Multiple stack buffer overflows in HTTP response handling in bb_ledm.c

Bug #1544099 reported by Vittorio Gambaletta (VittGam)
260
This bug affects 1 person
Affects Status Importance Assigned to Milestone
HPLIP
Undecided
Unassigned

Bug Description

The bb_ledm.c file contains at least four stack overflows in case of bad input.

For example, the BinaryURL parameter is contained in an XML HTTP response from the scanner, so this is remotely exploitable (but the user still needs to manually start a scan with sane).

From line 1011 of scan/sane/bb_ledm.c:

char *c = strstr(buf, "<BinaryURL>");
_DBG("bb_start_scan() BinaryURL=%s \n", c);

if (!c) goto bugout;
c +=11;
char BinaryURL[30];
i = 0;
while(*c != '<')
{
BinaryURL[i++] = *c ;
c++;
}
BinaryURL[i] = '\0';
//_DBG("bb_start_scan() BinaryURL=%s\n", BinaryURL);
len = snprintf(buf, sizeof(buf), GET_SCAN_JOB_URL, BinaryURL);

Line 1018 should be:

while(*c != '<' && i < 29)

to avoid the stack overflow.

Same thing goes for the Location header "parser", or the way http_read_size is used in get_size and in bb_get_image_data (third call, size parameter comes from HTTP chunked encoding... too many assumptions were made instead of using a proper HTTP parser!).

P.s: the ugly XML "parser" that's used in parse_scan_elements doesn't even check tag names but it trusts some built-in ordering of the tags, so it obviously gets some values wrong on my scanner (HP OfficeJet Pro 8600 Plus, it's the max X and Y resolutions, instead it gets the minimum resolution and the max X resolution)... Luckily those values aren't used for anything in the sane driver.

Cheers,
Vittorio G

information type: Private Security → Public Security
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers