Bugzilla – Bug 104357
VUL-0: CVE-2005-2547: bluez command execution
Last modified: 2022-01-06 14:39:36 UTC
We received the following report via vendor-sec. The issue is public. 6 remote non-root user +1 default package -1 default inactive -1 user interaction +1 command execution Total Score: 6 (Moderate) Date: Fri, 12 Aug 2005 09:34:59 +0200 From: Thierry Carrez <koon@gentoo.org> To: vendor-sec <vendor-sec@lst.de>, marcel@holtmann.org Subject: [vendor-sec] CAN assignment for bluez-utils device name validation vulnerability Hello everyone, Please note that following (public) vulnerability in bluez-utils was assigned CAN-2005-2547 : The name of a Bluetooth device is improperly validated by the hcid utility when a remote device attempts to pair itself with a computer. An attacker could create a malicious device name (containing shell escape characters) on a Bluetooth device resulting in arbitrary commands being executed as root upon attempting to pair the device with the computer. Vulnerable: <= 2.18 Fixed in 2.19 Refs: http://www.bluez.org/ https://bugs.gentoo.org/show_bug.cgi?id=101557 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2547 Please use this reference in all communication regarding this vulnerability. -- Thierry Carrez Gentoo Linux Security
From: Mark J Cox <mjc@redhat.com> Actually only 2.16, 2.17, 2.18 were vulnerable
I assume we will make an update for older products? 10.0 will contain 2.19 starting with beta2 if I am correct. I'll think I need a swamp-id for that, do I get it in this case from security-team or from aj?
If we are vulnerable in any released distro then we want to fix it there, yes. http://w3d.suse.de/Dev/Components/Packages/PackMan/pm_pr_fixing_bug.html#pm_pr_fb_bt_security_bugs
Thanks for the link. I especially liked the part "The package maintainer does not need to write patchinfo files, the security team will handle that." :)
SM-Tracker-2029
Thanks. Just for completeness: Is Monday early enough for a Patch for the old versions?
yes
which packages are affected? only bluez-libs?
only bluez-utils , bluez-libs is not affected. unfortunately this means that I have to create patches for each of the affected versions: SL9.0/SLES8-SLEC: 2.3 SL9.1/SLES9-SLD: 2.4 SL9.2: 2.10 SL9.3: 2.15 Simply updating the packages with v2.19 is no option. The patches are already finished, I "just" have to test if build accepts them (which it does) and to check the packages into the autobuild-system, which will happen late today or early tomorrow. BTW the CAN-number seems to be wrong (or I am not allowed to view the bug), but I will include the CAN-number in the ChangeLog-files never-the-less if I don't hear otherwise from you.
/work/src/done/9.0/bluez-utils /work/src/done/9.1/bluez-utils /work/src/done/9.2/bluez-utils /work/src/done/9.3/bluez-utils /work/src/done/SLEC/bluez-utils /work/src/done/SLES9-SLD/bluez-utils This should be all affected distributions.
mls pointed out that the patch is insufficient. '&' needs to be escaped as well.
hmm, wait
no, it's ok security wise. They surround the quoted string with double quotes. therefore only ` $ \ " need to be quoted. Quoting ; and | is not needed. Those characters would show up as \; and \| actually.
So shall we fix the patch by dropping the | and ; lines? (btw, why is tmp of size 497 and why is there a memset instead of *ptr = 0?)
No released distro is actually affected. The function calling popen doesn't read the device name at all so no need to quote it.
i added | and ; explicit by request from upstream. I have to confess I didn't look to close at the patch for the old distros, since the versions there are quite different from the current one the fix from upstream is for. I saw that some old versions might allocate a little bit more memory than needed, but since no other harm should be done (and I wanted to get it out soon) I didn't change much from the original patch for v2.18.
CVE-2005-2547: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)