Bug 452715 (CVE-2008-2374)

Summary: CVE-2008-2374 bluez-libs: SDP payload processing vulnerability
Product: [Other] Security Response Reporter: Jan Lieskovsky <jlieskov>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: bnocera, ddumas, jrb, kreilly, marcel, security-response-team, sgrubb
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-09 09:42:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 452820, 452821, 452822, 452878, 452879, 452880, 452881, 453384, 453385, 453386, 453387, 833879, 833880    
Bug Blocks:    
Attachments:
Description Flags
Fixes for SDP vulnerability in bluez-libs
none
Fixes for SDP vulnerability in bluez-utils
none
Patch for bluez-libs 3.7 in RHEL5
none
Patch for 3.7
none
RHEL-4 bluez-libs patch
none
Patch for bluez-utils 2.10 (RHEL-4) none

Description Jan Lieskovsky 2008-06-24 15:46:38 UTC
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

Comment 1 Jan Lieskovsky 2008-06-24 15:48:05 UTC
Public mention about this issue:

http://article.gmane.org/gmane.linux.bluez.devel/15809/

Comment 7 Bastien Nocera 2008-06-24 17:15:59 UTC
(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?

Comment 24 Fedora Update System 2008-07-06 06:15:11 UTC
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

Comment 25 Jan Lieskovsky 2008-07-08 13:27:33 UTC
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.



Comment 26 Fedora Update System 2008-09-10 06:51:44 UTC
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.

Comment 27 Fedora Update System 2008-10-16 02:09:49 UTC
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.

Comment 28 Red Hat Product Security 2009-01-09 09:42:48 UTC
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