Re: Secure access to system calls for a library?

On Wed, 09 Jun 2004 12:22:02 PDT, Jonathan Leffler <[email protected]>  said:
> How can a library ensure that when it calls getuid(), it really calls the 
> system call and not a dummy provided by the application that is using the 
> library?

For that matter, how do you know that you're not running under a kernel that's
had a loadable module installed?

There's really not much a program can do - at some point it just has to trust
that the kernel and libc.a are trustworthy, and that the sysadmin has taken
proper steps to prevent such issues.

Remember - for this attack to work, the system is already compromised. If it's
a set-UID process, they've already got control of the system. If it's a user
process, they already own you enough to get you to run a program in a subverted
environment.

For that matter, in some operating systems, this sort of "We control the horizontal
and vertical" is a design feature.  For an example, consider IBM's VM series of
operating systems, from CP/67 through VM/370 and VM/XA.  Under those, the
only documented way to tell you are even on a real machine and not in a VM sandbox
is to issue a 'DIAG 0' privileged instruction and rely on the fact that on the
real iron, a 0 subcode to DIAG will get a specification error because IBM never
implemented it on the diagnostic microcode of any production box (other subcodes
would do things like "run POST", "load microcode", and so on in a model-dependent
manner) while if you're running in a virtual machine, CP (Control Program) would
fill in a data block for you with info about the real and virtual hardware.

On the other hand, it's been a bit over a decade, so I've forgotten which
DMKxxx or HCPxxx module one would have to modify - but it shouldn't take a
experienced assembler jock more than an hour or so to find the module and code
up the 4-5 line mod to add the CLC VMUSER(8),=CL8'VICTIM' and the branch on
equal to the place we reflect back a specification error (there's even code in
there already to do that part - you can get a specification interrupt back on a
DIAG 0 if the reply buffer isn't on a dword boundary)...

> [Yes, there is room to suppose that the library is at fault for assuming 
> the getuid() is reliable - but how do you establish the actual identity of 
> the program when getuid() can be subverted so easily?]

You *might* be able to do something with public-key crypto.  However, even
there, it's more likely you can use it to prove the identity of the operating
system to the program than it is to prove the program's identity to itself.

Two things you didn't mention:

1) You could be running under control of a debugger that has breakpoints
set.  It's hard to make any sort of decision in the program if it runs code
evaluating "Do I trust who I am?", coming up with an answer of 'false' -
and then the breakpoint sees the alteration of the variable and smashes
a "true" in there....

2) Remember that even embedding your own assembler code may not
be sufficient - read Ken Thompson's Turing Award lecture "On Trusting
Trust" (http://www.acm.org/classics/sep95/) and realize that even given
the source to your entire compiler toolchain and operating system, you
may not be able to create a trustable binary....

(For the record, the "unknown Air Force document" that Thompson cites is
the Karger&Schell paper on Multics security, available at
http://www.acsac.org/2002/papers/classic-multics-orig.pdf.  They also
did a "30 years later" retrospective paper that's quite a good read as well:
http://www.acsac.org/2002/papers/classic-multics.pdf.  I think both of those papers
are must-reads for anybody subscribed to this list....)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFAydvncC3lWbTT17ARApFZAJ9umRIydpzH8THgMAsUs6W1riCJ4QCg3WHD
3D3o6p6WRFwFQj8ziKOQky4=
=NVkb
-----END PGP SIGNATURE-----