[Home]

Summary:ASTERISK-22590: BufferOverflow in unpacksms16() when receiving 16 bit multipart SMS with app_sms
Reporter:Jan Juergens (j_juergens)Labels:Security
Date Opened:2013-09-26 07:05:20Date Closed:2013-12-16 09:40:54.000-0600
Priority:CriticalRegression?
Status:Closed/CompleteComponents:Applications/app_sms
Versions:SVN Frequency of
Occurrence
Frequent
Related
Issues:
Environment:Debian 7,1, Kernel 3.2.0-4-686-paeAttachments:( 0) Handle16BitSmsWithOddLength.patch
( 1) smsT8
Description:In the current HEAD, a buffer overflow in app_sms.c prevents Asterisk from receiving 16 bit multipart SMS, as it runs in an endless loop over the array boundaries.

The function unpacksms16() always expects an even number of bytes to be processed. If, however, the user data header contains an odd number of bytes, the second while-loop never terminates (l is never 0 in the while condition) and it keeps overwriting the boundaries of *i until Asterisk terminates with a SIGSEGFAULT.
The odd number of bytes are according to specification, though (http://www.etsi.org/deliver/etsi_ts%5C123000_123099%5C123040%5C11.05.00_60%5Cts_123040v110500p.pdf page 74).

The error has been reproduced by sending a multipart SMS with 16 bit encoding from Deutsche Telekom and Vodafone to a German landline number, which is handled by Asterisk.

We have addressed this issue by creating a patch, which checks for an odd number of bytes and adds another byte in that case.
Comments:By: Jan Juergens (j_juergens) 2013-09-26 07:17:21.374-0500

The patch that addresses the issue.

By: Matt Jordan (mjordan) 2013-09-26 07:28:36.604-0500

For now, I've locked down this issue to Bug Marshal + Issue Reporter.

In the future, if you think you've identified something that could be remotely exploitable, please contact a bug marshal or e-mail us at security@asterisk.org. That helps to keep such things from becoming public before they are addressed.

By: Jan Juergens (j_juergens) 2013-10-09 09:47:29.024-0500

We dumped the content of a sms_t struct at the beginning of sms_handleincoming() while trying to understand the issue. I'll add it here so others can reproduce the bug. This data was received from the Deutsche Telekom.

By: Scott Griepentrog (sgriepentrog) 2013-10-21 13:59:23.863-0500

Jan-

Can you confirm that in your example smsT8 the text portion of the message is supposed to include the 4 character, as in "...adgj54" is correct instead of "...adgj5"?

Thanks,
Scott

By: Jan Juergens (j_juergens) 2013-10-23 09:04:13.052-0500

Hi Scott, unfortunately, the phone from which we sent the test messages did not save all the sent messages. I found a message with a similar text passage, so I'm guessing this should be it:

Ucs2 mit uberlÂȘnge
1.adgjmptw2.adgjmptw3.adgjmptw4.adgjmptw5.adgj543210.adgjmptw1ÂȘend

So yes, it looks like the 4 is included.

By: Scott Griepentrog (sgriepentrog) 2013-10-23 09:49:30.767-0500

Great!  Okay, then this patch duplicates that functionality and should be correct.  I'm running it on a test loop trying to break it against random garbage input and it's been fine so far, so there should be no more surprises.