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.
This archive was generated by hypermail 2b30 : Tue Jul 31 2001 - 11:12:40 PDT