Bugzilla – Bug 336658
VUL-0: HPLIP remote buffer overflow in sane backend
Last modified: 2016-04-15 09:05:14 UTC
The current HPLIP version 2.7.10 in STABLE and on http://download.opensuse.org/repositories/home:/jsmeix/ 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 http://hplip.sourceforge.net/mailing_lists.html or see the "HP Linux Imaging and Printing System (HPLIP) 2.7.10 Release" mail thread at http://www.mail-archive.com/hplip-devel@lists.sourceforge.net/ in particular see this mail: http://www.mail-archive.com/hplip-devel@lists.sourceforge.net/msg00532.html
Why 0666? Shouldn't 0640 root:lp be sufficient? resmgr can grant additional access via ACLs for local users.
"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...
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).
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): /usr/share/doc/packages/hal/spec/hal-spec.html 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.
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 /etc/hal/fdi/policy/10osvendor/70-hpmud.fdi
Created attachment 196351 [details] 70-hpmud.fdi FYI: The 70-hpmud.fd with int_outof which does not work for me.
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).
still open
hmm
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 receipt. 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.
Created attachment 403535 [details] proposed overflow patch .
Sebastian, 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 http://hplipopensource.com/hplip-web/support.html (usually this is public accessible) or did you perhaps already talk to upstream HPLIP?
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.
CVE-2010-4267
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.
Submitted fixed hplip for SLE-11-SP1 in the internal build service to SUSE:SLE-11-SP1:Update:Test via submitrequest 9855.
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 http://en.opensuse.org/Security
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).
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.
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.
Of course I work according to our processes in compliance to our working environment.
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: Summary: 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 where 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
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>
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 https://bugzilla.novell.com/show_bug.cgi?id=593879#c6 http://bugzilla.novell.com/show_bug.cgi?id=593879#c21
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,
Regarding "should hplip3 be on SP1 ?" Vade retro satana! See https://bugzilla.novell.com/show_bug.cgi?id=593879#c6 ------------------------------------------------------------ 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 ------------------------------------------------------------ and https://bugzilla.novell.com/show_bug.cgi?id=511340#c3 ------------------------------------------------------------ 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
So, out of confusion, SLE11-SP1 patchinfos are submitted. Can I submit box as well?
has the CRD passed? I seem to have removed the vendor-sec communiction already.
we proposed Jan 10th, which has passed. you can submit openSUSE fixes now.
Submitted to openSUSE:11.2:Update:Test/hplip via submitrequest 58067 and 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.
Reopening for further processing by the security team...
For the log: Submitted to Printing/hplip via submitrequest 58073 and submitted to openSUSE:Factory/hplip via submitrequest 58075 so that it is not fixed everywhere where it is maintained by me.
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
Update released for: hplip, hplip-debuginfo, hplip-debugsource, hplip-hpijs, hplip-hpijs-debuginfo Products: openSUSE 11.2 (debug, i586, x86_64) openSUSE 11.3 (debug, i586, x86_64)
done
Update released for: hplip, hplip-debuginfo, hplip-debugsource, hplip-hpijs Products: 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)
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".
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. 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?
(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.
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: https://bugs.launchpad.net/hplip/+bug/746814
Weird. Thanks for keeping track.
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