Re: Buffer overflow/privilege escalation in MacOS X
In-Reply-To: <Pine.LNX.4.58.0312151132450.13512@xxxxxxxxxxxxxxx>
Hi,
It seems that my original message needs some clarification.
Firstly, the demonstration quoted below does not give you a root shell. It
shows that there is a segmentation fault caused by access to invalid memory
region. The root shell in the second part of demonstration is a copy/paste from
another window, where gdb was running.
Secondly, although it is possible to overwrite the stack, it is not that simple
to exploit it because the overflow happens in main(), and there is an exit() at
the end of main(), so the execution is never passed to the address in the
stack. (credits go to @stake, they were first who mentioned it). There may be
a way to exploit, I didn't have enough time for comprehensive analysis.
Thanks,
Max.
>Hi,
>
>It appears that parts of MacOSX that didn't come from BSD are
>not very well written and have significant security issues.
>
>An example is a /System/Library/Filesystems/cd9660.fs/cd9660.util
>utility. It is suid root and it is vulnerable to a classic buffer
>overflow due to the lack of input validation.
>
>Demonstration:
>
>sdsx:/System/Library/Filesystems/cd9660.fs max$ ls -la cd9660.util
>-rwsr-xr-x 1 root wheel 20476 23 Sep 23:53 cd9660.util
>
>sdsx:/System/Library/Filesystems/cd9660.fs max$ ./cd9660.util -p `perl -e
>"print 'A'x512"`
>Segmentation fault
>
>sdsx:/System/Library/Filesystems/cd9660.fs root# gdb -core /cores/core.1405
>./cd9660.util
>[gdb banner here]
>Reading symbols for shared libraries .... done
>Core was generated by `./cd9660.util'.
>#0 0x9000d360 in strcat ()
>(gdb) where
>#0 0x9000d360 in strcat ()
>#1 0x00002b84 in main ()
>#2 0x41414141 in ?? ()
>
>
>
>Thanks,
>
>Max.
>