[00:00.000 --> 00:01.880]  Everybody hear me, is the first question.
[00:03.180 --> 00:03.620]  Excellent.
[00:04.240 --> 00:10.260]  You might not be able to understand me because I'm English, so if you can't just throw things on, I'll attempt to adapt my accent.
[00:11.740 --> 00:21.860]  Alright, as you can probably tell, if you can read, the title of this talk is The Emperor's Naked, or Breaking Big Iron for Fun and Profit.
[00:23.760 --> 00:25.640]  Why aren't you working now?
[00:28.380 --> 00:29.980]  I'll start again in a moment.
[00:32.240 --> 00:33.120]  What next?
[00:33.400 --> 00:33.780]  Thank you.
[00:34.100 --> 00:34.600]  There we go.
[00:36.720 --> 00:40.000]  So, first question, who am I and what the hell am I doing here?
[00:40.460 --> 00:43.480]  Well, as you can probably tell by the accent, I'm based in the UK.
[00:43.940 --> 00:49.500]  I make a living as a security consultant and generally ask around the world and get paid for it.
[00:50.480 --> 00:57.400]  The genesis of this talk largely is that I'm not actually here to sell anything and I don't actually have anything to prove.
[00:57.540 --> 01:05.000]  I just had an idea or two that I wanted to run past everybody in this room to find out whether or not I am in fact wrong, which I very probably am.
[01:06.700 --> 01:08.280]  So, couple of disclaimers.
[01:09.080 --> 01:17.640]  I don't want to get sued and it's worth pointing out that my current paymasters in no way endorse support or like this talk.
[01:17.640 --> 01:33.420]  Additionally, if you use anything I say during the duration of this talk and end up actually bricking anything that you own or that somebody else owns, I'm not liable in any way, shape, form or legally acceptable sense of the word.
[01:35.120 --> 01:36.760]  So, yeah, another disclaimer.
[01:36.960 --> 01:37.740]  Disclaimers are cool.
[01:39.460 --> 01:43.340]  It's worth pointing out before I start that by trade I'm an application guy.
[01:43.540 --> 01:47.560]  I understand applications, I understand DBs, but I don't understand networks.
[01:49.360 --> 01:59.000]  A lot of the stuff that I'm talking about in this talk is largely a result of being drunk with my friends and basically coming up with idiot ideas which we can't prove one way or the other.
[01:59.840 --> 02:04.180]  And a lot of the material in this is preliminary research.
[02:04.300 --> 02:06.900]  With all that that entails, largely, I can't prove it.
[02:08.460 --> 02:15.280]  So, oh yeah, the important bit on that is if you know any better, let me know because that's the entire point and the entire reason why I'm here.
[02:18.190 --> 02:21.670]  So, what I'm going to be talking about is broken into four areas.
[02:22.950 --> 02:27.630]  One, basically a general introduction to the topic of virtualisation.
[02:28.090 --> 02:32.070]  Two, a breakdown of virtualisation flaws that are known.
[02:32.750 --> 02:36.490]  Three, an interesting idea what I've had.
[02:37.230 --> 02:39.970]  And four, something else.
[02:41.890 --> 02:43.470]  How wide, there we go.
[02:43.470 --> 02:51.110]  So, before we begin, I was working on a client site a while ago and noticed something a little bit weird.
[02:51.630 --> 03:04.870]  The standard logic out there goes that in a Win32 login environment, especially if you're running AD, the maximum password length stroke username length is 127, 128 characters.
[03:07.210 --> 03:16.210]  Unfortunately, in one particular instance, there was no maximum length set in the domain security policy or in Active Directory itself.
[03:16.550 --> 03:27.190]  So, basically what that means in concrete terms is that once somebody's authorised, they can do a password reset, pass any string they want to both a local machine instance and also to Active Directory.
[03:30.790 --> 03:36.010]  What that means in practice is crappy buffer overflow mark 404.
[03:36.330 --> 03:42.190]  If you pass a huge string to AD, it falls over and stops working, which is quite interesting.
[03:43.050 --> 03:52.390]  Got in touch with MS, God knows why, but basically they came back and said, okay, it's not 127, we lied, it's actually 999.
[03:53.550 --> 04:01.630]  At which point I decided to do a lot of cotton pasting, injure my hand, get RSI and get in about 8,888 characters.
[04:01.970 --> 04:06.890]  Went back to Microsoft and they said, please f*ck off now, don't tell anybody about this.
[04:09.010 --> 04:15.850]  So, basically it could be a fault in MS itself, well, Win2K3 anyway.
[04:16.510 --> 04:24.290]  But whatever, it's definitely a fault in that particular instance of domain security policy and probably in the AD config as well.
[04:25.550 --> 04:28.970]  You might be thinking, what on earth has this got to do with virtualisation?
[04:29.490 --> 04:32.310]  But it does have a point and I will get to it later.
[04:32.570 --> 04:38.490]  There's a lot of tangential information in this, or tangential even, but it does all tie up at the end, probably, ish.
[04:39.250 --> 04:39.470]  Sure.
[04:41.150 --> 04:43.170]  Just so you know what I'm talking about, it's that one there.
[04:43.390 --> 04:47.010]  Big thing saying, oops, that's the one they forgot to actually do a check on.
[04:47.230 --> 04:47.930]  Well done, Microsoft.
[04:48.250 --> 04:50.070]  Your QA process is at work there.
[04:52.850 --> 04:54.090]  So, couple of quotes.
[04:54.270 --> 04:55.510]  We like quotes, they're always good.
[04:56.370 --> 05:02.330]  First one from Patrick Lynn, who's the Senior Director of Product Management at VMware, so should know what he's talking about.
[05:02.790 --> 05:05.370]  Namely that virtualisation is both an opportunity and a threat.
[05:05.370 --> 05:11.770]  And one from Albert Einstein, who probably knew a bit more, inasmuch that if we knew what we were doing, it would not be called research.
[05:14.990 --> 05:16.030]  So, to begin.
[05:16.910 --> 05:19.430]  There's a lot of talks out there about virtualisation.
[05:19.690 --> 05:24.010]  In fact, everybody's talking about virtualisation, because it's the latest bandwagon, let's all jump on it.
[05:24.510 --> 05:27.630]  But largely it's, I have found a bug in VMware, aren't I ace?
[05:27.630 --> 05:32.150]  Or, I have found a bug in VMEs or in hypervisors, aren't I marvellous?
[05:33.270 --> 05:36.910]  Because I'm an idiot, I'm going to focus on more than one area.
[05:38.850 --> 05:44.690]  As I say, a lot of talks out there talk about VMware specifically, or if not about VMware, about the whole subject of platform virtualisation.
[05:45.210 --> 05:48.890]  So, app virtualisation, hardware enabled, yadda yadda yadda.
[05:49.830 --> 05:58.110]  I'd like to talk about research virtualisation, which is a bit more interesting because it does things like grid computing and clustering and lots of good stuff like that.
[05:59.690 --> 06:04.190]  So, if I can ever make my mouse work, which is open to the vet.
[06:04.510 --> 06:09.470]  So, platform virtualisation, sure you're all familiar with it, but I'm going to break it down further.
[06:09.670 --> 06:23.150]  Basically, in a typical deployment of virtualised platform instance or instances, you're going to find a combination of virtual machines, guest and host operating systems, virtual machine monitors, hardware, obviously.
[06:23.810 --> 06:27.210]  And, allegedly those are all going to play nicely in a virtual machine environment.
[06:27.630 --> 06:29.370]  Whatever or not they do is open to debate.
[06:30.670 --> 06:36.750]  So, there's been a lot of research out there that's focused on platform virtualisation, which I'll cover off in a bit.
[06:36.750 --> 06:44.290]  But, there's been sod all, or very little, thought or research focused on the security of resource virtualisation.
[06:46.010 --> 06:56.290]  The use of virtual servers, specifically grid computing, is growing, largely because there are a number of economic and business drivers behind it, which suck.
[06:56.750 --> 07:00.190]  But, in the UK, you've got virtual resources, i.e.
[07:00.210 --> 07:03.470]  big of iron, that are being deployed across sectors.
[07:03.890 --> 07:05.770]  So, you've got SCADA systems running it.
[07:05.770 --> 07:13.870]  In the UK, we've got the national grid, which basically powers everybody's house, running on virtualised resources, which is great.
[07:15.170 --> 07:26.050]  In the U.S., which is where I am, you've got virtualised resources, specifically SuperDomes, which are being run by the likes of Continental, Amazon, Talk America.
[07:26.550 --> 07:31.950]  DISA, interestingly enough, and various other dot mill agencies, all run SuperDomes, because they're cheap.
[07:32.130 --> 07:33.150]  Well, for DISA.
[07:33.710 --> 07:42.250]  And both Proxis and Wonderware, which are SCADA systems, can all be melded to fit quite nicely in a virtualised resource environment.
[07:42.510 --> 07:48.150]  So, effectively, you've got national critical infrastructure and defence systems running on big iron.
[07:48.430 --> 07:48.810]  Cal surprise.
[07:51.210 --> 07:54.710]  So, why is it that everybody's using virtualised resources?
[07:55.070 --> 07:57.870]  Well, the bean counters, for one, love it.
[07:58.750 --> 08:00.650]  Largely because it's cheap.
[08:00.850 --> 08:13.910]  Instead of running nice conventional LANs, which everybody understands and everybody knows how to manage, they can basically take a LAN, put it all in one box, hire one administrator to look after that box instead of a team, and they've saved a fortune.
[08:14.570 --> 08:20.930]  The issue they've got is actually deploying it in a sensible and secure manner is a bit of a problem.
[08:22.790 --> 08:31.770]  I'm going to talk about threats in a minute, but it's worth defining what I mean by what constitutes a secure virtual machine environment.
[08:32.210 --> 08:35.650]  Basically, there's a number of my rules, which aren't really my rules.
[08:35.730 --> 08:37.170]  I stole them because I steal everything.
[08:37.170 --> 08:43.710]  Basically, the entire genesis of this is that things have to be kept separate.
[08:44.750 --> 08:46.890]  Platforms and partitions should be kept separate.
[08:47.770 --> 08:52.050]  Specific issues like memory allocation within the stack should be kept separate.
[08:52.350 --> 09:01.250]  It should all be scalable and basically users or other operating systems of guests shouldn't be able to interact with hosts.
[09:02.850 --> 09:08.190]  And most important thing, you shouldn't be able to turn it off easily, shall we say.
[09:08.290 --> 09:17.430]  Because obviously, if you've got medical systems running on it, if you've got minor things like, I don't know, power grids running on it, maybe you shouldn't be able to turn it off.
[09:19.770 --> 09:25.170]  So, I'm going to talk a bit about research that's already been done specifically in relation to platform virtualization.
[09:25.650 --> 09:29.730]  A lot of this you'll already have heard, so feel free to pelt me with eggs and rotten food.
[09:30.770 --> 09:32.550]  New York's expensive, I could do with eating.
[09:33.110 --> 09:37.450]  But yeah, basically, a lot of people have already broken a lot of virtualized environments.
[09:38.010 --> 09:43.450]  There's been a huge amount of research and there still is a lot of research that's focused on VMware specifically.
[09:43.890 --> 09:45.030]  A couple of reasons for that.
[09:45.250 --> 09:46.370]  A, it's cheap to get hold of.
[09:46.510 --> 09:47.710]  B, it's widely deployed.
[09:48.590 --> 09:50.370]  And C, it's quite funny to do.
[09:50.730 --> 09:53.570]  So, quick recap of what's already been done.
[09:55.770 --> 10:02.570]  Before doing that, basically, it's worth breaking what research has been done already into three key areas.
[10:02.710 --> 10:11.150]  Basically, detecting the virtual machine instances, bypassing the protections that are allegedly in place, and then destroying the virtual machine instances.
[10:13.190 --> 10:19.450]  So, everybody who talks about virtualization always uses analogies which don't usually work, i.e.
[10:19.530 --> 10:20.650]  the cave, the matrix.
[10:20.650 --> 10:24.930]  So, I'm basically going to steal the cave one because it's not all sad.
[10:25.570 --> 10:29.030]  But basically, it allows me to make a bum joke and use the phrase, casing the cave.
[10:29.610 --> 10:35.170]  So, there's been a lot of research that's been geared towards detecting virtual machine environments.
[10:36.770 --> 10:40.150]  You can detect virtual machine instances in a number of ways.
[10:41.410 --> 10:43.150]  You can check for running processes memory.
[10:43.410 --> 10:44.690]  You can check for specific reg files.
[10:44.830 --> 10:46.550]  You can look for platform-specific files.
[10:46.550 --> 10:49.390]  And you can look for specific memory artifacts, i.e.
[10:49.550 --> 10:52.670]  the internal table descriptor using check IDT, etc., etc.
[10:53.490 --> 10:55.910]  Problem with that is VMware are getting a bit more wise.
[10:56.090 --> 10:57.950]  And they're actually attempting to build rootkits now.
[10:58.130 --> 11:01.530]  So, finding virtual machine instances is getting a bit trickier.
[11:01.590 --> 11:05.470]  But it still can be done using any combo of those.
[11:06.050 --> 11:11.430]  If you can't be asked if you're a lazy man like what I am, you basically will steal the red pill which Joanna wrote up.
[11:11.650 --> 11:14.610]  Or you can use a host of other tools that exist, i.e.
[11:14.610 --> 11:16.210]  Scrappy Jerrydo, VMDetect.
[11:17.870 --> 11:21.310]  VMDetect is highly entertaining in as much as it's one click and it does it.
[11:22.590 --> 11:25.010]  However, there are more than one ways to skin a cat.
[11:25.250 --> 11:27.730]  And it's an interesting one which nobody's looking at.
[11:30.250 --> 11:33.950]  There's an issue with detecting virtual machine environments at the moment.
[11:34.410 --> 11:37.010]  And quite a major one from an attack perspective.
[11:37.150 --> 11:39.950]  And as much as to detect them, you first have to be authorized to them.
[11:40.270 --> 11:42.730]  Which as a remote attacker is really kind of rubbish.
[11:44.250 --> 11:50.790]  Ed Saunders and the Intel Guardian guys are at the moment looking at pattern IDs in network headers.
[11:52.230 --> 11:54.130]  Really not that necessary, I don't think.
[11:54.430 --> 11:55.530]  Although it's interesting.
[11:55.530 --> 11:57.970]  Yeah, kind of a bit iffy.
[11:58.190 --> 12:03.350]  Basically, another way of doing it is because the timestamps are off in virtual machine environments.
[12:03.390 --> 12:07.050]  You can use those timestamps to ascertain whether you're in a virtual environment or not.
[12:08.810 --> 12:11.450]  The timestamps being awry makes auditing a lot of fun.
[12:11.610 --> 12:14.130]  But it makes discovery a little bit easier.
[12:14.610 --> 12:17.330]  At the moment, there aren't any publicly released tools.
[12:18.090 --> 12:21.530]  But they might be on their way soon depending on whether or not I can be arsed.
[12:22.230 --> 12:26.930]  Okay, so once you've actually established you're in a virtual machine environment, what can you do?
[12:27.870 --> 12:36.650]  Well, at Sansfire last year, July last year, Ed Scudis demonstrated a range of applications concerned with the bypass of virtual machine protections.
[12:36.870 --> 12:38.630]  Which is worth a look in a bit more detail.
[12:39.530 --> 12:47.330]  Right, basically, a number of volumes were found in VM Workstation 4 and 5, and probably in 6, although he's not publicly admitted it.
[12:48.410 --> 12:58.290]  As I'm sure you're all patently aware, VMware's got a comm channel, otherwise referred to as backdoor.io, which allows for the host and the guest OSs to actually talk to each other, which is nice.
[12:58.290 --> 13:07.830]  Basically, what it does is it subverts the x86 instruction set, which is in VMware, and allows for inter-host communication, shall we say.
[13:08.750 --> 13:15.590]  Obviously, that makes the entire concept of memory separation, which is allegedly the point of all this, somewhat redundant.
[13:16.730 --> 13:20.810]  Ed found a number of breakouts without too much effort.
[13:21.090 --> 13:25.570]  And those could be accomplished with or without VM tools actually being installed.
[13:26.770 --> 13:33.890]  Basically, what he did is release a suite of tools, or not release, he talked about a suite of tools, I should say.
[13:34.670 --> 13:39.150]  Namely, VMChat, VMFTP, VMCAT, and VMDragonHack, rather.
[13:41.470 --> 13:44.450]  Basically, I could go over them all in detail, but that's going to be dull.
[13:44.670 --> 13:45.910]  Read the Internet, it's wonderful.
[13:46.470 --> 13:51.450]  Basically, though, VMChat is kind of interesting in as much as it opens up a number of ideas.
[13:51.450 --> 13:58.210]  Basically, what VMChat does is it allows for a chat client to be implemented between guest and host operating systems.
[13:58.710 --> 14:08.950]  Basically, how it does that is it uses a DLR injection attack to allow a buffer to be opened up in the memory space, which can be then used by both instances.
[14:10.830 --> 14:14.990]  Unfortunately, the issue that I've got is that Ed Scudis won't release these tools.
[14:16.290 --> 14:27.010]  He won't share the information or data that he's accrued, which actually generated it, largely because the research that was conducted was sponsored by your very lovely people at the Department of Homeland Security.
[14:27.890 --> 14:34.890]  It's worth wondering why the Department of Homeland Security are actually looking at virtual machines, and whether or not they actually use them themselves.
[14:35.450 --> 14:36.330]  I wonder.
[14:36.670 --> 14:43.490]  So, basically, I decided I wanted to have an attempt at trying to do this, so I looked around for a bit more help.
[14:45.070 --> 14:51.510]  Thankfully, Ed basically, I think, ran across the same person I ran across, which is Ken Kato, who's a Japanese guy.
[14:52.770 --> 15:00.590]  And he released a suite of tools called VMBack, and I suspect that the guys of Core obviously ran across that as well.
[15:01.350 --> 15:06.710]  So, Ken Kato and the people that Ken Kato knows have been looking at the backdoor I/O functions of VMware for years.
[15:10.170 --> 15:24.410]  Basically, by utilizing that inbuilt functionality in VMware, what they've done is developed a number of cross-platform command line based tools, including a generic backdoor that allows for files to be copied between guest and host operating systems.
[15:24.570 --> 15:26.670]  Again, memory separation kind of redundant.
[15:27.350 --> 15:35.750]  And VMFTP, which allows for hosting guests to share files through VM shared folders, which Corelabs recently popped to do their shared folder bit.
[15:38.310 --> 15:42.630]  So, obviously, if you use VMFTP, it may be possible to clone VMChat.
[15:43.210 --> 15:47.230]  All you've got to do is establish a chat server on the host, a client on the guest, and there you go.
[15:47.330 --> 15:47.610]  Job done.
[15:48.050 --> 15:50.190]  I haven't done it yet because, as I said, I'm lazy.
[15:51.310 --> 15:57.670]  If it can be done, though, and there's no reason why it can't, the separation between the guest and host operating systems can be bypassed.
[15:58.170 --> 15:58.910]  You know, simple.
[16:01.010 --> 16:06.430]  So, interestingly enough, destroying virtual environments is a piece of...
[16:06.430 --> 16:09.230]  Well, I would say a piece of piss, but it's a doddle, shall we say.
[16:09.230 --> 16:17.530]  There are a number of tools that Tavish Olmedy's released, most notably Crash Me and IFOs, which basically do what they say on the tin.
[16:18.290 --> 16:24.290]  And there's a group of German researchers called ERNW, which have been building on that research.
[16:24.290 --> 16:27.830]  Although, thanks to the intricacies of German law, they can't speak about it publicly.
[16:28.430 --> 16:28.870]  Marvellous.
[16:29.550 --> 16:38.070]  But, basically, most virtual machine instances, with regards to platform virtualization, can be made to fall over relatively trivially.
[16:40.370 --> 16:46.930]  So, as I said at the start of this, there's been a lot of research that's focused on platform virtualization specifically.
[16:48.070 --> 16:54.090]  There's been a lot of vulnerabilities and tools that have been released, and undoubtedly more will be oncoming shortly.
[16:54.990 --> 17:01.990]  The separation and the isolation that was promised by the deployment of virtual platforms doesn't actually seem to be there.
[17:02.750 --> 17:09.150]  The problem is, though, that that's just one small part of the equation, and as much that, okay, let's look at VMware.
[17:09.550 --> 17:10.850]  But, VMware, no.
[17:11.070 --> 17:14.050]  If you're talking about proper big systems, they aren't using VMware.
[17:14.310 --> 17:16.050]  They're using resource virtualization.
[17:16.170 --> 17:17.310]  They're using big in iron.
[17:17.890 --> 17:19.690]  But nobody's looked at that, really.
[17:21.730 --> 17:23.930]  I'd like to begin with a couple more quotes about this bit.
[17:23.930 --> 17:27.390]  Namely, that looks like the ankle biters have learned to read technical manuals.
[17:27.490 --> 17:28.510]  I am an ankle biter.
[17:28.650 --> 17:30.250]  I have read a technical manual.
[17:30.930 --> 17:37.750]  That, obviously, is from the wonderful Mr. Markoff, which I obviously don't have to go into details at this audience for.
[17:38.110 --> 17:43.730]  And a better quote, or more apt quote for myself, is that there's nothing more dangerous than a resourceful idiot.
[17:43.950 --> 17:45.310]  I am that resourceful idiot.
[17:45.310 --> 17:52.490]  So, this bit's going to be incredibly dull, but I am going to go somewhere with this, I promise you.
[17:52.950 --> 18:01.130]  Basically, it's really, really difficult to talk about virtualized resources without talking about memory design models.
[18:01.450 --> 18:02.510]  Which, fascinating.
[18:02.870 --> 18:03.510]  Sorry about that.
[18:04.390 --> 18:10.730]  One of the most interesting of recent years is non-uniform memory access, or allocation.
[18:11.670 --> 18:16.870]  For those of you that are unfamiliar with virtualized memory architecture, which I was, I'm going to do a quick recap.
[18:17.030 --> 18:22.710]  To those that are familiar with it, I apologize in advance for huge gross technical inaccuracies and generalizations.
[18:23.210 --> 18:26.310]  And as I said earlier, I am going somewhere with this, I promise you.
[18:27.050 --> 18:30.810]  So, basically, simple laws of computing 101.
[18:31.070 --> 18:33.590]  Processors will always run faster than the memory they're attached to.
[18:35.430 --> 18:38.610]  CPUs are going to have to stall and potentially wait for memory access.
[18:39.550 --> 18:46.410]  Basically, to get around that simple equation, a number of projects have been undertaken to allow for high-speed access to memory.
[18:47.470 --> 18:48.690]  Numa is one of many.
[18:48.850 --> 18:52.070]  You've got multics, you've got distributed, shared virtual memory, blah, blah, blah, blah.
[18:53.130 --> 18:56.870]  But what it seeks to do is provide a separate memory instance for each processor.
[18:57.350 --> 18:57.690]  Cal surprise.
[18:59.210 --> 19:04.010]  Numa is not really deployed in real life, basically because it doesn't work.
[19:04.850 --> 19:11.510]  Von Neumann architectural models of coding make the implementation of Numa virtually impossible and nobody's actually done it yet.
[19:12.230 --> 19:19.190]  They have, however, got around the restrictions in place by moving to cache coherent non-uniform memory allocation.
[19:19.890 --> 19:33.450]  Basically, what CC Numa seeks to do is maintain the integrity of data, which is stored in local caches of shared resources, and also the integrity of data that's stored within multiprocessor system memory.
[19:34.590 --> 19:42.290]  It's used in most cluster computing models, and it's also deployed in most virtual resources and servers that are out there.
[19:42.670 --> 19:48.290]  HP Superdomes, PSeries, integrity servers, all of them use the CC Numa model.
[19:49.490 --> 19:56.650]  There's a lot of people that attempt to explain CC Numa by analogy because, again, we're back to the analogous argument.
[19:57.050 --> 20:00.030]  And the example that's always used is cake baking.
[20:00.030 --> 20:03.150]  Now, as a Brit, I don't understand cake baking.
[20:04.250 --> 20:08.050]  Basically, the closest I get to cake baking is using a microwave occasionally.
[20:08.450 --> 20:11.530]  So, I came up with a better one, largely about drinking.
[20:12.990 --> 20:18.070]  So, imagine you want to throw a legendary party or complete a process to put it in CC Numa terms.
[20:18.290 --> 20:21.290]  To do that, you're going to need a lot of beer or memory pages.
[20:21.470 --> 20:24.470]  You can get a lot of beer in your fridge, i.e.
[20:24.470 --> 20:25.090]  in local memory.
[20:25.090 --> 20:30.730]  However, your neighbour has some fantastic vodka that you want to steal and or borrow.
[20:31.230 --> 20:32.370]  That's in remote memory.
[20:32.750 --> 20:37.110]  You want to get drunk quickly, which is kind of the point, so local storage is good.
[20:37.410 --> 20:40.530]  However, you've got a fridge that only holds so much, i.e.
[20:40.530 --> 20:41.510]  physical nodal memory.
[20:41.750 --> 20:45.850]  So, what you need to do is get your neighbour to hold some of your beer whilst you steal their vodka.
[20:45.850 --> 20:48.730]  If local memory is full, allocate memory remotely.
[20:50.050 --> 20:51.530]  See, much better than cake baking.
[20:52.010 --> 20:54.850]  So, as I promised, I am going to go somewhere with this.
[20:55.530 --> 21:02.850]  Basically, I first came across CC Numa in 2007, which is about five years after the rest of the world.
[21:04.170 --> 21:12.110]  As I've said throughout this talk, and I will probably say again, I am an incredibly lazy man and will not learn about things unless I am absolutely forced to learn about things.
[21:12.110 --> 21:24.510]  Basically, how I came across it is that a .gov client in the UK was looking to put nice flat LAN into a single virtualised resource, specifically HP Superdome.
[21:24.870 --> 21:31.910]  The UK .gov client that I am particularly referring to is our wonderful, wonderful NHS.
[21:32.190 --> 21:33.190]  Yes, we have free healthcare.
[21:35.190 --> 21:42.530]  Basically, as you may or may not be aware in the UK, they are currently trying to allow for connectivity between every aspect of the NHS.
[21:42.890 --> 21:50.510]  So, your local doctor's surgery will be able to get your medical records, as will a local doctor's surgery in Azerbaijan.
[21:51.770 --> 21:55.270]  The problem with all that is you need a spine for this data to go over.
[21:55.470 --> 21:58.570]  Those spines have got to be secure and encrypted, which it isn't at the moment.
[21:59.370 --> 22:08.970]  And instead of actually building a nice understandable network that everybody gets, because this is being generated by the private sector, what they are doing is they are looking at cost savings.
[22:09.210 --> 22:12.130]  So, they are putting it all in one box because, you know, that is cheap.
[22:12.410 --> 22:16.870]  We can spend half a million pounds or we can spend lots and lots of millions of pounds.
[22:17.070 --> 22:18.830]  If we spend half a million pounds, we will make more money.
[22:18.930 --> 22:19.810]  Let's put it in one box.
[22:20.730 --> 22:26.470]  As part of that process, idiot boy here to do a risk assessment, hence coming across NUMA.
[22:28.610 --> 22:36.030]  So, it's worth looking at how memory works in a Superdome, largely because that's what I know and that's what I researched.
[22:36.390 --> 22:47.390]  According to the literature that HP themselves have pushed out in terms of their white papers, their marketing stuff and their conversations with me, it works kind of similar to this.
[22:47.390 --> 22:52.790]  Okay, so, you've got multiple processes, four within a cell.
[22:53.050 --> 22:58.070]  You've got local memory, interleaved memory and data communicates via crossbar interfaces.
[22:58.450 --> 22:58.990]  Very dull.
[22:59.830 --> 23:11.270]  So, broken down, as I said, into 64 individual processes within, what, eight cells?
[23:11.390 --> 23:12.330]  No, four cells, I don't know.
[23:12.330 --> 23:12.850]  Yeah, eight.
[23:13.010 --> 23:13.470]  There you go.
[23:14.050 --> 23:21.950]  You've got local and interleaved memory, interconnection via crossbars and IO connections, both within a cell and external to a cell.
[23:23.690 --> 23:30.550]  The important bit of this is that if memory can't write to a local processor cell, it'll try its neighbours.
[23:31.210 --> 23:39.610]  There's allegedly a proviso in the architecture that says that it can't cross more than two crossbars, but there's only four crossbars, so who really cares about that?
[23:41.270 --> 23:45.370]  I could jabber on about locality domains, but they're actually very, very dull.
[23:46.210 --> 23:57.650]  The entire point of locality domains, though, is that the further away a processor is in terms of where it's situated in a cell, the longer it's going to take to read to that and write to that particular cell.
[23:59.870 --> 24:01.070]  So, yeah.
[24:01.510 --> 24:10.270]  Basically, the memory bit's important in as much that you've got local memory instances which are allegedly restricted to the storage of private objects.
[24:10.470 --> 24:12.510]  Whatever those private objects are, who knows?
[24:13.370 --> 24:16.230]  Local memory can be accessed by any processor, however.
[24:16.230 --> 24:23.590]  So any processor that's sitting in a big piece of iron can access that local memory, or the local memory instance of any other processor.
[24:23.890 --> 24:26.890]  The further it is away, the longer it takes, hence Eldon.
[24:28.130 --> 24:35.290]  Interleaved memory stores shared objects and data structures and allows for universal latency across the board.
[24:35.290 --> 24:40.870]  So any processor sat in terms of any cell can access that data relatively rapidly.
[24:42.070 --> 24:44.950]  Interesting thing about interleaved memory is it's accessed in a round-robin fashion.
[24:45.070 --> 24:47.070]  So if you can't get there first, you just go round and round and round again.
[24:48.210 --> 24:51.950]  So, there is a gaping flaw in this, which I kind of spoiled.
[24:52.470 --> 25:03.470]  Namely, if you can access and control one individual processor, you can not only access the memory space of that processor, but all the other processors.
[25:03.830 --> 25:07.370]  Not just within a cell instance, but across the whole virtualized resource.
[25:07.730 --> 25:09.290]  So, classic analogy.
[25:10.010 --> 25:11.890]  Okay, let's say you've got a nice flat LAN.
[25:12.010 --> 25:13.530]  You might be able to pop one box.
[25:13.710 --> 25:14.570]  Great, you popped a box.
[25:14.650 --> 25:14.770]  Woo!
[25:15.930 --> 25:21.990]  You may be able to segue further into that at some later point, elevate your privileges, et cetera, et cetera.
[25:22.750 --> 25:28.590]  Virtual resources, if you own one processor or one box, you own all of them because they all share the same memory.
[25:28.990 --> 25:29.810]  Bit of an issue.
[25:30.650 --> 25:41.330]  So, basically, to break it down in simple terms, instead of injecting malicious code into the memory of one machine, you can now inject malicious code into everything.
[25:42.550 --> 25:53.710]  If an application errors or an error state is created maliciously and becomes a processor hog, and I'm just thinking particularly here about, I don't know, malformed XML just because that's a nice easy one that everybody gets.
[25:54.510 --> 25:56.890]  Basically, more than one processor gets to come to the party.
[25:56.950 --> 25:58.630]  So, the first processor will try and process it.
[25:58.750 --> 25:59.210]  It'll die.
[25:59.330 --> 26:00.150]  It'll go to the next one.
[26:00.450 --> 26:00.850]  It'll die.
[26:01.170 --> 26:01.950]  It'll go to the next one.
[26:02.090 --> 26:02.510]  It'll die.
[26:03.450 --> 26:15.110]  Basically, if you can own a single processor, infect a single processor, or hog the resources of a single processor, you get to actually own, infect, or hog the entire virtual resource.
[26:15.330 --> 26:18.350]  Or, to put it in other terms, the network replacement.
[26:18.470 --> 26:21.150]  Because, as I said earlier, you're basically getting LANs put in boxes.
[26:21.690 --> 26:24.310]  Unlike LANs, you can own the lot just by owning one.
[26:24.730 --> 26:28.210]  Or, to put it another way, fluffy bunny of doom.
[26:32.620 --> 26:34.380]  I apologise for the Python reference.
[26:35.800 --> 26:38.580]  So, the issue is, so what?
[26:38.680 --> 26:39.380]  It'll never happen.
[26:39.760 --> 26:42.460]  Well done, you found an architectural flaw that's never going to be exploited.
[26:42.740 --> 26:48.360]  Well, it's worth looking at where this technology is being deployed, which is why I started with that.
[26:48.940 --> 26:51.540]  If this can't ever be done, great.
[26:51.760 --> 26:55.380]  But it better not be able to be done, because it's running national critical infrastructure.
[26:55.680 --> 26:59.300]  You know, as I said, in the UK, we're putting the National Health Service on there.
[26:59.780 --> 27:01.720]  We've also put the power grid on there.
[27:02.040 --> 27:05.120]  We've also put police command and control on there.
[27:05.360 --> 27:07.380]  We've got various bits of defence on there.
[27:07.500 --> 27:09.140]  In the U.S., you've got various bits of defence too.
[27:09.260 --> 27:09.540]  Well done.
[27:09.960 --> 27:14.700]  But basically, if this happens, we go back to the Stone Age.
[27:15.080 --> 27:16.660]  We can no longer get health treatment.
[27:16.820 --> 27:17.640]  We can no longer fly.
[27:17.660 --> 27:18.600]  We can no longer eat.
[27:18.700 --> 27:20.120]  We can no longer have sanitation.
[27:20.120 --> 27:21.760]  We can no longer go to the doctors.
[27:22.020 --> 27:23.520]  We no longer have health insurance.
[27:24.440 --> 27:27.180]  The military are running around going, where are our orders coming from?
[27:27.200 --> 27:28.080]  It all goes to shit.
[27:28.740 --> 27:29.920]  So it better not happen.
[27:30.200 --> 27:32.560]  So how is it actually being deployed?
[27:32.780 --> 27:39.040]  Well, as I said earlier, basically what they're doing is they're taking normal lands and placing them in a virtual environment, specifically virtualized resources.
[27:39.920 --> 27:46.760]  Unfortunately, what they're doing is instead of using sensible network layer separation, they're using wonderful things like VRF, i.e.
[27:46.760 --> 27:47.820]  virtual routing and forwarding.
[27:49.780 --> 27:54.760]  The problem is, in a lot of instances that I've come across, they're not doing it properly.
[27:54.760 --> 28:00.040]  So instead of having the app layer, the DB layer, the OSI no, no, no, that's a silly idea.
[28:00.160 --> 28:05.040]  What we'll do is to speed up the way that it operates, we'll put the app and DB on the same layer.
[28:05.180 --> 28:05.480]  Wahey!
[28:06.700 --> 28:11.880]  In terms of building in adequate protections, you can't actually do it.
[28:13.580 --> 28:22.420]  I know from my own stuff that I've done, to actually get auditing working in a virtualized resource environment is impossible.
[28:23.480 --> 28:24.520]  Classic example.
[28:24.840 --> 28:33.120]  Different client, not the NHS, basically said, okay, what we want to do, we've got a contract commitment, we've got to order any security related event within 25 milliseconds.
[28:34.900 --> 28:36.000]  You can't.
[28:36.460 --> 28:42.720]  Largely because it takes a long time for the data to go from there to there for you to actually audit it.
[28:43.240 --> 28:51.640]  Actually getting in IDS and firewalls is a pain in the arse because IDS and firewall vendors, for all their nice sticky badge goodness that says this is virtualized ready, aren't.
[28:54.200 --> 29:07.460]  How is it possible to monitor data transactions which may be potentially illegitimate in an environment where basically there's that much data floating around anyway and everybody can access everybody else's memory?
[29:07.580 --> 29:08.120]  You can't do it.
[29:09.180 --> 29:22.480]  Another thing that's happening at the moment and will continue to happen is largely the Bing counters have got involved in this and they've said, okay, we need to deploy, deliver, and get this rolled out as soon as possible because the sooner we get it in,
[29:22.580 --> 29:25.560]  the sooner we start saving cash and we don't have to pay network admins and MRP.
[29:26.500 --> 29:29.360]  The problem is, by doing doing it so quickly, they're overlooking the basics.
[29:29.500 --> 29:30.460]  They're not putting in firewalls.
[29:30.540 --> 29:32.860]  They're putting in virtual routing and forwarding.
[29:33.180 --> 29:37.440]  You know, because you can take care of layer separation just using that, can't you?
[29:37.780 --> 29:40.480]  So you might have a perimeter firewall, but once you pass that, you're in.
[29:40.580 --> 29:42.480]  And you're golden because as I say, you own one, you own the lot.
[29:43.320 --> 29:48.060]  So, the important bit of all this is this is just an idea.
[29:48.180 --> 29:49.440]  I'm not going to release POC.
[29:49.600 --> 29:51.660]  I'm not going to say, here, here's my code.
[29:52.260 --> 29:55.540]  Basically, I haven't done any research on PSeries and I've not looked at some.
[29:56.680 --> 29:57.680]  I'm not saying it will work.
[29:58.240 --> 30:00.060]  Largely because I can't afford to prove it.
[30:01.040 --> 30:13.640]  A Superdome instance, the cheapest I've ever found one, and this was very, very dodgy second-hand, probably fell off the back of a truck on eBay, was about £65,000, which I think is about $4 million.
[30:17.700 --> 30:19.300]  But, yeah, they're not cheap.
[30:19.800 --> 30:24.580]  To buy a new one, you're looking at half a million pounds, so a million quid, or a million dollars, I should say, which...
[30:25.400 --> 30:29.640]  My girlfriend loves me, but I think if I spent that on a computer, she would kill me.
[30:30.120 --> 30:32.900]  And I also can't afford to spend that on a computer.
[30:34.160 --> 30:36.700]  Hence, asking for rotten vegetables earlier so I can eat.
[30:37.560 --> 30:39.480]  But, yeah, basically, they're very expensive.
[30:39.900 --> 30:43.200]  They're very rarely deployed in environments that people can get at.
[30:43.480 --> 30:50.840]  If you actually can get at them, the restrictions that are in place in terms of contracts are, please don't blow it up, it'll cost us a fortune.
[30:52.860 --> 30:59.220]  Because they're so difficult to get hold of, I can't prove this, which makes me feel like an arse.
[30:59.540 --> 31:14.760]  But it also presents a real challenge in terms of securing the memory space of those virtual resource instances, ensuring the isolation, which was allegedly built into virtualization, and also in terms of security research itself, which is why nobody's looking at it.
[31:16.360 --> 31:19.680]  Now, I realize that many of you may have an issue with this.
[31:19.940 --> 31:22.400]  So, I did the reasonable thing.
[31:22.520 --> 31:23.300]  I spoke with HP.
[31:24.540 --> 31:26.200]  They were far from happy with me.
[31:26.480 --> 31:31.000]  Basically, their initial response was, oh, okay, please tell us about it.
[31:31.040 --> 31:31.460]  So I did.
[31:31.600 --> 31:33.640]  And they were like, okay, please stop telling us about it.
[31:33.720 --> 31:34.160]  Please go away.
[31:35.300 --> 31:45.920]  To be exact, what they actually said, and this is the important bit, is CC Numer is more or less vulnerable than the same number of processors associated with monolithic memory.
[31:46.240 --> 31:52.840]  Thereto, if an attacker can get privileged access to a processor, they can write to the memory that all processors share and corrupt their flow of execution.
[31:53.800 --> 32:02.140]  Minor issue with that, inasmuch that in most monolithic memory instances, you've not got your entire network.
[32:02.800 --> 32:05.200]  So, you know, they kind of missed the point.
[32:08.540 --> 32:12.340]  But, HP wouldn't actually tell me what protection mechanisms were built into their stack.
[32:12.480 --> 32:18.000]  I've been talking to IBM a bit lately about their implementation of virtualization.
[32:18.200 --> 32:21.940]  And they're kind of open to talking about the protection mechanisms.
[32:22.320 --> 32:24.020]  But, you know, obviously, they're not public knowledge.
[32:24.140 --> 32:24.980]  Please don't tell anybody.
[32:25.140 --> 32:26.020]  Oh, we'll shoot you in the face.
[32:26.160 --> 32:28.460]  I'm a robot IBM, and we can probably do that and get away with it.
[32:28.880 --> 32:31.460]  HP, on the other hand, basically said, we don't know.
[32:31.720 --> 32:32.920]  They've got it at OS level.
[32:32.920 --> 32:36.840]  It's like, okay, this is why I kind of began with the AD thing.
[32:37.000 --> 32:39.120]  Because AD, oh, AD is wonderfully secure.
[32:39.280 --> 32:40.780]  We can manage our networks using Active Directory.
[32:40.920 --> 32:41.180]  Woo-hoo.
[32:41.620 --> 32:47.920]  But if there's an issue in that, there's probably other issues in OS which are probably just as significant.
[32:49.780 --> 32:56.920]  And if the OS is flaky in terms of virtualized resource, that basically means your entire virtualized resource is toast.
[32:58.100 --> 33:03.180]  As I say, I got in touch with HP, said, excuse me, what protection mechanisms other than the OS have you got?
[33:04.300 --> 33:05.280]  They haven't told me.
[33:06.320 --> 33:07.380]  They still haven't told me.
[33:07.460 --> 33:12.400]  I've spoken to them for about the last six months and annoyed them constantly and consistently, but they won't tell me.
[33:12.540 --> 33:16.280]  And they won't tell me why they won't tell me, which leads me to suspect that there aren't any.
[33:16.540 --> 33:18.240]  Because if there were, they maybe will tell me.
[33:18.760 --> 33:25.060]  Because even, as I say, even IBM have said, oh, no, commercially sensitive, please don't mention it, have told me.
[33:25.520 --> 33:29.760]  HP haven't told me, Which leads me to suspect that their crossbar instances are kind of knackered.
[33:32.280 --> 33:39.240]  So, my issue with this is the entire architectural model is designed by implementation to be open.
[33:39.540 --> 33:42.640]  I.e., processors can access each other's processor's memory.
[33:42.880 --> 33:43.800]  Yeah, that's the point.
[33:44.060 --> 33:48.100]  How does that suddenly become secure and closed and how do you actually lock that down?
[33:48.860 --> 33:54.260]  And the entire point of this is instead of just owning a single processor instance, you actually own a network.
[33:54.260 --> 33:56.120]  You know, that's the point.
[33:57.300 --> 34:02.180]  So, as I said earlier, I really don't like discussing things I can't prove.
[34:03.540 --> 34:05.500]  Largely because I tend to get beaten up.
[34:05.740 --> 34:10.480]  But I've spoken to lots of people about this within HP and external to HP.
[34:10.580 --> 34:13.260]  I've spoken to architects, tech designers, blah, blah, blah, blah, blah, blah, blah.
[34:13.560 --> 34:15.740]  Everybody I've spoken to hasn't disagreed.
[34:15.840 --> 34:17.680]  This is the third time I've given this talk.
[34:19.580 --> 34:22.160]  Hopefully somebody in the room will disagree with me.
[34:22.160 --> 34:26.020]  But the point is, if I'm wrong, I'm at least not wrong alone.
[34:27.700 --> 34:30.880]  The entire point of this is I'm currently trying to get hold of a Superdome.
[34:31.000 --> 34:37.780]  So, if anybody actually knows of a spare Superdome hanging around, if you could let me know about it, that'd be great.
[34:39.420 --> 34:39.860]  Right.
[34:40.620 --> 34:47.400]  As you might have figured out, doing virtualization or implementing virtualization securely is a bit of an issue.
[34:48.420 --> 34:53.440]  It's made more of an issue in as much that researchers are only looking at one area of technology.
[34:53.620 --> 34:55.520]  Either looking at the platform specific stuff.
[34:56.880 --> 34:59.640]  As I said earlier, I know why this is happening because they're just as poor as me.
[34:59.740 --> 35:00.620]  They can't afford it either.
[35:00.860 --> 35:02.300]  But it really doesn't help.
[35:02.420 --> 35:08.660]  Because you're reliant on placing your trust in the likes of HP and IBM and hoping they don't cock it up.
[35:08.660 --> 35:11.680]  Which, not really that comfortable an idea.
[35:13.620 --> 35:19.860]  Point is that reality is now intruding on virtual instances in quite a major and substantive way.
[35:20.640 --> 35:22.640]  There's a lot of organizations out there.
[35:22.900 --> 35:27.300]  Some of which I've mentioned and some of which I'll continue to mention until they have issues with me.
[35:28.200 --> 35:33.560]  That are actually moving towards basically the big iron single box, single point of failure option.
[35:33.560 --> 35:39.620]  Because, you know, unlike network latency, if you bang it all in a Superdome, if your Superdome falls over, you're knackered.
[35:41.920 --> 35:49.440]  In the real world, basically all the separate components of IT infrastructure as it's currently known are being lumped into one resource.
[35:50.040 --> 36:02.260]  So, instead of having an application security manager, a security manager, a network admin, a firewall guy, an IDS guy.
[36:02.260 --> 36:09.500]  Now, basically, you've got one guy who's trying to manage applications, databases, network topologies and components all in one box.
[36:09.720 --> 36:10.680]  Because that's the point.
[36:10.840 --> 36:15.660]  Basically, they want to replace entire networks and entire network support teams with one box, one guy.
[36:15.900 --> 36:18.320]  That will never work because one guy can't understand the law.
[36:18.480 --> 36:20.820]  And if he can, you maybe shouldn't be working for a corporate.
[36:23.100 --> 36:27.900]  Another issue is that layer separation, as I said earlier, is being replaced by VRF.
[36:28.760 --> 36:33.280]  Interestingly, the vendors are all falling over themselves to sell the latest magic bullet.
[36:33.940 --> 36:37.800]  I.e. hypervisors, VMSafe, nice secure firewall, which works with virtualization.
[36:38.000 --> 36:40.380]  We know it works with virtualization because we put a sticker on it.
[36:40.580 --> 36:42.940]  We haven't tested it, but, you know, if it doesn't, please let us know.
[36:43.900 --> 36:46.500]  The problem is, one size doesn't fit all.
[36:47.340 --> 36:52.420]  A hypervisor or VMSafe is great if you're running VMware.
[36:54.580 --> 36:57.620]  VMSafe isn't going to work on a SuperDome.
[36:57.800 --> 36:58.840]  That's not the point of it.
[37:00.980 --> 37:08.160]  Conducting real, credible, admissible, demonstrable research on virtual resources is a colossal pain in the arse as well.
[37:08.320 --> 37:14.260]  Simply because it's beyond most people's budgets and professional access, shall we say.
[37:15.160 --> 37:20.580]  Running assessment applications against virtual resources is not only hard work, it's virtually impossible.
[37:20.800 --> 37:23.380]  I've tried to do it and almost got mad as a result.
[37:24.900 --> 37:29.160]  And implementing protections, such as they are, is even more difficult.
[37:29.340 --> 37:32.980]  Which, you know, may be good or bad news depending on which side of the fence you sit on.
[37:32.980 --> 37:41.240]  So, to the beam counters, virtualization, specifically resource virtualization offers a lot.
[37:42.180 --> 37:47.400]  But from an attack and research perspective, it's largely uncharted territory as far as I know.
[37:47.580 --> 37:49.220]  Anybody in here knows better, let me know.
[37:50.720 --> 37:55.080]  The beam counters aren't considering risk, they're just considering savings and speed of delivery.
[37:56.040 --> 38:00.960]  And researchers, as I say, they're all looking at VM-safe and the likes of hypervisors.
[38:01.060 --> 38:05.200]  I mean, classic example, look at the debacle at RSA between Chris Hoff and Joanna Rutowski.
[38:05.360 --> 38:08.600]  Basically, they both threw their toys out of the pram and said, I'm right, no, I'm right.
[38:08.720 --> 38:12.660]  And it all went a bit gay, basically, but hypervisors don't work anyway, so shut up.
[38:14.540 --> 38:21.760]  But basically, researchers out there need to start thinking about weird areas of virtualization, such as page mapping, bit flipping, memory allocation, yadda, yadda, yadda.
[38:21.880 --> 38:23.120]  Nobody's doing it, because they can't be bothered.
[38:24.700 --> 38:32.620]  From an attack perspective, though, maybe it's time to start cheering, because, you know, there's a lot of very cool stuff running this, which nobody's looking at securing, which is kind of interesting.
[38:35.160 --> 38:39.720]  Yeah, as the old analogy goes, there's no such thing as a secure system.
[38:40.500 --> 38:45.240]  Unless, of course, you bury it and never use it, and, you know, if you're going to use a system, it ain't secure.
[38:45.780 --> 38:51.080]  The problem is, if your system is insecure by design, meh, it's going to get a bit biblical.
[38:52.400 --> 38:59.240]  So, I think, yep, that's just a thanks to people that basically allow me to be here, including my current paymasters.
[38:59.380 --> 39:00.060]  Haha, fools.
[39:01.180 --> 39:04.100]  Right, so, comments, questions, random abuse.
[39:04.460 --> 39:07.300]  I will take them all and deal with them accordingly.
[39:08.600 --> 39:09.100]  Anyone?
[39:09.380 --> 39:09.520]  Hello?
[39:09.840 --> 39:11.700]  Is your presentation available online?
[39:12.140 --> 39:12.640]  Yep.
[39:16.940 --> 39:18.340]  Oh, you want to know where?
[39:21.220 --> 39:22.720]  I'll make it available there.
[39:26.390 --> 39:27.110]  Anyone else?
[39:27.230 --> 39:27.490]  In the back.
[39:32.360 --> 39:34.120]  I cannot hear a word you're saying.
[39:34.120 --> 39:36.340]  Running VMware on the Superdome?
[39:36.740 --> 39:36.760]  Yep.
[39:36.760 --> 39:37.920]  Would that solve the...
[39:39.680 --> 39:40.220]  Why?
[39:42.180 --> 39:44.820]  Because it's sort of what you're talking about.
[39:45.580 --> 39:47.680]  It's separated at the OS.
[39:48.160 --> 39:52.140]  Yeah, but the point is about VMware, which is why I kind of covered it off earlier.
[39:52.380 --> 39:55.360]  It doesn't actually allow any degree of separation at all.
[39:56.120 --> 39:57.560]  By default...
[39:58.520 --> 39:59.580]  Does it, boss?
[40:00.380 --> 40:05.280]  VMSAFE is not going to deal with the crucial fact that they've actually implemented a comm channel to allow it to work properly.
[40:05.960 --> 40:07.740]  And they've still not rectified that.
[40:07.820 --> 40:13.360]  And they might close down one thing, but as Ken Cato's research shows, there's so many instruction pointers in there.
[40:13.520 --> 40:16.020]  If they close down one instruction pointer, you just go to the next one.
[40:17.080 --> 40:33.920]  So, to be honest, the only thing that would actually help is if they actually developed proper security devices for virtual instances, which they're not going to do because at the moment, vendors are running around saying, oh, okay, you're implementing virtualization.
[40:34.080 --> 40:35.340]  We've got a box that can do that.
[40:35.520 --> 40:42.180]  We've got a box that can secure that, which basically is a relabeled Nokia IP390 with a nice little sticker on it saying virtualization ready.
[40:43.200 --> 40:51.960]  Nobody can test it, because as I say, most small vendors, even most big vendors aren't prepared to pay the cost of these instances so they can actually test their own kit.
[40:52.140 --> 40:54.920]  They'll just stick a label on it and hope for the best, you know?
[40:55.700 --> 40:56.080]  Why
[40:59.490 --> 40:59.910]  is your next?
[41:00.090 --> 41:00.390]  Yep.
[41:41.920 --> 41:42.480]  Okay.
[41:43.420 --> 41:44.590]  First one, no.
[41:45.260 --> 41:46.840]  Second one, probably not.
[41:48.550 --> 41:54.900]  Now, to be slightly less flippant, I've not looked at any Microsoft implemented solution largely because, eh, why?
[41:56.550 --> 41:57.800]  Basically, it...
[42:02.500 --> 42:04.040]  Yeah, but it's...
[42:04.040 --> 42:06.860]  If it's anything to do with Redmond, it will probably be insecure.
[42:07.400 --> 42:08.570]  Okay, they've got TPM.
[42:08.820 --> 42:09.360]  Wow, marvellous.
[42:09.400 --> 42:09.720]  Well done.
[42:10.040 --> 42:15.320]  But, by and large, a lot of their kernel design is fundamentally insecure.
[42:15.320 --> 42:19.200]  So, if they carry the same kernel design over to the virtualized space, which they probably have.
[42:19.340 --> 42:22.820]  It's probably insecure by default, just because that's how they run that stuff in Redmond.
[42:23.540 --> 42:31.570]  The second question with regards to switching options on particular chipsets.
[42:31.610 --> 42:32.380]  Yes, it may.
[42:32.380 --> 42:36.050]  But, I'm not sure whether you can do that in Superdomes or the integrity servers.
[42:36.320 --> 42:37.500]  Largely because they haven't got one.
[42:39.820 --> 42:40.720]  It may be there.
[42:40.800 --> 42:41.630]  It may not be there.
[42:41.740 --> 42:42.020]  I don't know.
[42:42.160 --> 42:43.820]  As I say, this is an idea more than anything.
[42:43.820 --> 42:45.840]  Let's talk afterwards about the hardware.
[42:46.550 --> 42:46.900]  Okay.
[42:48.520 --> 42:49.200]  Yep.
[42:49.610 --> 42:53.800]  What do you find as the possible or probable solution might be?
[42:54.050 --> 42:57.260]  Is it stronger OS because it's impossible?
[42:57.540 --> 42:59.680]  Or is it stronger resource management?
[43:00.500 --> 43:03.800]  I think it's stronger actual deployment instances.
[43:03.800 --> 43:16.090]  Basically, as I said earlier, what you've got is a lot of organizations and a lot of private and public entities dashing towards virtualized resources as a way to save cash.
[43:16.440 --> 43:23.720]  Now, one of the ways they're going to save cash is A, getting rid of their conventional network space and B, getting rid of all their conventional network resources, i.e.
[43:23.720 --> 43:24.160]  the people.
[43:24.700 --> 43:30.820]  The problem is, if you get rid of the people, the poor sod that's left after the dramatic call has to manage it all.
[43:31.400 --> 43:32.280]  You can't.
[43:32.780 --> 43:40.520]  You know, no one person can manage applications, can manage security, can manage databases, can manage network topologies, you know.
[43:40.900 --> 43:53.640]  So, if corporates actually looked and organizations adopting it looked at having sensible deployments which were guided by actual sensible implementations instead of just like, let's buy a box.
[43:54.080 --> 43:59.760]  Then, you know, maybe that would be a solution, but they're never going to do that because the vendors have said, buy a box, it'll be great.
[43:59.760 --> 43:59.780]  Okay.
[44:01.360 --> 44:01.880]  Anyone else?
[44:02.060 --> 44:02.180]  Yep.
[44:06.500 --> 44:07.740]  Who shouts loudest wins?
[44:08.460 --> 44:13.800]  Do you see this as a specific hardware problem with the CC new mic computation from HP?
[44:14.540 --> 44:14.920]  Yep.
[44:15.220 --> 44:15.760]  I would.
[44:16.400 --> 44:22.800]  Would you see the same problem as Asian technologies from HP, like M4 and E4?
[44:23.400 --> 44:24.000]  I don't know.
[44:24.080 --> 44:24.820]  I haven't looked at them yet.
[44:27.060 --> 44:33.080]  But yeah, unlike IBM, HP have actually not come back with any details.
[44:33.240 --> 44:36.420]  IBM have said, okay, yes, we recognize this might be an issue.
[44:36.540 --> 44:40.240]  This is why we've got X, Y and Z on the crossbar.
[44:40.540 --> 44:42.960]  HP have come back and said, go away.
[44:43.680 --> 44:45.020]  So, who knows, man?
[44:46.500 --> 44:50.500]  Is there any value to independent evaluation like the common criteria?
[44:51.740 --> 44:58.480]  It depends how you actually conduct those independent evaluations and indeed how independent they actually are.
[44:58.740 --> 45:06.060]  The problem with a lot of vendors in this space is they are going to insist on non-disclosure because of their nature.
[45:06.560 --> 45:09.120]  So, if you've got a non-disclosure agreement, guess what?
[45:09.280 --> 45:12.140]  Even if you find anything or even if you find nothing, you can't tell anyone.
[45:12.660 --> 45:14.900]  And you have to deal with their wonderful, wonderful legal teams.
[45:16.660 --> 45:17.380]  Question here.
[45:18.220 --> 45:18.820]  Sorry, man.
[45:19.080 --> 45:29.100]  If you were to implement a virtualized solution for a company, in a nutshell, I'm sure you can't get into all of it, what would be your most basic recommendation for security?
[45:30.140 --> 45:31.140]  Hire me, pay me.
[45:31.140 --> 45:31.880]  No.
[45:32.320 --> 45:38.120]  In all seriousness, most basic recommendation is don't believe the vendor hype.
[45:38.320 --> 45:39.640]  The vendors will tell you it's secure.
[45:39.780 --> 45:41.760]  The vendors will put a label on that says it's secure.
[45:42.000 --> 45:42.720]  Test it's secure.
[45:46.460 --> 45:47.180]  Anyone else?
[45:47.780 --> 45:48.280]  At the back?
[45:48.420 --> 45:48.520]  Yeah.
[45:51.350 --> 45:52.350]  I haven't looked.
[45:53.970 --> 45:58.770]  I am aware of a few issues, but I haven't actually looked and I haven't actually documented, so I'm not talking about them.
[46:00.230 --> 46:01.550]  Because I can't prove it.
[46:03.670 --> 46:08.630]  You mentioned earlier that the security assessment on VMware is kind of a nightmare.
[46:09.090 --> 46:12.290]  Can you give a brief example of, like, one thing you did or...
[46:12.290 --> 46:16.050]  Now, with regard to VMware, it's not that hard.
[46:17.910 --> 46:23.430]  It's hard if you're coming at it from an aft, but if you've got aft credentials, it's a dodge, because, you know, that's kind of the point of it.
[46:24.070 --> 46:30.790]  It only becomes a problem when you're looking at virtualized resources, which don't do things sensibly.
[46:31.350 --> 46:41.890]  Instead of, as I say, instead of having a nice network topology, which you can understand and which you can grasp and which you've dealt with for years, in a virtualized environment, and specifically virtualized resources as opposed to virtualized platform,
[46:42.270 --> 46:46.310]  you've basically got everything flat because you've got flat memory access.
[46:46.310 --> 46:52.030]  So it's just like, okay, okay, where would be the proxy that would live?
[46:52.210 --> 46:52.870]  I don't know.
[46:53.190 --> 46:56.250]  You know, so you can't map it is the main issue.
[46:56.830 --> 46:58.650]  And if you can't map it, you can't assess it.
[46:58.730 --> 46:59.570]  You've just got to run blind.
[47:01.370 --> 47:02.070]  Anybody else?
[47:21.360 --> 47:22.580]  I didn't get the end of that.
[47:22.740 --> 47:22.800]  Sorry.
[47:24.320 --> 47:31.020]  Where I work, we found that virtualizing only cuts down technician time into half.
[47:33.040 --> 47:36.780]  To be honest, it actually is going to increase technician time in the long run.
[47:38.680 --> 47:44.820]  There's a lot of bullshit that's spoken about virtualization, if you'll excuse the issue, saying, oh, you'll save time, you'll save money, you'll save everything.
[47:45.040 --> 47:54.440]  The problem is because now Bugger actually understands its implementation and because you've got smaller network teams trying to manage and secure those networks, it actually increases the time they spend on those networks.
[47:54.800 --> 48:08.640]  So you may have got a reduction now, and I'd love to hear how you got a reduction offline, but there's a lot of instances where they're dashing around like headless chickens for want of a better expression, trying desperately to understand this heap of pain that they've just been landed with by the bean counters.
[48:10.840 --> 48:11.820]  Anyone else or are we done?
[48:12.100 --> 48:12.180]  Yep.
[48:15.820 --> 48:16.240]  Yep.
[48:17.240 --> 48:19.840]  I'm now looking at virtual apps.
[48:21.580 --> 48:26.980]  More will be forthcoming at some point, I'm sure, when I can actually find time to get out of the pub and actually do it.
[48:28.500 --> 48:29.160]  Anyone else?
[48:31.060 --> 48:31.380]  Yep.
[48:31.620 --> 48:31.780]  Okay.
[48:31.960 --> 48:33.200]  In that case, folks, I am done.
[48:33.320 --> 48:34.360]  Thank you very much for your time.
[48:34.960 --> 48:35.920]  I'm now going for a play.
[48:49.260 --> 48:54.400]  Yeah, I'm hitting up Citrix pretty soon with their, like, their kind of virtual app, you know, the ICH.
[48:54.900 --> 48:58.500]  Do you know anybody that's working in that field or are you hitting it up at all?
[48:58.840 --> 49:01.340]  A lot of the shit, unfortunately, a lot of the shit.
[49:01.340 --> 49:02.880]  There's like eight different ways you can go in there.