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

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

In some mail from Juanjo Ciarlante, sie said:
> + *
> + * Insecure "back" data channel opening
> + *   The helper does some trivial checks when opening a new DCC data
> + *   channel. Use module parameter
> + *           insecure=1
> + *   ... to avoid this and get previous (pre 2.2.20) behaviour.
>   */
[..]
> +/*
> + *   Ugly workaround [TM] --mummy ... why does this protocol sucks?
> + *
> + *   The <1024 check and same source address just raise the
> + *   security "feeling" => they don't prevent a redirector listening
> + *   in same src address at a higher port; you should protect 
> + *   your internal network with ipchains output rules anyway
> + */

The < 1024 is actually a pretty good idea, especially if the client that
is on the receiving end isn't savy enough to do this itself.  Why ?  Well,
it stops someone from sending you a DCC message that connects to a chargen
port on some remote server from working.  What do I mean by that?  Well,
the content of the message which advertises the DCC connection is just
text - ^ADCC blah^A - and if you know the format (pretty basic) you can
send it via /msg anyway.  Since the message is conveyed via IRC, the
receiving client has no way of knowing that the IP address supplied by
the offer is actually a client and not something else.  Since you're
checking for < 1024, you might want to check that the IP address is
not in network 127 - afterall, you _are_ going through a firewall!

I think chargen is the only dangerous port as it's not even a protocol
(which would require ACKs, etc), just straight data, as fast as it can
send.  Unless there is some other server/service like this ?

For DCC file transfers, the proxy should be looking at the size parameter
in the DCC setup message, understand the byte-ack mechanism (used to
throttle transfers) and be able to "close the connection" when the
correct amount of data has been sent.

What other firewalls support this proxy and provide massive holes?

Anyway, to be "firewall friendly" AND "secure", the exchange to setup a
DCC chat or file transfer should be something like this:

clientA: (PRIVMSG to clientB)
PDCC which arg token ipaddressA portnumberA [size]
[at this point the recipient currently does /dcc foo and connects but
 that is not enough]

clientB: (NOTICE to clientA)
PDCC which arg token ipaddressB portnumberB
[this tells clientA where the connection should come from and it would
 be safe in discarding any others, now]

clientA: PDCCACK token (PRIVMSG to clientB)
[clientB is now free to connect to clientA, who prior to sending this,
 should reject any connections to the incoming DCC port]

The "token" is just there to identify a particular exchange.  This is
not meant to be "secure" (use crypto) just firewall/proxy friendly.  I've
just thought about this whilst writing this email so don't flame me if
there are glaring problems above O:)  If someone else actually thinks
it'll work, maybe it should be added to ircII for starters..

Now, IF I understand the exploit correctly then there are _serious_
problems in that proxy's validation of messages.  First and foremost
it is _NOT_ checking to make sure it is a complete PRIVMSG as is found
within the IRC protocol.  If it were then the exploit would be more
like:

0x0a:foo PRIVMSG bar :^ADCC params^A0x0d0x0a

And that's ignoring things like it should have seen the client send
a "NICK" command, maybe "PASS" as well as "USER", etc, and even expect
back responses FROM the IRC server indicating that the client had been
able to successfully register BEFORE allowing any DCC proxying.

In short, someone should throw that proxy away and write a real one and
in doing so will make it incredibly hard to force "bad things" to happen.

The FTP proxy in Linux suffered from a similar problem - it looked for a
"magic string" rather than being "protocol savy".  How many other firewalls,
commercial and not, try take these short cuts and sacrifice security ?  Is
there an IRC/DCC thing for FW-1 ?  Is that "secure" ?

Darren 

p.s. DCC being such a PITA to proxy safely is why there is no IRC proxy in
any redily available version of IPFilter.