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 

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?

   - Andreas

More information about the Vm-dev mailing list