Lynx CRLF Injection PROGRAM: Lynx VENDOR: Lynx-Dev List <lynx-devat_private> HOMEPAGE: http://lynx.browser.org/ VULNERABLE VERSIONS: 2.8.4rel.1, 2.8.5dev.8, 2.8.3rel.1, 2.8.2rel.1, possibly others IMMUNE VERSIONS: 2.8.4rel.1 with all patches applied PATCH: ftp://lynx.isc.org/lynx2.8.4/patches/lynx2.8.4rel.1c.patch SEVERITY: medium DESCRIPTION: "Lynx is a fully-featured World Wide Web (WWW) client for users running cursor-addressable, character-cell display devices such as vt100 terminals, vt100 emulators running on Windows 95/NT or Macintoshes, or any other character-cell display. It will display Hypertext Markup Language (HTML) documents containing links to files on the local system, as well as files on remote systems running http, gopher, ftp, wais, nntp, finger, or cso/ph/qi servers, and services accessible via logins to telnet, tn3270 or rlogin accounts. Current versions of Lynx run on Unix, VMS, Windows95/NT, 386DOS and OS/2 EMX." (direct quote from the program's README file) Lynx is published under the terms of the GNU General Public License. It is a very common program (I personally have used it since 1995), but this hole will only affect some of its users. SUMMARY: If you give Lynx a URL with some special characters on the command line, it will include faked headers in the HTTP query. This way, you can make scripts that use Lynx for downloading files access the wrong site on a web server with multiple virtual hosts. TECHNICAL DETAILS: When a URL is given on the command line or in the WWW_HOME environment variable, Lynx doesn't remove or encode dangerous characters such as space, tab, CR and LF before constructing HTTP queries. This means that an attacker can construct a URL that will send arbitrary faked HTTP headers, by adding space + "HTTP/1.0" + CRLF + some headers + CRLF + CRLF after the normal URL. Lynx's own HTTP headers are sent after the faked headers, but the web server ignores them, as our CRLF + CRLF pair above indicates the end of the headers. This may cause some security problems. One scenario is when a program starts Lynx, and the host part of the URL is supplied by the program and the path by its user (something like "lynx http://www.site3.st/$path", where the value of $path is defined by the user). An attacker can make such a program access some other web site than www.site3.st, if it's a virtual host on the same machine as www.site3.st, by adding a "Host:" header as described above. Relative links don't work in web pages that are fetched this way. If there is a relative link like <a href="sunnanvind.html">Sunnan</a> and the user follows it, Lynx gets confused. To get more information about this type of hole, read my paper "CRLF Injection", which is available at http://cert.uni-stuttgart.de/archive/bugtraq/2002/05/msg00079.html PERL EXPLOIT: #!/usr/bin/perl -- # Ulf Harnhammar 2002 # example: ./exploit www.site1.st www.site2.st # will show www.site2.st die "$0 hostone hosttwo\n" if @ARGV != 2; exec('lynx "'. "http://$ARGV[0]/ HTTP/1.0\012". "Host: $ARGV[1]\012\012". '"'); BASH COMMAND LINE EXPLOIT: (This exploit assumes that www.site1.st and www.site2.st are virtual hosts on the same machine. Lynx will show www.site2.st.) [ulf@metaur ulf]$ lynx "http://www.site1.st/ HTTP/1.0 Host: www.site2.st " COMMUNICATION WITH VENDOR: The vendor was contacted on the 13th of August. Their patch was released and announced on the Lynx-Dev list on the 18th. // Ulf Harnhammar ulfhat_private
This archive was generated by hypermail 2b30 : Sun Aug 18 2002 - 17:42:47 PDT