nmlorg / naim

naim is a console client for AOL Instant Messenger (AIM), AOL I Seek You (ICQ), Internet Relay Chat (IRC), and The lily CMC.
http://naim.n.ml.org/
1 stars 0 forks source link

Certain malformed statuses can crash naim and cause an assertion failure. #39

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
> What steps will reproduce the problem?

1. Get the status of certain users with malformed status (this can happen on 
signon).

> What is the expected output? What do you see instead?

Naim crashes with Assertion failed: (s[len+3] == 0), function toc_got_data, 
file toc2.c, line 1812.
                                                                                 Abort (core dumped)

> What version of naim are you using? On what operating system?
> % naim --version

naim 0.11.8.3.2

> % uname -a

FreeBSD prime.gushi.org 6.4-STABLE FreeBSD 6.4-STABLE #1: Sat Mar  7 23:54:27 
EST 2009     danm@prime.gushi.org:/usr/src/sys/i386/compile/PRIME6  i386

> Please provide any additional information below.

[01:46:08] *** frame=2, sequence=in:39142, length=42, 
value=[UPDATE_BUDDY2:briancrackberry:F:0:0:0: :0]
[01:46:08] *** frame=2, sequence=in:39143, length=69, 
value=[BART2:briancrackberry:4 2 ABNJIHdhbnQgcGFuY2FrZXMgT19v 4 13 ThuL1w== ]
[01:46:08] *** BART 4 2: STATUS_TEXT: ABNJIHdhbnQgcGFuY2FrZXMgT19v []

Original issue reported on code.google.com by goo...@gushi.org on 12 Jul 2011 at 6:31

GoogleCodeExporter commented 9 years ago
I think I know what is going on here.  naim expects there to be a trailing NULL 
in the Base64 stream *after* the length'ed bits -- or otherwise, for the number 
of bytes to require Base64 padding.  If we look at the Base64 data:

joshua@escape:~$ openssl base64 -d | hexdump -C
ABNJIHdhbnQgcGFuY2FrZXMgT19v
00000000  00 13 49 20 77 61 6e 74  20 70 61 6e 63 61 6b 65  |..I want pancake|
00000010  73 20 4f 5f 6f                                    |s O_o|
00000015

then we'll note that the length is correct, but there's no trailing null.  
firetalk_debase64 does successfully add a null, passing the check on line 1811 
(s[len+2] == 0), but there's no extra null at the end.

I think there should be no adverse behavioral change from removing the assert 
for s[len+3].  I will create a patch for this shortly.

Original comment by joshua.a...@gmail.com on 12 Jul 2011 at 6:37