Fake handles (was: Re: New VMMaker/svn release)
Andreas Raab
andreas.raab at gmx.de
Wed Jan 4 06:41:29 UTC 2006
Hi Dave -
> The fileID is an opaque value that just happens to correspond to some
> data structure that we are not supposed to know about, but it is easier
> to handle the issue in the Win32OSProcessPlugin that to try to design a
> platform independent solution that can be incorporated into FilePlugin for
> all supported platforms.
*Gasp* If I've ever seen "evil" code, this got to be it ;-) Not because
it's badly written but because it's designed to break the (supposed)
encapsulation of the file structure. If the file plugin code ever
changes (such as when removing the fileSize) that code will make the VM
explode.
The main lesson for me here is that if it's *that* easy to fake a file
handle we've got a real problem with security. Basically, all of our I/O
operations are prone to this kind of attack and I don't even want to
think about all of the different ways in which this could be exploited.
In order to fix this, I just added a tiny little hash table to the
windows file plugin which checks whether a file handle is genuine, e.g.,
has been produced inside the the file plugin or not. Since that hash
table is not publicly accessible you can't store into it, thus you can
no longer fabricate a random file handle.
BTW, this is not designed "just so your evil code breaks" - as far as I
am concerned it's actually a *major* step forward towards a secure VM
design because one of the effects this achieves is that the handle
(token) that's used in the plugin is actually a capability to invoke a
given set of primitives and no others, and it is solely at the plugins
discretion which set of primitives to assign to which handle. Nice,
simple, and secure (just as it should be).
One of the effects of that change is that it immediately makes the
session ID superfluous from a security POV. The worst that could ever
happen is that an "old" handle refers to a "new" file (if handles aren't
unique across sessions) but an invalid handle can never be used in any
of these operations. (note that from a security POV an old handle
referring to a new file is indistinguishable from cloning an existing
handle which is something that we don't deal with either right now -
fixing this would be straightforward if we were able to deal with oops
instead of third-party handles but that would require dealing with oop
relocation during GC; ouch).
And now that we got this done ;-) we can start talking about how to
expose the functionality that you need in a nice and cross-platform way.
Like, accessing standard file handles: What's wrong with a
primitiveGetStdFileHandle that takes an integer argument for the kind of
standard handle to retrieve (0 - stdin, 1 - stdout, 2 - stderr)? Sounds
simple enough to me. Any others you'd need?
Cheers,
- Andreas
More information about the Vm-dev
mailing list