---------- Forwarded message ---------- Received: from BlackHole.RainNet.Org (rainat_private [192.168.1.3]) by Portal.RainNet.Org (8.8.8/8.8.8/Debian/GNU) with ESMTP id LAA23199 for <rainat_private>; Tue, 22 Dec 1998 11:56:57 -0500 Received: from listopher.concentric.net (listopher.concentric.net [206.173.119.117]) by BlackHole.RainNet.Org (8.8.5/8.8.5) with ESMTP id LAA16044 for <rainat_private>; Tue, 22 Dec 1998 11:57:05 -0500 Received: (from majordom@localhost) by listopher.concentric.net (8.8.3/8.8.5) id LAA02046; Tue, 22 Dec 1998 11:31:37 -0500 (EST) Message-ID: <199812221631.KAA03778at_private> To: ircii-epicat_private Subject: Re: Ircii-epic: about dcc hijacking... (fwd) In-Reply-To: Your message of "Mon, 21 Dec 1998 16:30:59 EST." <Pine.LNX.4.03.9812211630450.22325-100000at_private> Date: Tue, 22 Dec 1998 10:31:31 -0600 From: Jeremy Nelson <jnelsonat_private> Sender: owner-ircii-epicat_private Precedence: bulk >Heya, I did not say that dcc-hijack.c is more than a simple tcp >portscanner, so this is not so preposterous as you wrote. What I thought was preposterous is that you presented this as some kind of serious problem. >Then if you read my post with attention you can't find anything absurde. No comment. >More, it could not be a `bug', anyway we can easly patch irc-client to >bind random port. This won't change the problem since you can still port-scan a wider range to pick up the random ports. This kind of stuff is best left to the operating system. Your "exploit" only works when: 1) Someone either accepts or initiates a dcc transaction with an untrusted party. 2) During the time that the untrusted party runs the port scanner, the DCC transaction is the one and only transaction that is pending. If, for example, someone is doing a FTP, then you could just as well pick up one of their PORT commands rather than a DCC listen. 3) The untrusted party runs the port scanner between when the person initiates the latter DCC CHAT and when the latter DCC CHAT is accepted. (Race condition) 4) The person does not double-check the IP address on the latter DCC CHAT to see if it is reasonable. >Which is your point of view? hehe My point of view is that one should write a script to hook /on dcc_offer, dispatch a userhost or userip (depending on your network) to retrieve the hostname of the person you are soliciting for a dcc transaction. When that hostname information comes back, stash it in a variable. When the DCC is accepted, if the hostname information has not come back, 'wait'. If it has come back, then check $2 (or whatever) against the IP address of the person you are interested in. If its not the same, chances are you have a conflict to look at. An alternative solution for those who are lazy is to keep a "moving" variable that holds open a DCC RAW port over the last few DCC's you have offered. Something that hooks /on dcc_offer and then does a $listen() to fool the port scanner into connecting to the $listen() socket would be sufficient. One must be careful to close their fd's though when theyre done. I do not feel that the random binding of ports offers anything useful above and beyond the current mechanism. If you are interested in implementing either of the above, then i would be most appreciative and interested in your work... Jeremy
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:25:42 PDT