bugThe oSIP library - Bugs: bug #63103, osip_body_parse_header len integer...

 
 

bug #63103: osip_body_parse_header len integer overflow (5.3.0) [CVE-2022-41550]

Submitter:  Marco Bartoli <wsx>
Submitted:  Sun 25 Sep 2022 04:28:15 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  aymeric
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 12 Oct 2022 05:02:14 PM UTC, comment #5: 

To be complete:

When end_of_line is NULL: (end_of_line - 2) - colon_index < 2 may be true.

This will ends up crashing and explains why there was a crash when compiling with "-m32"

Aymeric MOIZARD <aymeric>
Group administrator
Wed 28 Sep 2022 01:35:22 PM UTC, comment #4: 

The other places are false positive. The use-case should never happen because those methods are called after removing LWS.

In msg_osip_body_parse, LWS wasn't removed (they are not allowed here)

The current code should be safe.

I will think about adding the return anyway in the 2 files you mentioned.

Thanks

Aymeric MOIZARD <aymeric>
Group administrator
Tue 27 Sep 2022 06:04:30 PM UTC, comment #3: 

Thanks for the fast fix.

Yes I did not analyze completely what was happening in the caller (osip_body_parse_header) so I assumed it was an overflow from there, that's why I said probably.

I verified and the fix is correct! Not exiting on the error value -2 made osip_clrncpy crash because of an overflow achieved with garbage data.

I checked around the codebase and it seems this bug is replicated two other times, not sure if it's triggerable but better fix those too.

https://git.savannah.gnu.org/cgit/osip.git/tree/src/osipparser2/osip_message_parse.c#n590

https://git.savannah.gnu.org/cgit/osip.git/tree/src/osipparser2/osip_message_parse.c#n388

Marco Bartoli <wsx>
Tue 27 Sep 2022 09:26:33 AM UTC, comment #2: 

Hi Marco,

Thanks a lot for your report.

I made a fix, available there:

https://git.savannah.gnu.org/cgit/osip.git/commit/?id=f77f16c832c3c37589c2b749f01b644dc44a55b5

The change doesn't look to match exactly your report: the bug appeared on the line after osip_clrncpy for me.

Can you please check the newest fix?

Regards
Aymeric

Aymeric MOIZARD <aymeric>
Group administrator
Sun 25 Sep 2022 04:56:37 PM UTC, comment #1: 

pwndbg> bt
#0  0x5656a1b7 in osip_clrncpy ()
#1  0x5655adde in osip_body_parse_header ()
#2  0x5655b057 in osip_body_parse_mime ()
#3  0x5655ab82 in osip_message_set_body_mime ()
#4  0x56564844 in msg_osip_body_parse ()
#5  0x56564c6d in _osip_message_parse ()
#6  0x56564d2f in osip_message_parse ()
#7  0x56577511 in test_message ()
#8  0x5657737b in main ()
#9  0xf7c1f129 in ?? () from /usr/lib32/libc.so.6
#10 0xf7c1f1fd in __libc_start_main () from /usr/lib32/libc.so.6
#11 0x5655636b in _start () at ../sysdeps/i386/start.S:111
pwndbg> disass $pc, $pc+16
Dump of assembler code from 0x5656a1b7 to 0x5656a1c7:
=> 0x5656a1b7 <osip_clrncpy+181>:       movzx  eax,BYTE PTR [eax]
   0x5656a1ba <osip_clrncpy+184>:       cmp    al,0x20
   0x5656a1bc <osip_clrncpy+186>:       je     0x5656a17c <osip_clrncpy+122>
   0x5656a1be <osip_clrncpy+188>:       mov    eax,DWORD PTR [ebp-0x18]
   0x5656a1c1 <osip_clrncpy+191>:       movzx  eax,BYTE PTR [eax]
   0x5656a1c4 <osip_clrncpy+194>:       cmp    al,0xd
   0x5656a1c6 <osip_clrncpy+196>:       je     0x5656a17c <osip_clrncpy+122>
End of assembler dump.
pwndbg> info reg
eax            0xfffffffd          -3
ecx            0x0                 0
edx            0xf7fc14c0          -134474560
ebx            0x5657fff4          1448607732
esp            0xffffd070          0xffffd070
ebp            0xffffd088          0xffffd088
esi            0xffffd340          -11456
edi            0xf7ffcb80          -134231168
eip            0x5656a1b7          0x5656a1b7 <osip_clrncpy+181>
eflags         0x10282             [ SF IF RF ]
cs             0x23                35
ss             0x2b                43
ds             0x2b                43
es             0x2b                43
fs             0x0                 0
gs             0x63                99

Marco Bartoli <wsx>
Sun 25 Sep 2022 04:28:15 PM UTC, original submission:  

Hello, I would like to report an integer overflow I found fuzzing the SIP parsing function of the latest version (5.3.0).

osip_clrncpy pend pointer overflows adding the length to the src ptr, this wrong len probably comes from some overflows in osip_body_parse_header.
The program crashes when it tries to read from the overflown pend.

```
init pend=0xfffffffd == (len=135081942 + src=0xf7f2d028 - 1) pbeg=0xf7f2d028
```

To reproduce the bug, change the torture file size limit to use 200000 instead of 100000 and compile it for 32bit (-m32).

```
./torture crash1_5.3.0_report
```

Thanks and looking forward for a feedback,
Marco `wsx` Bartoli

Marco Bartoli <wsx>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #53752:  crash1_5.3.0_report added by wsx (132KiB - application/octet-stream - Testcase to crash 32bit parse)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by aymeric (Posted a comment)
  • -email is unavailable- added by wsx (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-10-12 aymeric Summaryosip_body_parse_header len integer overflow (5.3.0) osip_body_parse_header len integer overflow (5.3.0) [CVE-2022-41550]
    2022-09-28 aymeric Open/ClosedOpen Closed
    2022-09-27 aymeric StatusNone Fixed
        Assigned toNone aymeric
    2022-09-25 wsx Attached File- Added crash1_5.3.0_report, #53752

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code