Re: [RAZOR] Linux kernel IP masquerading vulnerability (_actual_

[Darren Reed <avalon () coombs anu edu au>]

In some mail from Michal Zalewski, sie said:
[...]
> This does not really give that much. As discussed in our advisory, it is
> possible to generate 'good loking' USER and NICK sequence, and 'good
> looking' IRC server response. Two things here - first of all, most of web
> browsers ignore first line sent by remote host - the banner - and accept
> it even if it does not start with valid ftp protocol numeric code. Also,
> response fragmentation (newlines in the middle of TCP packets, and so on),
> can be used to make HTTP client think it sees FTP messages and the
> firewall to think it sees IRC conversation. Sample conversation might 
> look like that:
>
> > ":server 255 user :Hello\r\n331 Username OK"
>   (ignored by web browser)

Say what?  What do FTP numeric responses have to do with IRC and an IRC
proxy?  Also, IRC servers generally don't send anything unless an error
is generated, a PING is sent or registration is complete.  There is
no "you have connected to me" banner (or is this a recent bastardisation?).

> < "USER user +iw user user\r\nNICK user\r\n"
>   (as a result of ftp://USER%20user%20...@server:6667/...) 
>
> > ":server 255 user :You are welcome\r\n210 Something"
>   (client will usually join this together with remaining
>    331 Username OK from previous message; firewall would
>    probably parse it as-is, as IRC message)
>
> ...and so on, and so on.

Upto this point you've not shown me anything that a well written proxy
cannot detect and reject.  At least the IPFilter ftp* proxy knows if it
was in the middle of a string when it reached the end of the packet and
junks following text upto the next \r\n in the next packet.  Likewise the
irc proxy should be doing the same.  Given that this is for IRC and IRC
uses TCP, it can simply drop things which are out of order (if a server is
trying to play nasty and attack).  The proxy should work when it is
interfacing between an IRC client and an IRC server under normal
circumstances (i.e ignore things going through byte at a time, etc) but
whether or not it does when talking to an FTP server is not important,
although you would generally prefer it didn't.

So where was I going with that...oh, that's right, your look-alike
":server 255 user :You are welcome" should just be ignored and given
the FTP server is never going to respond in a fashion that is recognised
by the IRC proxy, you'll go nowhere, fast.

> Not to mention using Java applets for this purpose. Very tight protocol
> validation makes the attack somewhat more complicated, but does not solve
> the question of sender's intentions =)

If you want to go to that extreme, there is nothing safe you can do.
The applet could sit there sending out PRIVMSG commands to a /dev/null
style server for every port from 1024 - 65535 (there's no requirement
on the part of DCC for the previous port to be connected before another
"connect to me " announcement is sent out).

For most netizens that use Windows, so long as the < 1024 ports are just
ignored, life is not likely to be too hard.

Even the original problem needed a bit of work to exploit.  Whilst the
target string is:

<IMG SRC="http://server:6667/^ADCC stuff^A">

you should at least have been required to get the correct IP address,
which when using NAT and a web proxy may not even be available to the
remote server.  Still, you can't use static HTML here, unless javascript
can find out your IP#.

Darren
* - well, it's _meant_ to work that way :*)