Onderwerp: Buffer overflow/privilege escalation in MacOS X

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.

> Date: Mon, 15 Dec 2003 11:54:02 -0800
> From: Max <rusmir@tula.net>
> To: bugtraq@securityfocus.com
> Subject: Buffer overflow/privilege escalation in MacOS X
>
> 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.
>

Indeed. However, due to several mitigating factors, this issue doe not
appear to be exploitable (at least not with any of the techniques I am
aware of). The overflow occurs in main() and there is an unavoidable
exit() at the end of the function. So while you can overwrite the
return stack frame, the process will never use your new value.

Cheers,

Dave G.

In-Reply-To: <Pine.LNX.4.58.0312151132450.13512@fsj.fqfubzr.arg >

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 gd
b 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.
>

--+HP7ph2BbKc20aGI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 15, 2003 at 05:48:21PM -0500, Dave G. wrote:
> The overflow occurs in main() and there is an unavoidable exit() at
> the end of the function. So while you can overwrite the return stack
> frame, the process will never use your new value.

Are you sure about this? exit(3) will perform cleanup functionality with
at least stdio streams before calling exit(2). If FILE * are located in
the same autovariable space as the overflowed buffer, there exists the
possibility those stream pointers have been smashed; if those stream
pointers have been smashed, I would NOT be confident in claiming this
buffer overflow poses no problem.

Remember that the latest OpenSSH vulnerabilities relied on the cleanup
behaviour embedded throughout the code. (A call to a fatal-death
function wasn't as fatal as the name would indicate. Oops.)

--=20
A: No.
Q: Should I include quotations after my reply?

--+HP7ph2BbKc20aGI
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/30Nj+9nuM9mwoJkRAsRjAKCUOQgVIDAqhvnz6+BlOXUbVIMYbA CeKryH
6ikzSQXNyUPKVLfP5XaDO6g=
=nFrV
-----END PGP SIGNATURE-----

--+HP7ph2BbKc20aGI--

On Mon, 15 Dec 2003, Dave G. wrote:

> Indeed. However, due to several mitigating factors, this issue doe not
> appear to be exploitable (at least not with any of the techniques I am
> aware of). The overflow occurs in main() and there is an unavoidable
> exit() at the end of the function. So while you can overwrite the
> return stack frame, the process will never use your new value.
>
But you overflow local varialbles, argc and argv**, so if the program ever
uses it after the overflow, it might be possible to expoit it, _before_
exit().

See: http://www.phrack.org/show.php?p=56&a=5, at the end of "Oily way"
part. We explained there how to exploit a code protected with a compiler
placing a canary word before the RET. Of course a couple of conditions
must be fulfilled.

Regards,

--
Mariusz Wo³oszyn
Internet Security Specialist, GTS - Internet Partners

On Dec 15, 2003, at 2:54 PM, Max wrote:

> 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.
>
[snip]

> 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 ?? ()

Unfortunately, I don't think this is exploitable. main() would have to
blr instead of making a system call to exit() for this to be
exploitable. Additionally, no other calls seem to call any exploitable
functions like strcat or strcpy. This would probably be exploitable if
the function calling it wasn't main().

For what it's worth, the segfault comes from a bad access when strcat
tries to read from 0x41414141 because its source vector gets
overwritten by an earlier strcat (the destination vectors are stored
earlier in memory and can't be overwritten, not that you'd be likely to
be able to do anything with the overwritten vectors since there don't
seem to be any places you can overwrite the stored link register value
- main sticks it in a register, doesn't touch it, and in fact doesn't
even use the saved value for returning, since it calls exit()).