curl / Docs / Security / curl URL sanitization vulnerability

curl URL sanitization vulnerability

                     curl URL sanitization vulnerability
Project curl Security Advisory, January 24th 2012
  curl is vulnerable to a data injection attack for certain protocols through
  control characters embedded or percent-encoded in URLs.
  When parsing URLs, libcurl's parser is very laxed and liberal and only
  parses as little as possible and lets as much as possible through as long as
  it can figure out what to do.
  In the specific process when libcurl extracts the file path part from a
  given URL, it didn't always verify the data or escape control characters
  properly before it passed the file path on to the protocol-specific code
  that then would use it for its protocol business.
  This passing through of control characters could be exploited by someone who
  would be able to pass in a handicrafted URL to libcurl. Lots of libcurl
  using applications let users enter URLs in one form or another and not all
  of these check the input carefully to prevent malicious ones.
  A malicious user might pass in %0d%0a to get treated as CR LF by libcurl,
  and by using this fact a user can trick for example a POP3 client to delete
  a message instead of getting it or trick an SMTP server to send an
  unintended message.
  This vulnerability can be used to fool libcurl with the following protocols:
  IMAP, POP3 and SMTP.
  Both curl the command line tool and applications using the libcurl library
  are vulnerable.
  There is no known exploit for this problem.
  The Common Vulnerabilities and Exposures (CVE) project has assigned the name
  CVE-2012-0036 to this issue.
  Affected versions: curl 7.20.0 to and including 7.23.1
  Not affected versions: curl < 7.20.0 and >= 7.24.0
  Also note that libcurl is used by many applications, and not always
  advertised as such.
  libcurl 7.24.0 scans for a range of "bad codes" in the path part of URLs so
  that they are rejected before any protocol code even can consider using
  We suggest you take one of the following actions immediately, in order of
  A - Upgrade to curl and libcurl 7.24.0
  B - Apply this patch and rebuild libcurl
  C - Rebuild curl with support for vulnerable protocols IMAP, POP3 and SMTP
  D - Disable the vulnerable protocols IMAP, POP3 and SMTP at run-time to
      forbid libcurl from using them. You can do this with the
  Dan Fandrich realized the problem and reported it to us on December 22nd
  We discussed solutions and a first patch was written on the same day.
  curl 7.24.0 was released on January 24th 2012, coordinated with the
  publication of this this flaw.
  Reported and analyzed by Dan Fandrich. Thanks a lot!