> Yes, this might help. But why worry? they would need to port scan, and
> find the port quicker than the other client can connect. Do you think they
> can do this all the time? Or Barely ever? So this is not a problem, I
> don't understand why anyone even got jumpy over it. I could do the same
> with ftp, ftp opens ports waiting to recieve files. Do you see people
> making patches for that?
the point of the original post was that you dont need to do a real port
scan, you can just hammer the next port until you get a connection.
you probably *will* do it before the other client, actually, because
bitchx likely calls listen() for the dcc socket at the same time it
sends the offer message, and it will take some time for the other
client to get the message over irc.
i think there is a correct way to fix this, if you see it as
sufficiently exploitable that it is a problem. you accept()
connections to the offered dcc until you get one from an ip and port
that you are happy with. unfortunately, the "standard" for dcc
(created by the behavior of ircii) doesnt provide any mechanism for the
dcc requester to specify this, so you either have to invent one or
assume that it will come from the same ip as the irc client that
initiated the dcc transfer. some people see it as useful that you can
request a dcc from a client at one ip and do the transfer at another;
some people see it as dangerous.
yes, people do make patches for this with ftp. for example, in the ftp
server i use (apologies to whomevers copyright im violating in my
laziness):
s = accept(pdata, (struct sockaddr *)&from, &fromlen);
...
if (s < 0) {
reply(425, "Can't open data connection.");
...
}
if (ntohs(from.sin_port) < IPPORT_RESERVED) {
perror_reply(425, "Can't build data connection");
...
}
if (from.sin_addr.s_addr != his_addr.sin_addr.s_addr) {
perror_reply(435, "Can't build data connection");
...
}
or havent you heard of "ftp bounce attacks"? (yes, i realize that that
refers to asking the ftp server to connect to something, but it may be
exploitable in some instances to instead connect something to an ftp
server, and its a very similar attack, and clearly someone went to the
trouble of preventing it with the code shown above.)
now, arguably, this behavior in an ftp server is a misfeature, because
it prevents you from using tools like fxp. but this has been recognized
as a security issue before.
> as recently discovered, with a simple port scan you can hijack some
> of the BitchX dcc
> connections. This due to the port assigning on the requesting client.
> Here follows a really short patch that will fix the problem. The problem
> is here:
> BitchX when creates a DCC connection (listening socket) uses the
> functions
> connect_by_number (defined in network.c file). Passing as port 0
> This means that the OS will determine the port. Now.. for mental order..
> the ports will be quiet consecutive. Bad.. Bad... So.. let's add a
> random value to the port returned by the system. All is now fixed.
> Patch follows
this patch is just silly. it adds an eight bit value, which is not
actually that much change, although it would make the attack somewhat
more difficult to execute, it adds it after going to network order, it
doesnt check for overflow, which could mean leaving the valid range
(1-65535) or wrapping into the reserved range (1-1023), depending on
the size of sin_port, and it doesnt retry if the port is already
taken.
bind() should do the work for you. if you are paranoid you can use a
tcp stack like openbsds, which returns a random port from among the
free ones. the only reason sequential port allocation is a problem is
that it makes portscanning for new listen()s in realtime much easier,
because it typically takes much less traffic to accomplish the same
probing. i think the real fix is what i discuss above; not blindly
accepting what you are accept()ing.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:26:15 PDT