FS#48112 - [hplip] Stack buffer overflow in BinaryURL handling in bb_ledm.c

Attached to Project: Arch Linux
Opened by Vittorio Gambaletta (VittGam) - Tuesday, 09 February 2016, 21:35 GMT
Last edited by Andreas Radke (AndyRTR) - Wednesday, 16 March 2022, 19:24 GMT
Task Type Bug Report
Category Security
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

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.

Additional info:
* Both published version (3.15.11-2) and latest upstream version (3.16.2) are vulnerable
* I don't know how to report this bug to HP...

Cheers,
Vittorio G
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Wednesday, 16 March 2022, 19:24 GMT
Reason for closing:  Fixed
Comment by Vittorio Gambaletta (VittGam) - Wednesday, 10 February 2016, 00:07 GMT
Actually, the bb_ledm.c file contains other stack overflows in case of bad input... There are at least another two in bb_start_scan.

Not to mention the ugly XML "parser" that 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... Sigh.
Comment by Andreas Radke (AndyRTR) - Wednesday, 10 February 2016, 14:50 GMT
Please send it upstream!
Comment by Vittorio Gambaletta (VittGam) - Wednesday, 10 February 2016, 14:58 GMT
I've now found their bug tracker on Launchpad, I failed to find it before...
Comment by Levente Polyak (anthraxx) - Thursday, 11 February 2016, 01:08 GMT
@VittGarn: can you please link to the upstream report?
Comment by Vittorio Gambaletta (VittGam) - Friday, 12 February 2016, 10:53 GMT
It is https://bugs.launchpad.net/bugs/1544099 but it is still unassigned and unreplied...

But I think that only the "HPLIP security team" can see it for now.
Comment by Vittorio Gambaletta (VittGam) - Sunday, 21 February 2016, 06:48 GMT
As of now nobody from the HPLIP team has acknowledged the bug... I was able to make it public on Launchpad though.

I don't know what to do exactly now; should I get a CVE number and do a full disclosure (somehow)?
Comment by Levente Polyak (anthraxx) - Sunday, 21 February 2016, 13:27 GMT
@VittGarn: please try to reach someone through the HP security reporting portal / or send them an email which is listed there with a GPG key:
https://h41268.www4.hp.com/live/index_e.aspx?qid=11503
Comment by Andreas Radke (AndyRTR) - Thursday, 23 June 2016, 18:36 GMT
Any news on this?
Comment by Vittorio Gambaletta (VittGam) - Saturday, 12 March 2022, 19:12 GMT
  • Field changed: Percent Complete (100% → 0%)
Actually, it's not fixed in the latest v3.21.12. Nobody from HP has ever acknowledged this remotely exploitable security bug in these six years!
Comment by Andreas Radke (AndyRTR) - Saturday, 12 March 2022, 20:19 GMT
I've applied your suggested fix to 3.22.2-2 in testing repo. Please confirm it still working.

Loading...