illurity-logo
Log in

Site menu:

Categories

Tags

Site search

August 2018
M T W T F S S
« Dec    
 12345
6789101112
13141516171819
20212223242526
2728293031  

Links:

Archives

Tough Love

Techno-eschatologists rejoice! The first sign that the end of days is nigh has come to pass. Lo, we have suffered what the professional fomentor convocation has declared the first significant hypervisor-level virtual machine security exploit: A VMWare Shared Folders Directory Traversal Vulnerability. And with that they reveal that contrived validation is no less sweet than the real thing. Blasphemer! An allegation of exaggeration? Yup. First, because the event has been sensationalized, and second because it’s only a virtualization vulnerability by correlation, not causation.

First, to call this a hypervisor level attack against VMWare is not entirely accurate because it only affected the Workstation, Player, and ACE platforms. Even on affected platforms, it required that shared-folders be enabled, which by default they are not on current versions. It did not affect Server, Fusion, or ESX Server, and since ESX Server is categorically the only true hypervisor (type 1, “bare-metal” hypervisor, the rest are type 2 virtual machine monitors, living atop an existing OS) then this was not a hypervisor vulnerability. Why am I mentioning this? Not to split hairs, but to underscore the fact that the vulnerability exists through an interface of convenience exposed by the VMM application running on the host’s general OS.

Second, to suggest that the augurs were correct and that we’ve seen a failing in virtualization security commits the all-too-common logical fallacy cum hoc ergo propter hoc. Although this occurred on the VMWare platform, it was not caused by virtualization. Rather, it was caused by inadequate input validation – the same root cause of very nearly every exploit ever recorded. The fact that it struck VMWare is coincidental, and the only commentary it makes on virtualization is that it’s been very widely adopted.

So how can we protect against these sorts of weaknesses? Code analysis and fuzzer testing have become table stakes. Any developer not employing such tools should be pilloried for criminal negligence and misfeasance. How about going further, like employing good design principles from the start rather than trying to catch the problems exposed by bad principles in analysis or QA. Anyone writing software should know Saltzer and Schroeder’s eight design principles which summarily prescribe:

  1. Economy of Mechanism – “Perfection is achieved, not when there is nothing left to add, but when there is nothing left to remove.” – Antoine de Saint-Exupery.
  2. Fail-Safe Defaults – Access should be denied by default, and only allowed when an explicit condition is met.
  3. Complete Mediation – Every access to every object should be checked.
  4. Open Design – The strength of the mechanism should not come from its secrecy. Protection mechanisms should be separate from the protection keys. Don’t rely on security through obscurity.
  5. Separation of Privilege – When feasible, access should only be granted when multiple conditions are met.
  6. Least Privilege – Only the minimum necessary access privilege should be granted to users, programs, or any other entity.
  7. Least Common Mechanism – As few entities (functions, programs, users, etc.) as possible should share the protection mechanism to minimize the chance or extent of rejection or corruption.
  8. Psychological Acceptability – Usability to increase the chances of the protection mechanisms being used, and used correctly.

It’s the first one, Economy of Mechanism, that I’d like to focus on here. Did VMWare really need to provide the shared folders feature? Sure, it’s a convenience, but is mapping a drive using the Microsoft/Samba provided and maintained CIFS interfaces that much more difficult? Rather than caving to the demands of an increasingly impatient and entitled base of users (of which I, too, am one), maybe it would make sense for developers to resist the temptation to provide yet-another feature, convenience, interface, exposure, and attack surface to have to protect?

Superfluous convenience breeds dependency and weakness. Maybe someday something will trigger a maturation whereby we become less inconvenience-averse, and we realize that removing functions, machinery, and complexity is a surer path to simplicity and security than irrationally continuing to layer them on.

Share: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Twitter
  • LinkedIn
  • Facebook
  • email
  • Google Bookmarks
  • del.icio.us
  • StumbleUpon
  • Reddit

Comments

Pingback from Worth A Glance » On the Cybersecurity Act of 2009
Time: 2009-05-31, 01:08

[…] 11b and 11c more realistically call for secure coding research and education. 11d asks that grants be awarded for academic innovations in the area of […]

You must be logged in to post a comment.