Re: Ircii-epic: about dcc hijacking... (fwd)

[rain () INSANE LOONYBIN NET (Ben Winslow)]

---------- Forwarded message ----------
Received: from BlackHole.RainNet.Org (rain () BlackHole RainNet Org [192.168.1.3])
        by Portal.RainNet.Org (8.8.8/8.8.8/Debian/GNU) with ESMTP id LAA23199
        for <rain () portal RainNet Org>; 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 <rain () insane loonybin net>; 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.KAA03778 () nemesis acronet net>
To: ircii-epic () concentric net
Subject: Re: Ircii-epic: about dcc hijacking... (fwd)
In-Reply-To: <Pine.LNX.4.03.9812211630450.22325-100000 () Portal RainNet Org>
Date: Tue, 22 Dec 1998 10:31:31 -0600
From: Jeremy Nelson <jnelson () acronet net>
Sender: owner-ircii-epic () concentric net
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