Bug 336658 - VUL-0: HPLIP remote buffer overflow in sane backend
VUL-0: HPLIP remote buffer overflow in sane backend
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: General
Other openSUSE 11.0
: P3 - Medium : Major
: ---
Assigned To: Security Team bot
Security Team bot
maint:released:11.2:37918 maint:relea...
Depends on:
  Show dependency treegraph
Reported: 2007-10-25 09:38 UTC by Johannes Meixner
Modified: 2016-04-15 09:05 UTC (History)
3 users (show)

See Also:
Found By: Development
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

70-hpmud.fdi (2.33 KB, text/plain)
2008-02-21 17:24 UTC, Johannes Meixner
proposed overflow patch (472 bytes, patch)
2010-12-06 10:44 UTC, Sebastian Krahmer
Details | Diff
Why I think that hplip-0.9.7 in SLE10 is not affected (3.14 KB, text/plain)
2010-12-28 15:11 UTC, Johannes Meixner

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes Meixner 2007-10-25 09:38:54 UTC
The current HPLIP version 2.7.10 in STABLE and on
has /etc/udev/rules.d/55-hpmud.rules which has rules to set
the following permissive permissions only for HP printers
and HP all-in-one devices: OWNER="root", GROUP="lp", MODE="0666"

The problem is the read/write access for any user.

On the one hand:
Read/write access for any users is necessary so that any user can
get the device status (e.g. "paper out", "scanner warming up", ...).
To get the device status, a status query must be sent to the device,
therefore write access is needed.

On the other hand:
For MODE="0666" the crucial question is whether or not it is possible
that another user (e.g. someone who is logged in from remote)
can somehow eavesdrop when a document is printed or scanned.

I asked on the hplip-devel@lists.sourceforge.net and got the
following answer:
> Is eavesdropping somehow possible with MODE="0666"?
Given only one process can claim the USB interface for reading or 
writing, and claiming the interface is arbitrated by the kernel, I 
would say no other process could snoop the print job or scan job.
> Could you give me some more details what hpmud does to open 
> the device file so that I can let our security team have a 
> look at it or should they simply check all the files in io/hpmud/?

Yes, all the hplip i/o code is in io/hpmud.

For usb all i/o goes through libusb/usbfs. All read/writes to any
end-point require a claim_usb_interface(). Once the interface is claimed
all i/o to that interface is exclusive (ie: 7/1/2).

Parallel i/o is similar. All hpmud parallel i/o goes through
ppdev/parport. Before any i/o can take place PPCLAIM will claim
exclusive access to the port (ie: /dev/parport0). 
For the full mail thread, see "View the HPLIP-Devel list archive" at
or see the "HP Linux Imaging and Printing System (HPLIP) 2.7.10 Release"
mail thread at
in particular see this mail:
Comment 1 Ludwig Nussel 2007-10-25 09:43:51 UTC
Why 0666? Shouldn't 0640 root:lp be sufficient? resmgr can grant additional access via ACLs for local users.
Comment 2 Johannes Meixner 2007-10-25 10:39:59 UTC
"lp" needs read/write access so that the CUPS backend which
runs as "lp" can send printing data to the device.

Without read permissions even a simple command like "lsusb" cannot
list the device to normal users which may cause unnecessary confusion.
On openSUSE 10.2 and openSUSE 10.3 "ls -l /dev/bus/usb/*/*" shows
read permissions for normal users for all devices.

Therefore it seems "0664 root:lp" is a reasonable minimal default.

Regarding resmgr:
Currently /etc/udev/rules.d/55-hpmud.rules looks like this:
# Check for AiO products (0x03f0xx11).
SYSFS{idVendor}=="03f0", SYSFS{idProduct}=="??11", OWNER=...
# Check for Photosmart products (0x03f0xx02).
SYSFS{idVendor}=="03f0", SYSFS{idProduct}=="??02", OWNER=...
# Check for Business Inkjet products (0x03f0xx12).
SYSFS{idVendor}=="03f0", SYSFS{idProduct}=="??12", OWNER=...
# Check for Deskjet products (0x03f0xx04).
SYSFS{idVendor}=="03f0", SYSFS{idProduct}=="??04", OWNER=...
# Check for LaserJet products (0x03f0xx17).
SYSFS{idVendor}=="03f0", SYSFS{idProduct}=="??17", OWNER=...
I.e. there is no long static list of fixed USB IDs
which is probably outdated when our product is in the shelves.
This way it works even when a new model is connected because
often new models are compatible so that the existing driver
can be used.

If such kind of wildcard match is also possible for HAL/hal-resmgr
we could provide an appropriate fdi file to grant read/write
permissions for local users.

I will check the HAL documentation regarding wildcard match...
Comment 3 Johannes Meixner 2007-10-25 10:43:40 UTC
Regardless of comment #1 and comment #2,
it would be nice (if time permits) to check that the hpmud
device access is always exclusively for only one process
so that eavesdropping cannot happen when two users have
read/write access (regardless how they got this access).
Comment 4 Johannes Meixner 2008-02-01 14:39:36 UTC
Regarding the question in comment #2:

I asked Danny Kukawka and he told me
that wildcard and/or prefix/suffix matching
is not possible for integer values in HAL fdi files
(the HAL key usb_device.product_id is of type integer).

Therefore I must explicitely list all USB device IDs
in a HAL fdi file.

But is is not necessary to have tons of individual
<match key="usb_device.product_id" int="0x0101">
expressions because I can use one single "int_outof" match like
<match key="usb.product_id" int_outof="0xa1b2;0xc3d4;...">
see "Device Information Files" - "Matching"
in the HAL documentation (package hal-doc):

I think I will create such a fdi file automatically during
build of the hplip package (like in bug #298878) as follows:

I can get all known USB device IDs for those devices which
are supported by HPLIP via

tr '[:upper:]' '[:lower:]' </usr/share/hplip/data/models/models.dat \
 | egrep '^usb-pid=[0-9ABCDEFabcdef]+' | grep -v '0000' \
 | cut -s -d '=' -f 2 | sort -u

Currently this results 279 USB product IDs.

Let's see if HAL works with one single "int_outof" match
which consists of 279 entries.
Comment 5 Johannes Meixner 2008-02-21 17:21:38 UTC
Updated HPLIP to version 2.8.2 and submitted tpo STABLE.

int_outof="0xa1b2;0xc3d4;..." doesn't work with HAL
at least not on my openSUSE 10.3 system.

I like to be backward compatible so that I can provide
the same package for 10.3 and FACTORY via our build service.
Therefore I have now separated entries for each model in
Comment 6 Johannes Meixner 2008-02-21 17:24:28 UTC
Created attachment 196351 [details]

The 70-hpmud.fd with int_outof which does not work for me.
Comment 7 Johannes Meixner 2008-02-21 17:28:54 UTC
By the way:
Perhaps HAL works partially and it appends "scanner"
to the info.capabilities for only one first device
which matches to the int_outof list.
But there can be more than one device connected which match
(currently I have three such HP devices connected).
Comment 8 Marcus Meissner 2008-03-31 11:37:58 UTC
still open
Comment 9 Marcus Meissner 2010-11-27 16:04:49 UTC
Comment 10 Sebastian Krahmer 2010-12-06 10:33:15 UTC
This is rather a kernel issue if you can sniff from USB devices.
AFAIK you need usbmon loaded which requires root.
I dont see any sniffing related problems in hplip.

However there is a remote stack overflow in the hplip sane
(backend?) since it requests device status via SNMP remotely
in a LAN which is UDP, replies can easily be spoofed upon

It goes like this:

int __attribute__ ((visibility ("hidden"))) PmlRequestGet( ...)
    unsigned char data[PML_MAX_DATALEN];
    int datalen=0, stat=ERROR, type, pml_result;
    enum HPMUD_RESULT result;
    result = hpmud_get_pml(deviceid, channelid, obj->oid, data, sizeof(data), &datalen, &type, &pml_result);  
    PmlSetStatus(obj, pml_result);

where PML_MAX_DATALEN is 4096.

hpmud_get_pml() calls GetSnmp() with unsigned char message[HPMUD_BUFFER_SIZE]
where HPMUD_BUFFER_SIZE is 8192. It is passed the correct buf_size but
it is never used.  Rather it calls

memcpy(buf, p, dLen);

where buf is a ptr to the 4096 byte stack buffer
and dLen is the return value of GetSnmp() which can receive up
to a bufsize of 8192. So at the end you can copy 8192 bytes into
a 4096 bytes buffer on the stack.
The memcpy() at the end must check against buf_size.
Comment 11 Sebastian Krahmer 2010-12-06 10:44:44 UTC
Created attachment 403535 [details]
proposed overflow patch

Comment 12 Johannes Meixner 2010-12-07 09:09:08 UTC
many thanks for checking it!

Should I report the issue in comment #10 with
the patch in attachment #403535 [details]
to upstream HPLIP via "Report a Bug" at
(usually this is public accessible)
or did you perhaps already talk to upstream HPLIP?
Comment 13 Sebastian Krahmer 2010-12-07 09:38:17 UTC
I would report it to vendor-sec to notify other vendors
and to obtain a CVE and CRD. Will take you in the Cc. Then we
can inform upstream and build new packages meanwhile.
Comment 14 Ludwig Nussel 2010-12-08 06:51:43 UTC
Comment 15 Swamp Workflow Management 2010-12-14 10:10:53 UTC
The SWAMPID for this issue is 37765.
This issue was rated as moderate.
Please submit fixed packages until 2010-12-28.
When done, please reassign the bug to security-team@suse.de.
Patchinfo will be handled by security team.
Comment 16 Johannes Meixner 2010-12-21 13:45:29 UTC
Submitted fixed hplip for SLE-11-SP1
in the internal build service
to SUSE:SLE-11-SP1:Update:Test
via submitrequest 9855.
Comment 17 Johannes Meixner 2010-12-22 08:51:17 UTC
Comment #15 reads that I should
"submit fixed packages until 2010-12-28".

How should I do this for openSUSE products
without making the issue public?

I.e. what is the right project in our internal build service
to submit non-public security issues for openSUSE products?

If there is an article which describes how to do this,
please post its URL - I didn't find one at
Comment 18 Marcus Meissner 2010-12-22 09:04:17 UTC
The deadline requirement is for SLE products.

For openSUSE embargoed issues, please submit them on the day they get public (or when you get back from vacation).
Comment 19 Johannes Meixner 2010-12-22 09:28:03 UTC
For the future it would be very nice to have
internal build service projects for openSUSE products
whereto fixed packages for embargoed issues could be submitted
and tested by our QA in advance so that we have readymade
packages available on the day the issues get public.
Comment 20 Ludwig Nussel 2010-12-22 09:34:46 UTC
There is no QA for openSUSE ...
You could of course manually prepare package in ibs and later copy them over to obs in order to submit from there.
Comment 21 Johannes Meixner 2010-12-22 09:46:14 UTC
Of course I work according to our processes
in compliance to our working environment.
Comment 22 Johannes Meixner 2010-12-28 15:11:17 UTC
Created attachment 406409 [details]
Why I think that hplip-0.9.7 in SLE10 is not affected

See the attachment why I think that hplip-0.9.7 in SLE10
is not affected:


In the hplip-0.9.7 sources:

In io/hpiod/hpiod.cpp
session calls ExecuteMsg with a sendBuf
of BUFFER_SIZE + HEADER_SIZE = 8192 + 4096 = 12288

In io/hpiod/system.cpp
ExecuteMsg calls GetPml with this sendBuf of 12288 
GetPml calls GetSnmp with a message of BUFFER_SIZE = 8192
       and finally it copies the message to sendBuf
       with a prefix which contains 4 integers
                     and a fixed text of 99 characters
       i.e. it copies 99 bytes text
                      + 4 times up to 21 bytes text in case of 64-bit integers
                      + up to 8192 bytes message
                      <= 8375 < 12288
Comment 23 Johannes Meixner 2010-12-28 15:23:25 UTC
If my analysis in comment #22 is correct,
the issue would be fixed since comment #16
for all SLE products which are affected and
maintained by me (according to "is_maintained -a hplip")
i.e. only sle11-sp1.

Please tell me when the issue is public so that I can fix it
also for openSUSE 11.1, 11.2, 11.3, and Factory.

By the way:
Was there already any response from HPLIP upstream
e.g. from Ahmed, Zulfiqar Ali (Zulfi) <zulfiqar.ali@hp.com>
Comment 24 Johannes Meixner 2010-12-28 15:51:44 UTC
I missed some derivative HPLIP packages:

I maintain hplip17 which we provide for SLE10.
Fortunately its code is the same as in attachment #406409 [details]
so that hplip17 in sle10-sp3 should be also not affected.

Additionally we have hplip for Moblin in the IBS:
$ isc search hplip | grep -i moblin
Devel:Moblin:2.0                                         hplip
Devel:Moblin:Test:last_before_removal                    hplip
Devel:Moblin:tag_beforeobs_move                          hplip
SUSE:SLE-11:Moblin:2.0                                   hplip
hplip for Moblin is not maintained by me.

Finally we have hplip3 packages in the IBS:
# Project                          # Package
SUSE:SLE-11:HP-ZIP                 hplip3
SUSE:SLE-11:Update:Preload:2009-A  hplip3
SUSE:SLE-11:Update:Test            hplip3
hplip3 is not maintained at all because "is_maintained -a hplip3"
results nothing which is correct as far as I know, see
Comment 25 Marcus Meissner 2011-01-03 13:36:16 UTC
moblin: dont care
preloads: not important

Then hplip3 is only on sle11 ga, (should it have been on SP1?) and sle11 ga is out of maintainance,
Comment 26 Johannes Meixner 2011-01-04 10:11:07 UTC
Regarding "should hplip3 be on SP1 ?"

  Vade retro satana!

hplip3 was an evil broken-by-intention hack to "solve"
a singular special case issue for a special customer
and is not officially maintained by us (so they said),
see bug #511340 and in particular in bug #511518
hplip3 exists only to provide a more up to date version
for the HP-ZIP preload.

I hope they finally learned their lesson not to provide
a simple version upgrade under a different package name.

hplip in SUSE:SLE-11:GA is version 2.8.7

hplip3 in SUSE:SLE-11:HP-ZIP version 3.9.4b
(the "b" does not mean "beta", it is just a successor of 3.9.4)

hplip in SUSE:SLE-11-SP1:GA is version 3.9.8
Comment 27 Sebastian Krahmer 2011-01-10 11:00:10 UTC
So, out of confusion, SLE11-SP1 patchinfos are submitted.
Can I submit box as well?
Comment 28 Marcus Meissner 2011-01-12 15:31:39 UTC
has the CRD passed? I seem to have removed the vendor-sec communiction already.
Comment 29 Marcus Meissner 2011-01-12 15:43:57 UTC
we proposed Jan 10th, which has passed.

you can submit openSUSE fixes now.
Comment 30 Johannes Meixner 2011-01-13 15:08:43 UTC
Submitted to openSUSE:11.2:Update:Test/hplip
via submitrequest 58067
submitted to openSUSE:11.3:Update:Test/hplip
via submitrequest 58068

The issue is now fixed for all products which are
affected and maintained by me.
Comment 31 Johannes Meixner 2011-01-13 15:09:42 UTC
Reopening for further processing by the security team...
Comment 32 Johannes Meixner 2011-01-13 16:09:04 UTC
For the log:
Submitted to Printing/hplip via submitrequest 58073
submitted to openSUSE:Factory/hplip via submitrequest 58075
so that it is not fixed everywhere
where it is maintained by me.
Comment 33 Thomas Biege 2011-01-21 11:03:58 UTC
From the buffer overflow I get the following CVSS2 base score:
Vector: AV:A/AC:L/Au:N/C:C/I:C/A:C
Score: 8.3
Severity: High
Comment 34 Swamp Workflow Management 2011-01-21 12:16:56 UTC
Update released for: hplip, hplip-debuginfo, hplip-debugsource, hplip-hpijs, hplip-hpijs-debuginfo
openSUSE 11.2 (debug, i586, x86_64)
openSUSE 11.3 (debug, i586, x86_64)
Comment 35 Thomas Biege 2011-01-21 12:19:51 UTC
Comment 36 Swamp Workflow Management 2011-01-21 15:05:27 UTC
Update released for: hplip, hplip-debuginfo, hplip-debugsource, hplip-hpijs
SLE-DEBUGINFO 11-SP1 (i386, ia64, ppc64, s390x, x86_64)
SLE-DESKTOP 11-SP1 (i386, x86_64)
SLE-SERVER 11-SP1 (i386, ia64, ppc64, s390x, x86_64)
SLES4VMWARE 11-SP1 (i386, x86_64)
Comment 37 Johannes Meixner 2011-04-01 12:18:10 UTC
I noticed an evil typo in comment #32 "not fixed" is wrong, correct is:
"it is now fixed everywhere where it is maintained by me".
Comment 38 Johannes Meixner 2011-08-12 14:43:27 UTC
The newest HPLIP 3.11.7 has the issue still not fixed.
My hplip-3.9.8-CVE-2010-4267.patch still applies there.

do you know if anyone from HPLIP upstream is involved
in CVE-2010-4267?

If yes,
I really wonder why HPLIP upstream seems to simply
ignore their security issues, compare
where HPLIP upstream did not respond in any way
for at least one month to their upstream security bug.

If nobody from HPLIP upstream is already involved
in CVE-2010-4267, should I file an upstream security bug
to have them at least informed?
Comment 39 Thomas Biege 2011-08-12 16:53:35 UTC
(In reply to comment #38)
> FYI:
> The newest HPLIP 3.11.7 has the issue still not fixed.
> My hplip-3.9.8-CVE-2010-4267.patch still applies there.

Does it mean the current hplip submission is again vulnerable to this bug?

> Security-team,
> do you know if anyone from HPLIP upstream is involved
> in CVE-2010-4267?
> If yes,
> I really wonder why HPLIP upstream seems to simply
> ignore their security issues, compare
> https://bugzilla.novell.com/show_bug.cgi?id=704608#c10
> where HPLIP upstream did not respond in any way
> for at least one month to their upstream security bug.
> If nobody from HPLIP upstream is already involved
> in CVE-2010-4267, should I file an upstream security bug
> to have them at least informed?

Ok, good idea.
Comment 40 Johannes Meixner 2011-08-16 08:25:35 UTC
The newest HPLIP 3.11.7 sources "as is" from upstream
has the issue still not fixed.
My hplip-3.9.8-CVE-2010-4267.patch still applies
and I do apply it so that our hplip packages
are of course still fixed by our own patch.

Meanwhile Daniel Pielmeier (https://launchpad.net/~daniel-pielmeier)
has already filed an upstream security bug report:

Comment 41 Sebastian Krahmer 2011-08-16 08:37:09 UTC
Weird. Thanks for keeping track.
Comment 42 Bernhard Wiedemann 2016-04-15 09:05:14 UTC
This is an autogenerated message for OBS integration:
This bug (336658) was mentioned in
https://build.opensuse.org/request/show/58067 11.2:Test / hplip
https://build.opensuse.org/request/show/58068 11.3:Test / hplip
https://build.opensuse.org/request/show/58075 Factory / hplip
https://build.opensuse.org/request/show/59006 Evergreen:11.1 / hplip