[asterisk-bugs] [Asterisk 0010977]: [patch] multiple buffer problems with DUNDi

[noreply at bugs.digium.com]

The following issue has been UPDATED. 
====================================================================== 
http://bugs.digium.com/view.php?id=10977 
====================================================================== 
Reported By:                dimas
Assigned To:                russell
====================================================================== 
Project:                    Asterisk
Issue ID:                   10977
Category:                   PBX/pbx_dundi
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.13  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             10-14-2007 16:17 CDT
Last Modified:              10-15-2007 10:00 CDT
====================================================================== 
Summary:                    [patch] multiple buffer problems with DUNDi
Description: 
During debuggint DUNDi stuff I found several strange things in debug output
which led me to several fixes:

1. pbx/pbx_dundi.c does not initialize nor zaro-terminate buffer before
passing it to ast_canmatch_extension. I'm not sure what it can affect I
just noticed that packet debug output HINT sometimes contains garbage.

2. There were lines like:

        ANSWER          : [EXISTS|CANMATCH] 0
<IAX/dundi at XX.XX.XX.XX/4444 at dundi-users> from [00:15:17:13:a6:c3]

note the extra character after the context name. I looked to
pbx/dundi-parser.c code and found the following. In the dump_* functions:

1. There are many constants like in:

memcpy(tmp + strlen(tmp), value + 2, len - 2)

in dump_hint(). The "2" is sizeof unsigned short - the flags field. I have
no idea why the code is full of these when you have properly defined struct
for that (dundi_hint).

2. There is alot of "buffer magic". Instead of doing simple snprintf,
there are places using several buffers to concatenate intermediate results
and then finally copy to the output buffer.

3. There are potential buffer overruns (I do not know exploitable or not).
For example, in the dump_hint, the code:

memcpy(tmp + strlen(tmp), value + 2, len - 2)

does not verify there is enough space in the "tmp" buffer.
====================================================================== 

---------------------------------------------------------------------- 
 russell - 10-15-07 10:00  
---------------------------------------------------------------------- 
(marked as public again)

I do not think any of the potential overflows you have pointed out are
exploitable, mostly because the code makes assumptions about the maximum
information element length that can be passed in.  The DUNDi protocol only
allows a maximum of 255 byte information element payloads.

I still like your second patch, though, and will apply it to trunk.  The
bug fix will go to both 1.4 and trunk. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-15-07 10:00  russell        Note Added: 0071990                          
10-15-07 10:00  russell        View Status              private => public   
======================================================================