Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
"My only concern is that it wouldn't work, which I see as a problem."

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.

user:
pass:
register,


 

Please log in.
Before you can vote, you need to register. Please log in or create an account.

Zero-access VM for codecs

Allow custom CODECs without the security risk
  (+4, -1)
(+4, -1)
  [vote for,
against]

Under current Windows multimedia implementations, CODECs for media content have the ability to do anything the underlying user can do. Thus, anyone who uses any multimedia CODECs allows their authors access to their machines.

I would suggest that multimedia CODECs (and various other such code snippets) should be run in a zero-privileges VM. The OS would load the CODEC into memory, create buffer areas sized according to the CODECs requirements, and then call it in a VM that could access nothing whatsoever except its expressly-allocated memory.

The first buffer would contain information about what action was requested of the CODEC; one of the defined actions would be to fill in a buffer with information about its version, memory requirements, etc.

Arranging things in this way should allow considerable protection from either rogue CODECs, or rogue media streams that exploit buffer overflows. A corrupt media stream could crash a poorly-written CODEC, but the most it would be able to do would be to hog memory and CPU time up to specified limits, and generate bogus picture and sound data.

supercat, Dec 23 2005

[link]





      
[annotate]
  


 

back: main index

business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle