Bugzilla – Bug 404963
VUL-0: CVE-2008-2374: bluez-libs: SDP payload processing vulnerability
Last modified: 2021-08-11 09:14:37 UTC
Hi. There is a security bug in 'bluez-libs'. This information is from 'vendor-sec'. This bug is NOT PUBLIC. There is no coordinated release date (CRD) set. CVE number: CVE-2008-2374 CVE description: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2374 Original posting: ----- Forwarded message from Jan Lieskovsky <jlieskov@redhat.com> ----- Subject: [vendor-sec] CVE-2008-2374 bluez-libs: SDP payload processing vulnerability -- proposed embargo date lift 2008-07-{02,03} From: Jan Lieskovsky <jlieskov@redhat.com> Reply-To: jlieskov@redhat.com To: vendor-sec@lst.de Date: Fri, 27 Jun 2008 15:01:38 +0200 Errors-To: vendor-sec-admin@lst.de Hello vendors, Glenn Durfee from Google has reported the following security issue: Problem description: ==================== Hi all, The SDP parsing code blindly trusts string length fields in incoming SDP packets, exposing reliant applications to over-the-wireless memory manipulation attacks. An attacker need only send a malformed response to an SDP query to take advantage of this. This is most apparent in file bluez-libs-3.30/src/sdp.c, lines 988, 994, 1002 (see below). Also elsewhere in the code where input pointers are advanced without checking bytes remaining to be parsed. The root of the problem is that in bluez-libs-3.30/src/sdp.c:1125, the function sdp_extract_pdu() takes a buffer to parse (in) and a pointer to a length field (out), but it does not take an incoming length field (in). Attached is a patch to fix this issue. Basically I added a "bytesleft" argument to all of the SDP payload processing routines; length fields are checked against the number of remaining bytes to ensure the parser doesn't run past the end of the packet, or do crazy things like malloc two gigs of memory. This touches a lot of places, and changes the external API for SDP payload processing, but I don't see any other way to do this -- the parser MUST be aware of the incoming packet size in order for this to be secure. Glenn Public mention about this issue: http://article.gmane.org/gmane.linux.bluez.devel/15809/ (2008-06-16) ================================ This issue already public, but the detailed information about its security impact not known publit yet, so please handle this as confidential. More details about security impact from Marcel Holtmann: ======================================================== It affects the SDP client functionality and I don't see how you can actually trigger it. The user has to first enter a trusted relationship with the remote device before unexpected SDP transaction will happen and then you can do more harm anyway. The exception is that the user has proximity tool running that scans every device in range, but such things are neither shipped with RHEL or Fedora. However today I realized that there is an issue with the SDP service record registration. As normal user you can register service records via an old Unix socket interface or via D-Bus. Both times you give the record in binary form and since hcid is running as root, this could allow a privilege escalation. All the information from that blog were in the original email from Google and that was also public. The post mentions that you could trigger this remotely. This is a hard stretch since you actually have to construct a scenario for it. BlueZ will not connect to other devices without trusting them by default. So that is impact=low. However the same parsing is used to create service records locally and hence you have a local privilege escalation. That hasn't been mentioned publicly at all. Even I overlooked it in my first review of the patches. Affected bluez-{libs,utils} versions: All before 3.34 ===================================== CVE Id: Please use CVE-2008-2374 for future references to this issue ======= Proposed upstream patch: http://cache.gmane.org//gmane/linux/bluez/devel/15809-001.bin ======================== Proposes embargo date lift: =========================== 2008-07-02 or 2008-07-03 (based on how many time you will need before US public holliday event on 2008-07-04) Additional information: Please note, both of bluez-libs and bluez-utils need ====================== to be patched to resolve this issue (see attachments). Feel free to ask me for any further information if needed Kind regards Jan iankko Lieskovsky RH Security Response Team diff --git a/include/sdp_lib.h b/include/sdp_lib.h index eac2fe6..143056f 100644 ...
Created attachment 225062 [details] bluez-libs.patch
Created attachment 225063 [details] bluez-utils.patch
no needinfo
what about bluez-2.24 (included in SLE10)? I'll shortly attach patches massages into 10.3 and 10.2 and would appreciate feedback...
If bluez-2.24 is affected it needs fixing too.
Created attachment 225161 [details] bluez-utils patch applied to 3.18 (10.3) for 11.0 (bluez 3.32), the original patches worked fine. for 10.3 (bluez 3.18), bluez-lib.patch worked, bluez-utils is adopted like attached. Please review.
Created attachment 225162 [details] bluez-libs patch adapted to 3.7 (10.2) for 10.2, (bluez-3.7) bluez-libs.diff
Created attachment 225163 [details] bluez-utils patch adapted to 3.7 (10.2)
Created attachment 225189 [details] bluez-libs patch adapted to 2.24 (SLE10)
Created attachment 225190 [details] bluez-utils patch adapted to 2.24 (SLE10)
It would be very recommended that somebody double checks that i did not miss anything while backporting the fixes... I submitted packages for: - sle10 (package was not changed since GA, fix should go in SP1 + SP2) - 10.2 - 10.3 - 11.0 FACTORY already has bluez-3.34 I don't know the procedure for security bugs, so please advise.
I am currently reviewing the patches. When you submitted the packages let me know and I'll take care of the rest of the process. The author of the patches mentioned an API change. Will this cause trouble for some of our applications using BT SDP packages?
adopted patches look ok AFAICS
The packages are all in the buildsystem now (already checked in). Tom, Daniel, do you know of any 3rd party programs that might break because of the API changes? Actually they look safe to me, since the new versions are called "$function_safe" (with an additional length parameter), and the old functions call the new ones. The only visible change in include/sdp_lib.h is the removal of "sdp_extract_string" which was not implemented anyway, AFAICS. Some QA, at least on SLE10, probably could not hurt ;-)
> Actually they look safe to me, since the new versions are called > "$function_safe" (with an additional length parameter), and the old functions > call the new ones. So the applications have to change to use the _safe functions to avoid the problem?
Yes. And all users internal to bluez are converted to the _safe functions. I have no idea who is using those functions, it might be you need to be root to use them anyway, but i am really not knowledgeable in that area.
All i know is what they spelled out in this thread: http://thread.gmane.org/gmane.linux.bluez.devel/15809 not much ;-) We could just remove the unsafe versions of the functions and check what breaks, but i'm not sure if that's doable.
@Seife: Do you know which kind of the external bluez API is affected? The only SDP related stuff i'am using in kdebluetooth is GetRemoteServiceHandles in the BT Monitor and in the InputWizard to parse the services of the remote Device. If this method behaves different know i have to touch it.
AFAIK, the BlueZ D-Bus API is not affected by this. Grep'd through all packages which got returned by whatdependson bluez-utils for 11.0 and sle10-sp2. Affected packages: - bluez-utils - .... *still scanning* Maybe we should adjust the patch and set the unsafe functions as deprecated in the header.
Created attachment 225640 [details] script to test if the APIs were used anywhere I checked all distributions (sle10, 10.2, 10.3 and 11.0) with the attached script, and all packages that are shipped by us (and listed in "whatrequires bluez-libs") do not use those functions at all. The only exception is obex-data-server on 11.0, and i will fix this now. BTW: I just checked NLD9. It contains bluez-2.5, but this version had no SDP support at all. So we are fine, and we basically cannot do anything about third-party software, apart from warning in the advisory. So i'll fix obex-data-server now, attach the patch here and submit the package to the build system (only 11.0 affected). Is there any discussion about this going on on vendor-sec?
Created attachment 225651 [details] patch to adopt obex-data-server to the new API I'm actually not sure if this is needed, since obex-data-server gets the SDP data from hcid via DBUS and hcid should not deliver wrong data, but OTOH it should not hurt. Package is submitted for 11.0 and STABLE. Tom, it would be good if you could check if o-d-s still works as it should (i have no idea how to use it ;-)
redhat bug: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2008-2374 is this actually a buffer overflow or just some kind of "read past the end of a buffer and crash" bug? MaintenanceTracker-18489
(In reply to comment #22 from Ludwig Nussel) > redhat bug: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2008-2374 > > is this actually a buffer overflow or just some kind of "read past the end of a > buffer and crash" bug? How should i know?
From the comments in redhat bugzilla, it seems a local privilege escalation is likely.
updates released
CVE-2008-2374: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)