[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Beginners error: Hewlett-Packards driver software executes rogue binary C:\Program.exe

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