[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230418192822.GA2959@openwall.com>
Date: Tue, 18 Apr 2023 21:28:22 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution
On Tue, Apr 18, 2023 at 08:13:24PM +0300, 0xef967c36@...il.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 ...}) = 0
>
> No, 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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
