Bug 11945 - Null Dereference (mbox.c)
Null Dereference (mbox.c)
Status: RESOLVED FIXED
Product: ClamAV
Classification: ClamAV
Component: All
ALL
x86_64 GNU/Linux
: P1 security
: 0.99.3
Assigned To: ClamAV team
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-10-26 19:25 EDT by Suleman Ali
Modified: 2021-09-23 16:37 EDT (History)
7 users (show)

See Also:
QA Contact:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Suleman Ali 2017-10-26 19:25:18 EDT
Created attachment 7310 [details]
poc, pass is virus

There is a NULL pointer dereference at `blob.c:273` inside the function `blobGetDataSize`:
```c
267	size_t
268	blobGetDataSize(const blob *b)
269	{
270		assert(b != NULL);
271		assert(b->magic == BLOBCLASS);
272	
273		return b->len;
274	}
```

The bug happens because the argument `b` is NULL. This situation is detected during debugging when the `assert` is executed. But in release mode the assert is ignored and the NULL pointer dereference happens.

The root of the problem is at `mbox.c:3137`:
```c
3136			b = messageToBlob(m, 1);
3137			len = blobGetDataSize(b);
```

The result of `messageToBlog` is not validated. Parsing the PoC the function `messageToBlog` return `NULL` and that value is passed to `blobGetDataSize`.

The PoC consists in a regular mail with a special header:
```
From: Francisco Oca <foca@salesforce.com>
To: Francisco Oca <foca@salesforce.com>
Content-Type:=??b?=ybegin line=?=
```

The delimiters `=?` and `?=` are used in the RFC2047 encoding (Message Header Extensions for Non-ASCII Text: https://www.ietf.org/rfc/rfc2047.txt). The value `?b` indicated a base64 encoding. In the ClamAV specification the expected base64 data could also have a yenc encoding header `=ybegin line=`, but the lack of any line makes the function to return NULL.

Apossible solution is:
mbox.c
```c
3136                 b = messageToBlob(m, 1);
3137                 if (b == NULL)
3138                         return NULL;
3139                 len = blobGetDataSize(b);
```

Backtrace:
```c
   #0 0x819c39d in exportBounceMessage /tmp/clamav-devel/libclamav/mbox.c:3770:21
    #1 0x819c39d in parseEmailBody /tmp/clamav-devel/libclamav/mbox.c:2356
    #2 0x819c15d in parseEmailBody /tmp/clamav-devel/libclamav/mbox.c:2055:11
    #3 0x8194e47 in cli_parse_mbox /tmp/clamav-devel/libclamav/mbox.c:555:11
    #4 0x8194e47 in cli_mbox /tmp/clamav-devel/libclamav/mbox.c:353
    #5 0x8182f73 in cli_scanmail /tmp/clamav-devel/libclamav/scanners.c:2010:16
    #6 0x816e5d2 in magic_scandesc /tmp/clamav-devel/libclamav/scanners.c:3291:19
    #7 0x8167904 in cli_base_scandesc /tmp/clamav-devel/libclamav/scanners.c:3616:11
    #8 0x8176391 in cli_magic_scandesc /tmp/clamav-devel/libclamav/scanners.c:3625:12
    #9 0x8176391 in scan_common /tmp/clamav-devel/libclamav/scanners.c:3891
    #10 0x8177162 in cl_scandesc_callback /tmp/clamav-devel/libclamav/scanners.c:4032:12
    #11 0x8177162 in cl_scanfile_callback /tmp/clamav-devel/libclamav/scanners.c:4099
    #12 0x8177162 in cl_scanfile /tmp/clamav-devel/libclamav/scanners.c:4082
```

This vulnerability has been found by Offensive Research at Salesforce.com:
Alberto Garcia (@algillera), Francisco Oca (@francisco_oca) & Suleman Ali (@Salbei_)
Comment 1 Joel Esler 2017-10-27 09:52:06 EDT
Thank you very much for reporting these issues.  If possible, we'd like to gather some initial first details from you on these.  

First, can you tell us what version of ClamAV you are reporting against?  I notice that you have our git-repository name in the reports, is this a fresh check out of git?
Comment 2 Mickey Sola 2017-10-27 17:12:08 EDT
Fixed this (with changes to the suggested patch to account for allocated memory that needed to be freed) in commit: https://github.com/vrtadmin/clamav-devel/commit/39c89d14a61aef2958b8ea64ade1be7a5faca897