oss-sec mailing list archives
Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution
From: Solar Designer <solar () openwall com>
Date: Tue, 18 Apr 2023 21:28:22 +0200
On Tue, Apr 18, 2023 at 08:13:24PM +0300, 0xef967c36 () gmail com wrote:
On Tue, Apr 18, 2023 at 05:40:16PM +0200, Solar Designer wrote:BTW, even with the kernel bug fixed, there are ioctl number clashes between different devices, so even e.g. isatty(3) is not necessarily safe if called with elevated privileges under a possible confused deputy scenario. Here's strace showing some clashes on older Linux/i386: $ cat isatty.c int main(void) { return isatty(0); } $ gcc isatty.c -o isatty $ strace -e ioctl ./isatty ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0No, there's no clash. That was a bug in strace (fortunately fixed in newer versions). Those values macros are different; and they were ALWAYS different.
Oh, I didn't recall the full story. Thank you for correcting me.
IIRC, I was the one to add this feature to strace 20+ years ago: * Sat Jun 08 2002 Solar Designer <solar-at-owl.openwall.com> - Updated to today's CVS version (post-4.4) with an additional fix for displaying all possible ioctl names when there's more than one match,
So what I did back then was actually work around the shortcoming of older strace not decoding the full 32 bits, which I did not realize was the case.
There was no number clash. That 'foo or bar or quux' "fix" in strace was stupid.
It was indeed stupid of me not to realize what was going on, but the "fix" nevertheless made things slightly better at the time - before it, strace reported an arbitrary one of the 16-bit matches. So in the above example, we could have seen just SNDCTL_TMR_TIMEBASE whereas the program more likely meant TCGETS. It took until 2015 for the proper fix by the new strace maintainer Dmitry V. Levin, now referenced by Ruihan Li in this thread, and that fix involved that "the tools for generating ioctl definitions from kernel headers have been rewritten, and the source format of ioctl definitions has been extended" resulting in "118 changed files with 7,272 additions and 3,004 deletions."
$ cc -xc - <<EOT && ./a.out #include <sys/ioctl.h> #include <linux/soundcard.h> #include <sound/asound.h> #include <stdio.h> int main(int ac, char **av){ printf("%#lx %#lx %#x\n", SNDCTL_TMR_TIMEBASE, SNDRV_TIMER_IOCTL_NEXT_DEVICE, TCGETS); return 0; } EOT 0xc0045401 0xc0145401 0x5401
Yes, these are the values I get on the same old test system as well. So it was indeed just strace not decoding the high 16 bits. Alexander
Current thread:
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution, (continued)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Todd C. Miller (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Ruihan Li (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Todd C. Miller (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Steffen Nurpmeso (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution nightmare . yeah27 (Apr 19)
- Re: Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Steffen Nurpmeso (Apr 20)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution 0xef967c36 (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Ruihan Li (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution 0xef967c36 (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Solar Designer (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution 0xef967c36 (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Steffen Nurpmeso (Apr 18)