stack smashing Was: Re: Scanning Formats (TIFF vs. JPEG)

Don THX1138 at dakotacom.net
Sun Aug 20 02:32:30 CDT 2006


Josh Dersch wrote:
> Don wrote:
>> Josh Dersch wrote:
>>> You may be interested in the Singularity project (a research project 
>>> at Microsoft, no less).  It (gasp!) abstracts away pointers; the IL 
>>> used for the entire OS (a subset of the CLR), the OS interface, et. 
>>> al. is designed such that processes can be "proven" to be safe -- and 
>>> all process protection is done _without_ the use of any CPU hardware.
>>>
>>> http://research.microsoft.com/os/singularity/
>>
>> This can only be possible if applications are *interpreted*
>> AND the user is denied *any* means of accessing the underlying
>> hardware (either by accidental or *intentional* means).
>>
>> It's like claiming "run Java/Inferno/etc. on your machine and you'll
>> never have to worry about security issues" (unless, of course,
>> someone boots the machine to a "non-Java" state!)
>
> Or if you, for example, create a CPU that executes IL natively.  See 
> LispMs from the late 70s/early 80s for a different example of this.  
> There's no reason a modern equivalent couldn't be made.

Of course.

> In addition, the applications on Singularity (or Java/.NET today) are 
> not *interpreted*.  They're jitted, which is far more performant.

But the intent was to avoid the "performance penalties"
of using hardware mechanisms.  So, (in existing hardware)
you trade the use of those facilities for the overhead of
an interpreter (regardless of what you want to call it)

> On typical PC hardware, yes, for an OS like this there needs to be an 
> abstraction layer that lies between the "dangerous" physical hardware 
> and the safe IL domain; this abstraction layer can be made very small 
> and as such can be rigorously debugged.  This abstraction layer 
> _completely_ prevents access to the underlying hardware, or other 
> application's process spaces.
> 
> As far as "booting the machine to a "non-Java" state... if you (as an 
> evil haX0r) have physical access to the hardware and can boot the 
> machine to a different OS, then yes, all bets are off... I'm not quite 
> sure what the point of that argument is.

Because most machines nowadays are in the hands of people who
aren't savvy enough to understand these issues.  I.e. you can't
have physical security since there is nothing preventing a
user (*owner*) from circumventing this key step knowingly or
unknowingly.

E.g., any sort of removable media that can be passed control
of the processor outside (i.e., before) the scope of your VM
leaves the system vulnerable.  Hence the reason many PC's
are configured without (or with *disabled*) floppy and/or CD-ROM
drives in business environments.

Getting a robust system into a consumer's hands is considerably
harder than one sitting in a machine room  :>



More information about the cctalk mailing list