[security] 2.0.6 crashable from remote
Peter Zelezny
Due to a bug, version 2.0.6 can be crashed from remote. All users of 2.0.6
should upgrade immediately. 2.0.5 and earlier is not affected.
Explanation:
When receiving a "passive" dcc request with an invalid ID number, the client
will dereference NULL. As far as I know, this isn't exploitable other than
crashing the client (it tries to write to address 0x00000008).
Cause:
A patch accepted around Nov 18 (dcc psend patch) introduced this bug by
neglecting to check for a NULL pointer returned from a function.
(Don't blame me, I didn't write it! :) )
Solution:
Work-around: /ignore *!*@* DCC
Fix: Apply patch to 2.0.6 and recompile.
Permanent fix: Pay me to check 3rd party patches more thoroughly.
Patch:
http://xchat.org/files/source/2.0/xc206-fixpsend.diff
2.0.7 may follow in a few days to avoid the problem of people downloading
2.0.6 without the patch.
--
Peter.
--
XChat-discuss: mailing list for XChat users
Archive: http://mail.nl.linux.org/xchat-discuss/
Daniel Dubois
On Sat, 2003-12-13 at 11:52, Peter Zelezny wrote:
> A patch accepted around Nov 18 (dcc psend patch) introduced this
bug by
> neglecting to check for a NULL pointer returned from a function.
> (Don't blame me, I didn't write it! :) )
Sorry I didn't pay much attention on that pointer while porting that
patch from xchat 1.8.
Now I'm looking for other possible fixes and I've found one more: when
sending a file in certain conditions the sender receives a wrong error
message (XP_TE_DCCSENDFAIL) before che "complete message"
(XP_TE_DCCSENDCOMP).
The conditions are:
/dcc psend (always)
/dcc send (with fastdcc=0 in xchat.conf, this is not caused by psend
patch and affects also previous versions of xchat)
In default configuration the wrong message does not occur (/dcc send
with fastdcc=1).
A possible fix could be the patch included in this message that i will
explain now:
Actually if fastdcc=0 and pos=ack=size, dcc_read_ack() calls
dcc_send_data(). But dcc_send_data() has a read() that returns 0 because
we are at the end of the file, and for this reason the dcc is aborted.
Then dcc_send_data() notifies dcc completion causing confusion to the
user.
This patch makes dcc_read_ack() check for dcc completion before trying
to send new data.
This is only a possible fix, I dunno if it is the right one, but I've
tested dcc send/dcc psend with/without resume and with/without fastdcc
and it seems to work.
> Permanent fix: Pay me to check 3rd party patches more
thoroughly.
It is not your fault, also Khaled had the same bug, that fortunately is
not critical :)
Best regards
--
Daniel Dubois : in...@azzurra.org : Pub Key available on key servers
Key fingerprint = 137B 389F 03CF B65B 5CBD 301A 260D 7C92 7C7E 7F5A
David Oftedal
> The conditions are:
> /dcc psend (always)
> /dcc send (with fastdcc=0 in xchat.conf, this is not caused by psend
> patch and affects also previous versions of xchat)
>
> In default configuration the wrong message does not occur (/dcc send
> with fastdcc=1).
Funny, because I get that error all the time, and I use fast DCC sends.
DCC SEND blablabla failed.
DCC SEND blablabla done.
-David Oftedal
Peter Zelezny
Daniel Dubois <in...@azzurra.org> wrote:
> The conditions are:
> /dcc psend (always)
> /dcc send (with fastdcc=0 in xchat.conf, this is not caused by psend
> patch and affects also previous versions of xchat)
>
> In default configuration the wrong message does not occur (/dcc send
> with fastdcc=1).
That would make sense, since fastsend=off is rarely tested/used.
> A possible fix could be the patch included in this message that i will
> explain now:
>
> Actually if fastdcc=0 and pos=ack=size, dcc_read_ack() calls
> dcc_send_data(). But dcc_send_data() has a read() that returns 0 because
> we are at the end of the file, and for this reason the dcc is aborted.
> Then dcc_send_data() notifies dcc completion causing confusion to the
> user.
> This patch makes dcc_read_ack() check for dcc completion before trying
> to send new data.
> This is only a possible fix, I dunno if it is the right one, but I've
> tested dcc send/dcc psend with/without resume and with/without fastdcc
> and it seems to work.
With all that testing, I'm pretty happy with it. But, how does this affect
psend? From your patch, it looks like the changes would affect only fastsend=off.
Daniel Dubois
> With all that testing, I'm pretty happy with it. But, how does this affect
> psend? From your patch, it looks like the changes would affect only fastsend=off.
The previous patch fixes all dcc (send and psend) with fastsend=0.
The bug you have discovered is that fastdcc is not set to 1 using pdcc
also if prefs.fastdcc=1. This is because fastdcc is set only when the
dcc connection is accepted and not when it is initialized by the sender.
This cumulative patch shoud fix it (it is only one line).