Your message dated Mon, 23 Jun 2008 18:17:07 +0000
with message-id <[EMAIL PROTECTED]>
and subject line Bug#487222: fixed in tmsnc 0.3.2-1.1
has caused the Debian Bug report #487222,
regarding tmsnc: remote stack based buffer overflow in UBX parsing code
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
487222: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487222
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: tmsnc
Severity: grave
Tags: security
Justification: user security hole

Hi,
quoting http://msnpiki.msnfanatic.com/index.php/Command:UBX:
"UBX is the sister command to UUX. UUX is used to set your personal·
message, UBX is sent by the server to all principles to inform them of·
the change (where B means Buddy). The format is similar to UUX; they are·
payload commands where the first parameter is the passport address of·
the contact who has just changed their personal message or currently·
playing song, and the second parameter is the length of the payload.

Syntax:
 >>> UBX [EMAIL PROTECTED] xxx\r\n
 <Data><PSM>My Personal Message</PSM><CurrentMedia></CurrentMedia></Data>

as far as I can see this is sent by the original msn client but clients·
like pidgin and tmsnc do not support sending this information but·
receiving it.

Let's have a look at the code for parsing such a message in tmsnc...
>From core_net.c:
    727 int
    728 MSN_server_handle(session, message, message_len)
    729      MSN_session *session;
    730      char *message;
    731      int message_len;
    732 {
    733     time_t tm;
    734     char buf[512], md_hex[48];
    ...
    748     while (getline(buf, sizeof(buf) - 1, session->sd) > 0) {
    ...
    833         } else if (strncmp(buf, "UBX", 3) == 0) {
    834             /*
    835              * we read the payload of this command·
    836              */
    837             /*
    838              * but do not do anything with it······
    839              */
    840             if ((ptr[1] = (char *)split(buf, ' ', 1)) == NULL ||        
//by gfhuang
    841                 (ptr[0] = (char *)split(buf, ' ', 2)) == NULL) {
    842                 strncpy(message, "Couldn't parse UBX", message_len - 1);
    843                 return -1;
    844             }
    845             i = atoi(ptr[0]);
    846             free(ptr[0]);
    847·
    848             if (read(session->sd, buf, i) != i) {
    849                 strncpy(message, "Couldn't read UBX payload",
    850                         message_len - 1);
    851                 return -1;
    852             }
    853             // parsing PSM, by gfhuang
    854             if(0 == i) buf[0] = 0;      //important, by gfhuang, when 
i=0, buf is untouched!

In line 734 the message buffer is declared to store 512 bytes of data.
Line 748 reads a command line coming from a buddy contact.
Line 833 and the following are used if the message buffer contains an UBX 
message like:
UBX [EMAIL PROTECTED] xxx\r\n where xxx is the length of the UBX payload.

Here is the actual bug. If the first 3 bytes of the buffer match to UBX and the 
string
contains two spaces which are passed to ptr[1] and ptr[0] this is a valid UBX 
message.

The split function comes from core_misc.c and does basically the same like the 
strchr
function, returning a pointer to the first occurance of the string passed as 
second parameter.
So after the call in line 841 ptr[0] will point to the message length.
This value is then converted to an integer using atoi in line 845 and passed to 
read in line 848.
This will then read the UBX payload from the MSN "packet" through the session 
socket.

So if the UBX payload length is declared to be more than sizeof(buffer) or the 
payload is longer
than sizeof(buffer) this results in a stack-based buffer overflow and possibly 
in arbitrary code
execution.

The code also uses atoi quite a lot without checking for negative values 
resulting in integer
conversion issues but I guess that those values are correct is ensured by the 
MSN server itself.

This looks related to #487046.
I already contacted the upstream author because of this.

Kind regards
Nico



--- End Message ---
--- Begin Message ---
Source: tmsnc
Source-Version: 0.3.2-1.1

We believe that the bug you reported is fixed in the latest version of
tmsnc, which is due to be installed in the Debian FTP archive:

tmsnc_0.3.2-1.1.diff.gz
  to pool/main/t/tmsnc/tmsnc_0.3.2-1.1.diff.gz
tmsnc_0.3.2-1.1.dsc
  to pool/main/t/tmsnc/tmsnc_0.3.2-1.1.dsc
tmsnc_0.3.2-1.1_amd64.deb
  to pool/main/t/tmsnc/tmsnc_0.3.2-1.1_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [EMAIL PROTECTED],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Nico Golde <[EMAIL PROTECTED]> (supplier of updated tmsnc package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [EMAIL PROTECTED])


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Mon, 23 Jun 2008 19:24:31 +0200
Source: tmsnc
Binary: tmsnc
Architecture: source amd64
Version: 0.3.2-1.1
Distribution: unstable
Urgency: high
Maintainer: Miriam Ruiz <[EMAIL PROTECTED]>
Changed-By: Nico Golde <[EMAIL PROTECTED]>
Description: 
 tmsnc      - textbased (console) MSN client
Closes: 487046 487222
Changes: 
 tmsnc (0.3.2-1.1) unstable; urgency=high
 .
   * Non-maintainer upload by the Security Team.
   * Fix stack-based buffer overflow in UBX handling
     (No CVE id yet; Closes: #487222, #487046).
Checksums-Sha1: 
 751ee4435057045d81cd7e2b353bd313ebfe5dc9 978 tmsnc_0.3.2-1.1.dsc
 8c9952a310edfac8da42dc532dfd7d9f3daa653a 3658 tmsnc_0.3.2-1.1.diff.gz
 41fef53746fd2818e5963a745d4aa18bc32626e1 52512 tmsnc_0.3.2-1.1_amd64.deb
Checksums-Sha256: 
 22f115348d24b9db74300a86bb91c02b83e77f33d98b27a91a0dd85babca9322 978 
tmsnc_0.3.2-1.1.dsc
 e986e499e0f9064a5a5d78ad4335311bce838e8b5c139d388dee9031a30ae97a 3658 
tmsnc_0.3.2-1.1.diff.gz
 7644a1792707d746928849bea10578f86cda89edaafa97276b5a75e0cfc9ce05 52512 
tmsnc_0.3.2-1.1_amd64.deb
Files: 
 9b769d90fa4a1359d06a2e5a857dfc67 978 net optional tmsnc_0.3.2-1.1.dsc
 91181fec20ccfe0f1c4aeb94b56835fd 3658 net optional tmsnc_0.3.2-1.1.diff.gz
 fc1ceccbe6446632f48009f31ae61133 52512 net optional tmsnc_0.3.2-1.1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkhf5BYACgkQHYflSXNkfP8DTwCfTfzUS/g3jy1QhkypNr8jL28Y
Py4AoIwf2rLMWkhPwUSW/xJeKIRqZ+z3
=1qAj
-----END PGP SIGNATURE-----



--- End Message ---

Reply via email to