Beginners error: Hewlett-Packards driver software executes rogue binary C:\Program.exe May 20 2014 10:14PM
Stefan Kanthak (stefan kanthak nexgo de)
Hi @ll,

several programs of the current Windows 7 driver software for the
"HP OfficeJet 6700" multifunction device execute a rogue program

The evidence (an excerpt from the SAFER log, cf.
<http://technet.microsoft.com/en-us/library/bb457006.aspx> or

HPScanDisco.exe (PID = 3980) identified C:\Program.exe as Unrestricted using default rule, Guid =
FaxApplications.exe (PID = 3148) identified C:\Program.exe as Unrestricted using default rule, Guid =
ScanToPCActivationApp.exe (PID = 2944) identified C:\Program.exe as Unrestricted using default rule, Guid =

In every instance these programs try to execute
C:\Program Files\HP\HP Officejet 6700\Bin\HPNetworkCommunicatorCom.exe

The vulnerability is the result of calling Windows' CreateProcess*()
with an unquoted command line containing spaces!

Cf. <http://msdn.microsoft.com/library/cc144175.aspx> or

| Note: If any element of the command string contains or might contain
| spaces, it must be enclosed in quotation marks. Otherwise, if the
| element contains a space, it will not parse correctly. For instance,
| "My Program.exe" starts the application properly. If you use
| My Program.exe without quotation marks, then the system attempts to
| launch My with Program.exe as its first command line argument. You
| should always use quotation marks with arguments such as "%1" that are
| expanded to strings by the Shell, because you cannot be certain that
| the string will not contain a space.

HP: would you mind to hire just a few people for a little bit of QA?
And some more to teach beginner courses on (Windows) programming to
your developers?

"Long" filenames containing spaces are used in Windows for 20 years
now and your developers still dont get them right?

Stefan Kanthak

JFTR: the driver for the HP OfficeJet 6700 is not the only one from HP
with such a trivial to detect bug and vulnerability.


2014-04-14 sent vulnerability report to vendor

2014-04-14 vendor replies: forwarded to responsible division, will
keep you informed


2014-05-17 request status

2014-05-19 vendor replies: no information from the lab

2014-05-20 vendor replies:
"after looking at this problem and discussing it previously
with Microsoft MSRC, we have decided that this unquoted
registry string is not a security issue.
We are not going to be issuing a patch or security bulletin
for this issue."

JFTR: the vulnerable pathname is NOT in the registry, but in the code!

2014-05-20 report published

[ reply ]


Privacy Statement
Copyright 2010, SecurityFocus