Lucene search

K
securityvulnsSecurityvulnsSECURITYVULNS:DOC:22920
HistoryDec 15, 2009 - 12:00 a.m.

Mozilla Code *sighs*

2009-12-1500:00:00
vulners.com
5

Mozilla Code sighs
I reported a memory corruption vulnerability in Mozilla Codesighs, a "set of tools to help you determine the code and data size of shared libraries and executables. Once you can measure the code and data size, then you can measure drifts in size as code changes occur".

Mozilla Codesighs is included as third party in Google's Chromium Operating System, Google's Gadget for Linux, and probably others. I didn't expect them to jump right on it since its not for Firefox or Thunderbird, but I did figure they'd let me know that they would get around to it eventually.

"… this is a debugging tool used in specific situations, to read as input
output generated by other programs. So even if it crashes in response to
some other input, I don't see how that's a vulnerability. This tool is not
designed to handle arbitrary input, nor does it need to be."

Seems like Mozilla… is… not interested?

int codesighs(Options* inOptions)
/*
** Output a simplistic report based on our options.
/
{
int retval = 0;
char lineBuffer[0x500];
int scanRes = 0;
unsigned long size;
char segClass[0x10];
char scope[0x10];
char module[0x100];
char segment[0x40];
char object[0x100];
char
symbol;
SizeStats overall;
ModuleStats* modules = NULL;
unsigned moduleCount = 0;

memset(&overall, 0, sizeof(overall));

/*
**  Read the file line by line, regardless of number of fields.
**  We assume tab seperated value formatting, at least 7 lead values:
**      size class scope module segment object symbol ....
*/
while(0 == retval && NULL != fgets(lineBuffer, sizeof(lineBuffer), inOptions->mInput))
{
    trimWhite(lineBuffer);

    scanRes = sscanf(lineBuffer,
        "%x\t%s\t%s\t%s\t%s\t%s\t",
        (unsigned*)&size,
        segClass,
        scope,
        module,
        segment,
        object);

The vulnerability is introduced in the sscanf() call, where the developer's code dangerously copies data in buffers without a width specifier, allowing us to overflow 5 different buffers.

Some technical details via GDB…

257 while(0 == retval && NULL != fgets(lineBuffer, sizeof(lineBuffer), inOptions->mInput))
(gdb)
259 trimWhite(lineBuffer);
(gdb)
trimWhite (inString=0xbfffd310 "1\tCODE\t", 'A' , "\t", 'A'
times>, "\t", 'A' , "\t", 'A' …) at codesighs.c:213
213 int len = strlen(inString);
(gdb)
215 while(len)
(gdb)
217 len–;
(gdb)
219 if(isspace(*(inString + len)))
(gdb)
221 (inString + len) = '\0';
(gdb)
215 while(len)
(gdb)
217 len–;
(gdb)
219 if(isspace(
(inString + len)))
(gdb)
228 }
(gdb)
codesighs (inOptions=0xbffff350) at codesighs.c:261
261 scanRes = sscanf(lineBuffer,
(gdb) i r
eax 0x0 0
ecx 0xb7fe468c -1208072564
edx 0x82 130
ebx 0x9d8ff4 10326004
esp 0xbfffd040 0xbfffd040
ebp 0xbffff328 0xbffff328
esi 0x0 0
edi 0x0 0
eip 0x8048945 0x8048945
eflags 0x246 [ PF ZF IF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
(gdb) s
270 if(6 == scanRes)
(gdb) i r
eax 0x6 6
ecx 0x414141 4276545
edx 0x0 0
ebx 0x9d8ff4 10326004
esp 0xbfffd040 0xbfffd040
ebp 0xbffff328 0xbffff328
esi 0x0 0
edi 0x0 0
eip 0x804899d 0x804899d
eflags 0x282 [ SF IF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
(gdb)

An attacker could give someone a file to parse with Codesighs and it will corrupt memory with the possibility of executing code on the their system.

That is in fact a vulnerability.

ONE DAY after I filed the bug report, they unmarked it as a security issue. So I guess they wouldn't mind if I blogged about it and let others investigate with this code…