Where the risk is with virtualization (and iSCSI)

February 23, 2008

Both virtualization and iSCSI are fundamentally 'sharing' technologies, where multiple things use a shared infrastructure. This means that they have a shared set of general security risks, pretty much common to any sharing technologies: cross-contamination and base system compromise.

Cross contamination is the ability to interfere with other things using the shared environment and to compromise them in turn; having a shared infrastructure necessarily gives you a channel to attack other things that are using that infrastructure. This isn't novel, but virtualization and iSCSI make it worse in that much of the attack surface that they expose is trusted by the underlying operating environment.

(In other words, your SCSI driver is probably less hardened than your network driver.)

Base system compromise is breaking into the base system; for example, escaping virtualization and compromising the host operating system. This is worse than compromising other guest operating systems because the host OS probably has more access than any of the guests do; it may be on special management networks and so on. The same is true of breaking into an actual iSCSI target (and it's almost certainly possible, especially as it's very unlikely that they've been seriously hardened).

(This risk is not new with iSCSI, but it's certainly more accessible now that your SAN infrastructure will be using Ethernet and TCP instead of FibreChannel. And I am pretty sure that iSCSI plus TCP is significantly more complex than SCSI over FC, which increases the attack surface and thus the chance of a problem.)

Written on 23 February 2008.
« Why I am not fond of Ubuntu's management of kernel updates
An idea: only use URL fragments as an implementation detail »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Feb 23 23:40:55 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.