Description of problem: 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. Version-Release number of selected component (if applicable): All versions before bluez-{libs,utils}-3.34 Additional info: Proposed upstream patch: http://cache.gmane.org//gmane/linux/bluez/devel/15809-001.bin
Public mention about this issue: http://article.gmane.org/gmane.linux.bluez.devel/15809/
(In reply to comment #3) > This issue affects the code of bluez-libs as shipped with RHEL-{4,5} and > Fedora-{8,9}. Did you file bugs for the Fedora versions?
bluez-utils-3.35-2.fc9, bluez-libs-3.35-1.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update bluez-utils bluez-libs'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-6133
More information about potential security consequences of this one 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. 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. However the same parsing is used to create service records locally and hence you have a local privilege escalation.
bluez-libs-3.35-1.fc9, bluez-utils-3.35-3.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
bluez-utils-3.35-3.fc8, bluez-libs-3.35-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
This issue was addressed in: Red Hat Enterprise Linux: http://rhn.redhat.com/errata/RHSA-2008-0581.html Fedora: bluez-utils https://admin.fedoraproject.org/updates/F9/FEDORA-2008-6133