Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Undetectable Rootkits Through Virtualization?

Zonk posted more than 8 years ago | from the two-rooted-plants-die dept.

237

techmuse writes "eWeek has an article about a prototype rootkit that is implemented using a virtual machine hypervisor running on top of AMD's Pacifica virtualization implementation. The idea is that the target OS, or software running on it, would not be able to detect the rootkit, because the OS would be running virtualized on top of the rootkit. The prototype is supposed to be demonstrated at the Syscan conference and the Black Hat Briefings over the next month."

cancel ×

237 comments

Sorry! There are no comments related to the filter you selected.

Undetectable KeithCurtis through virtualization? (0, Offtopic)

Keith Curtis (923118) | more than 8 years ago | (#15632302)

Fuck I hate the Irish

Re:Undetectable KeithCurtis through virtualization (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15632489)

Old bullshit. This has been tried to death for UNIX-OSs. It's impossible to do. If all else fails, you can still look at the sequence of addresses of kernel-funtions.

Besides: rootkits are un-American(tm). Everyone using them is a communist FOSS-monkey or a SONY-gook. Good, honest American basement-dwelling spoilt white trash should stick to playing XBox 360 all day, leaving their sisters and mom's to us black people.

Before people start the Windows flamefest (4, Informative)

Anonymous Coward | more than 8 years ago | (#15632309)


fta:
Rutkowska stressed that the Blue Pill technology does not rely on any bug of the underlying operating system. "I have implemented a working prototype for Vista x64, but I see no reasons why it should not be possible to port it to other operating systems, like Linux or BSD which can be run on x64 platform," she added.

Re:Before people start the Windows flamefest (0, Offtopic)

haroldag (962342) | more than 8 years ago | (#15632395)

You are right, I guess it is in fact a vulnerability of "AMD's SVM/Pacifica virtualization technology", not the OS...

Anyways, "The Black Hat presentation will occur on the same day Microsoft is scheduled to show off some of the key security features and functionality being fitted into Vista."

After reading this, I can't stop imagining

Bill: So you can see the super cool security features bundled with Vista. Click, click, click...
Audience: woooooow...
SCREEN TURNS GREEN
Audience in awe...
Bill: We've changed the Blue Screen of Death. It is now Green, less intrussive.

Sort of like this [google.com] . Can't wait...

Re:Before people start the Windows flamefest (-1)

Penguinisto (415985) | more than 8 years ago | (#15632416)

Agreed to a point. OTOH, at least you'd stand a better chance of catching it in operation on a non-Windows OS, if for no other reason than transparency - No NTFS alternate data streams and the like to hide active processes in.

But yeah, it sounds like a bug in virtualization itself, and not an OS... though the OS can either help hide or uncover it in process.

/P

Re:Before people start the Windows flamefest (0)

Anonymous Coward | more than 8 years ago | (#15632468)

>....at least you'd stand a better chance of catching it in operation on a non-Windows OS, if for no other reason than transparency - No NTFS alternate data streams and the like to hide active processes in.

Mod parent -1, totally clueless. I'm sure some other /.er will be along to tell you why shortly.

Re:Before people start the Windows flamefest (2, Informative)

LiquidCoooled (634315) | more than 8 years ago | (#15632538)

WTF are you on about, this rides BELOW the operating system.

It has no feasible way of detecting this because the host OS runs exacly as it did before completely oblivious that its not sitting on raw hardware.

There is no spoon.

Re:Before people start the Windows flamefest (1)

geekoid (135745) | more than 8 years ago | (#15632572)

Then why do we have soup?

Re:Before people start the Windows flamefest (0)

Anonymous Coward | more than 8 years ago | (#15632760)

That's the least effective attempt at being clever in the history of slashdot.

Spoony (0)

Anonymous Coward | more than 8 years ago | (#15632950)

You think that's soup you're eating?

Let's make this a bit easier to understand. (5, Interesting)

khasim (1285) | more than 8 years ago | (#15632462)

I'm sure someone will correct me if I'm wrong but ...

This is not really different from running WinXP, then installing VMWare Workstation, then installing Win2K in a virtual machine.

The "host" OS is what gets infected. That would be WinXP. Of course nothing running in the "guest OS (Win2K) would be able to detect it. But ... so what? And that would directly contradict their claim:
Rutkowska stressed that the Blue Pill technology does not rely on any bug of the underlying operating system.
There are only three (3) ways for the "underlying operating system" to be infected.

#1. Worm
#2. Virus
#3. Trojan

If we aren't talking "nude pictures of celebrities", then it's either a worm or a virus and both of those are bugs in the OS.

If it's a trojan, then WTF are you doing installing unknown apps on the host OS?

Now, the only way this would be interesting would be if the worm / virus / trojan installed the virtualization software, moved the existing OS to a virtual machine and faked the names of all the interfaces (NIC, IDE controller, etc). If you can do that, VMWare really wants to talk to you.

Re:Let's make this a bit easier to understand. (2, Insightful)

kesuki (321456) | more than 8 years ago | (#15632738)

I'm sure someone will correct me if I'm wrong but ...

There are only three (3) ways for the "underlying operating system" to be infected.

There are only two ways, and you got them all wrong.

1. User/administration Error.

2. Programmer/Developer error.

any remote vulnerabilities fall under 2, and any configuration errors fall under 1. :) you shouldn't have said 'I'm sure someone will correct me if i'm wrong' unless you wanted to be corrected.

Re:Before people start the Windows flamefest (5, Insightful)

timeOday (582209) | more than 8 years ago | (#15632496)

Rutkowska stressed that the Blue Pill technology does not rely on any bug of the underlying operating system.
It's doesn't rely on any bug of the guest operating system, and isn't detectable from the guest operating system. But if something is mitigating access between multiple guest operating systems to hardware, then that thing is itself some sort of minimal operating system, and it is there that the problem lies. As far as the guest operating systems are concerned, this is really more like what would previously have been a hardware hack, in fact it's almost like your healthy computer is running behind a compromised firewall that's sending out the spam or whatever.

Getting to the point, people act as if virtualization simplifies things, But really it's an additional layer of abstraction and complication, another mass of code and/or hardware to go wrong. Now there will have to be software tools to manange this new underlying minimal OS, and maybe virus/rootkit software. I think the applicability will be limited.

Re:Before people start the Windows flamefest (2, Interesting)

MrLint (519792) | more than 8 years ago | (#15632610)

I wonder if you would be able to detect these things by, say, keeping log of the relative offset from address 0 of actual physical ram of the box of say, the top of the kernel stack, or start of userland. If this number changes and there was no mitigating software installed, you might be able to suspect you are running in a VM.

Re:Before people start the Windows flamefest (2, Informative)

dextromulous (627459) | more than 8 years ago | (#15632653)

You would have to be rather closed-minded to think a rootkit would apply only to Windows. From wikipedia [wikipedia.org] :
The term "rootkit" (also written as "root kit") originally referred to a set of recompiled Unix tools such as "ps", "netstat", "w" and "passwd" that would carefully hide any trace of the intruder that those commands would normally display, thus allowing the intruders to maintain "root" on the system without the system administrator even seeing them.

Generally now the term is not restricted to Unix-based operating systems, as tools that perform a similar set of tasks now exist for non-Unix operating systems such as Microsoft Windows (even though such operating systems may not have a "root" account).

said this before (4, Interesting)

dknj (441802) | more than 8 years ago | (#15632321)

Re:said this before (0)

Anonymous Coward | more than 8 years ago | (#15632715)

The blog entry mentioned in the article refers to SubVirt and describes some key differences. Among others, SubVirt requires a reboot and modifications to the disk, while Blue Pill doesn't.

Of course, I should not be surprised to see a comment like that moderated as Interesting instead of Redundant. Who would expect the moderators to read the article before deciding if the comments are relevant or not?

ok, but... (3, Funny)

celardore (844933) | more than 8 years ago | (#15632325)

Who runs anything *real* on a virtual server?

Re:ok, but... (1, Redundant)

drinkypoo (153816) | more than 8 years ago | (#15632352)

Who runs anything *real* on a virtual server?

I wish this hadn't been modded offtopic, because it isn't offtopic. It's just really fucking stupid.

Where's the "-1 Mental Midget with the IQ of a Fencepost" mod option?

Re:ok, but... (1)

mfaras (979322) | more than 8 years ago | (#15632414)

Tom Waits was on a virtualized rootkit caused by alcohol when he wrote that. -- I see friends saying "offtopic" / they really say "I love you"

The piano was rooted, not Tom (0)

Anonymous Coward | more than 8 years ago | (#15632509)

No, actually the piano was hit by the rootkit pretty badly. Tom says that he has nothing to do with it.

Re:ok, but... (1)

teasea (11940) | more than 8 years ago | (#15632451)

Why is it people can't recognize a joke when they see it anymore unless they see the idiot on stage with the googly-eyed expression?

People used to be able to recognize the tone and voice of the written word.

Sigh.

Re:ok, but... (1)

KingSkippus (799657) | more than 8 years ago | (#15632491)

Because you're typing, and you forgot the ;-)

;-)

Re:ok, but... (1)

KingSkippus (799657) | more than 8 years ago | (#15632503)

See? Works every time.

Re:ok, but... (1)

treeves (963993) | more than 8 years ago | (#15632619)

I got it, cuz it said "*real*", not "real".

Re:ok, but... (1)

A beautiful mind (821714) | more than 8 years ago | (#15632439)

Hey Stef, your post seems familiar [userfriendly.org] .

Everyone but you... (1)

KingSkippus (799657) | more than 8 years ago | (#15632477)

I don't know about your company, but I work for a giant Fortune 100 multinational company, by far one of the largest and most profitable and recognizable ones in the world. I'm very familiar with our computing environment, and I can tell you with absolute certainty that running applications on virtual machines is not only common here, it's a very important part of our future.

Yes, real applications, the kind that are business critical.

Is it a smart move? Maybe yes, maybe no. If you want to argue about it, go for it. (I don't really care one way or another.) But is it happening? Hell yeah, it already has.

Re:Everyone but you... (0, Offtopic)

celardore (844933) | more than 8 years ago | (#15632643)

I work for a massive global company. I bet it's bigger than yours (three letters), but that's not the point. We run on thin clients and it is fucking awful! There's so much downtime it's unreal. I started at the company and we had 486 boxes and CRT monitors (granted the new LCD ones are a godsend), but everything ran perfectly then. They introduced remote computing, Citrix and all that stuff. I don't think they realised the 'small details' they would be impacting. For instance, before the 'upgrade' if the network went down, we could write some letters, work on some spreadsheets etc... Now with the new 'upgrade', if the network goes down, we can't do anything. Not even write a letter, send an email, none of that stuff....

Virtualisation is NOT the way forwards, it's actually a hinderence to most common business-use functions. For so many reasons. For some reason, networks go down at least twice a week. (In several companies I've worked for)

Re:ok, but... (3, Interesting)

Scooter (8281) | more than 8 years ago | (#15632495)

Sadly, and in a large part due to the way commercial IT is funded, this can actually look good on paper - to the technology accountant: "as many servers as we like, that can be created and destroyed at will? Yes please". We also need virtual finance teams, virtual staff, virtual customers - hell don't bother running a real business at all - just model the entire thing, and play it like a RTS sim - with your score linked directly to the corporate stock price!

Technology finance will cretae some bizarre technical solutions, if sombody in the organisation doesn't put the brakes on - another good example is "hmm terminal server runs all the same apps that native desltops do for the remote workers - let's just issue everyone a Windows TS "device" and host everyone's sessions inside a big servers in the data centre - it's cheaper, and there's no difference right? This is where someone gets to try and explain latency, and how it's different from "bandwidth", to an accountant :D "yeah but we just paid for a 1 Ooodlegig/s line - it'll be super quick!"

It's not new either - mainframes have operated like this for years. IBM would have you create your entire data centre inside z/VM - including the routers, switches and firewalls. It's great for development and testing - need more Linux/Apache/WAS/Oracle servers? sure just wish 3 more into existence, re-test your fancy shmancy clustering and treacle bending widget, and then bin them off again with another wave of the virtual wand.

We have clusters of Websphere AS inside one LPAR - not for speed I hasten to add - that would be silly, but to create resilience, seperate the Java VMs and add flexibitlty for software releases.

Re:ok, but... (1, Funny)

Anonymous Coward | more than 8 years ago | (#15632748)

Are you kidding? Virtually everyone!

Re:ok, but... (1)

the_humeister (922869) | more than 8 years ago | (#15632785)

Oh, I don't know, perhaps people who use Java or Perl?

Is it *really* undetectable? (1, Insightful)

etymxris (121288) | more than 8 years ago | (#15632340)

Can't you just take the hard drive out, mount it from another computer, and see all the malicious DLLs the rootkit was trying to hide from you?

Re:Is it *really* undetectable? (1)

heauxmeaux (869966) | more than 8 years ago | (#15632350)

Holy Fuckin Shit!

Oh, wait - what?

Re:Is it *really* undetectable? (-1, Redundant)

Anonymous Coward | more than 8 years ago | (#15632374)

Can't you just take the hard drive out, mount it from another computer, and see all the malicious DLLs the rootkit was trying to hide from you?

Uh, sure, I guess you could. I think that most users would not be receptive to having to remove their hd's every day, mount it in a seperate computer to do a rootkit check though.

Re:Is it *really* undetectable? (-1, Redundant)

Anonymous Coward | more than 8 years ago | (#15632399)

Why not boot from a live cd? Assuming the rootkit did not mess with your bios too ...

Re:Is it *really* undetectable? (1)

etymxris (121288) | more than 8 years ago | (#15632680)

Why is this overrated? Article proudly announces "100% undetectable". Well, I just gave an example of how it could be detected, so the article is wrong.

the side effects are detactable (4, Funny)

Anonymous Coward | more than 8 years ago | (#15632378)

Current virtualization doesn't virtualize anything but basic VGA graphics. That's certainly noticable.

Boss asks: are you playing games at work?!

Me: Just checking for rootkits boss!

Re:the side effects are detactable (1)

WilliamSChips (793741) | more than 8 years ago | (#15632636)

Oh, I'm sure you could just make them see the actual hardware for the video card, just not for anything else

Re:the side effects are detactable (1)

enosys (705759) | more than 8 years ago | (#15632810)

Yeah, to make this truly undetectable you would need to provide access to some hardware. That is not straightforward. Some drivers deal with physical memory addresses. Physical addresses seen from a guest operating system might not correspond to actual physical addresses. Also this is an area where virtualization overhead might be significant and easy to detect.

Re:the side effects are detactable (1, Informative)

Anonymous Coward | more than 8 years ago | (#15632860)

If I can see the actual hardware for the video card than I can detect the trojan by DMA. If I get cleaver enough, I just might be able to remove it.

Besides, wouldn't I see it by machine total RAM shrinking?

Motherboards already block this... (4, Informative)

Manip (656104) | more than 8 years ago | (#15632386)

Some, albeit high end, motherboards support a visual warning message that alerts the user to a program, or the OS trying to modify the boot sector on the hard disk. If you had this enabled it would stop this rootkit dead in its tracks. It's just a shame that more bioses / motherboards don't offer this support by default.

If you have this on your motherboard I highly recommend you turn it on, it isn't too often that you reinstall the OS and pressing F9 isn't that much of an inconvenience even if you did it once a day.

PS - All of the "My favorite OS is secure" posts below this are wrong if the Operating System supports some type of driver, or root program (running in the kernels memory space).

Re:Motherboards already block this... (1)

IHateChoosingAName (976267) | more than 8 years ago | (#15632429)

I don't know all the details, but didn't some old bioses let you get past that boot sector write warning by inserting the appropriate character into the keyboard buffer before attempting the write and therefore fooling the bios into thinking the user had pressed the key to allow the write?

Re:Motherboards already block this... (4, Informative)

SillyNickName4me (760022) | more than 8 years ago | (#15632471)

Hmm.. I have quite a pile of system boards here, dating from old 486 systems upto p4 and athlon xp, with ami, award, phoenix and biosses, and all of them have the boot sector virus protection option (tho sometimes just called virus protection).

This offers at best a partial protection. While the MBR is important, the actual boot is done from the partition boot record, mot the master boot record, and this badly named feature is not going to help against that. Why badly named? because it does monitor (attempted) changes to the bootrecord and doesn't know anything about viruses.

Next. even if you could protect against that, things just get a bit more OS and possibly OS version dependent because you have to move to the file that gets loaded by the partition bootrecord.

Oh, quite a few 'boot managers' change the mbr on every boot.

So while it offers some protection, that protection is extremely limited, and can be quite inconvenient.

Re:Motherboards already block this... (2, Insightful)

enosys (705759) | more than 8 years ago | (#15632673)

I thought this only trapped writes which were done through the BIOS. Modern operating systems deal with the hardware directly. That is much harder to trap.

Re:Motherboards already block this... (2, Interesting)

utlemming (654269) | more than 8 years ago | (#15632674)

Well yes and no.

There was a proof of concept virus that has the ability to use the ACPI interface to take over the BIOS.

If you could that virus with the root kit that uses virtualization, the computer is now completely hosed. The only way to fix it is to flash the BIOS, and if it first takes over the BIOS and prevents the warning dialogs then virtualizes the OS, you now have an incrediably powerful malware that can only be stopped when it is run on the computer. If you don't detect the malware out the gate, then you may or may never know that you have a problem.

The problem that computer security is having is that the people that can develop this stuff are not stupid. And it is rather hard to forecast what is going to happen with out knowing what the malware people are planning on.

Essentially this problem is going to result in the implementation of signed code for anything that runs outside of a very limited sandbox. Frankly, I think that we are going to see an era of virtualized everything -- where the hardware runs a hypervisor, with a master kernel, and everything else runs in the context of a virtual machine that groups simular resources. Unsigned code would then be run inside of its own virtual machine using a microkernel that links to the master kernel. Or something like that.

This just reinforces the good old principle (5, Insightful)

A beautiful mind (821714) | more than 8 years ago | (#15632411)

If your system suffered a successful intrusion, you wipe.

Of course, there were LKM rootkits (pretty hard to detect) for a good while now, this is just taking it to an all new level.

I wish the spread of better hidden rootkits on Windows, because only that will further sane security policies and wipe the stupid idea of virus scanners out (when it's doing IDS not IPS). There ain't such thing as 'intrusion removal'. It's like putting on a condom after sex. Oh wait, it's slashdot. Let me rephrase. It is like trying to recover data from /dev/null.

Re:This just reinforces the good old principle (1)

sweet 'n sour (595166) | more than 8 years ago | (#15632631)

If your system suffered a successful intrusion, you wipe.

The trick, of course, if knowning when you've suffered a successful intrusion. The whole point of this exploit is not to be detected in the first place.
I still don't see how this or any other rootkit can get past a clean bootdisk + scan, like Bart's PE for Windows, or something like rescue disk + chroot + rpm -qV for linux.

BartPE http://www.nu2.nu/pebuilder/ [nu2.nu]

Re:This just reinforces the good old principle (0)

Anonymous Coward | more than 8 years ago | (#15632853)

Well if you could rootkit the firmware (updatable BIOS for example) you could force externally loaded OSes to run in virtualization.

1) Computer power on
2) rootkit bios start
3) rootkit bios calls rootkit host OS (from firmware or hardrive if there is not enought space in the firmware)
4) rootkit host OS loads the first bootable device as guest to itself ... not easy, probably not feasible for more than an specific machine you know a lot about, but yet posible.

Re:This just reinforces the good old principle (2, Insightful)

DrSkwid (118965) | more than 8 years ago | (#15632813)

Wiping isn't necessarily going to help. The BIOS could have been compromised and the virtualization taking place there.

Many a BIOS already contains a pile of crap :

ACPI
USB
IPMI 2.0
SATA
Infiniband

On the GX2, the BIOS is a message-passing microkernel that lives in SMI !

Wonder how your USB keyboard can be used before the OS is loaded :

> The implementation is chipset dependent. Often what happens is
> that the chipset recognizes an I/O request to port 0x60 or 0x64 and
> aborts the request with an SMI (system management interrupt). This
> is a *very* non-maskable interrupt (more non-maskable than NMI...)
> that causes the processor to save pretty much all its register state
> in a special memory area, and jump to a handler in the system BIOS.
> The BIOS SMI handler examines the saved register state, figures out
> what the OS was trying to do, runs a software model of the PS/2
> keyboard controller's state, chats with the USB keyboard, formulates
> an appropriate response, emulates the I/O instruction the OS was
> trying to do, and resumes execution of the OS at the instruction
> following the I/O instruction.
>
> Some chipsets might do it directly in hardware rather than using
> the SMI+BIOS strategy.

http://groups.google.com/group/comp.os.plan9/brows e_thread/thread/4c154a61f5bf15fa/5b9040b5d3e3fcfe? lnk=st&q=group%3Acomp.os.plan9+SMI%2BBIOS&rnum=1#5 b9040b5d3e3fcfe [google.com]

Re:This just reinforces the good old principle (1)

Alsee (515537) | more than 8 years ago | (#15632937)

It's like putting on a condom after sex. Oh wait, it's slashdot. Let me rephrase. It is like trying to recover data from /dev/null.

So you're saying there's a '/dev/random/' for sex that will (eventually) work?!

-

Virtualization not so virtuos since conception (0)

Anonymous Coward | more than 8 years ago | (#15632415)

Thats the reason of all that institucional "support"

A win-win situation for everyone (3, Funny)

KingSkippus (799657) | more than 8 years ago | (#15632423)

From TFA:

Rutkowska says of the Blue Pill concept, "I am very excited about the chance to work with Sony on how this technology can be used to protect their next generation of music CDs, DVDs, and high-definition Bluray discs. I believe it will be a win-win situation for everyone involved. Well, everyone important, anyway."

Not much less detectable (4, Insightful)

mrcaseyj (902945) | more than 8 years ago | (#15632428)

I don't think this changes the situation much. Viruses have always tried to hide. This just requires different methods to detect them. Ultimately some viruses can only be reliably detected by booting off of readonly media. The same now as before. I think OS providers should provide a boot disk for routine scanning as a matter of standard procedure.

Maybe it's time for some new paradigm (4, Insightful)

supradave (623574) | more than 8 years ago | (#15632434)

Perhaps there could be an OS that wouldn't allow malware to be injected through root-trust, signed applications, memory compartmentalization with read, write, execute permissions and 4 privilege levels (instead of 2). Of course, that wouldn't be Windows or Linux or BSD or any other generic OS.

Re:Maybe it's time for some new paradigm (1)

PB_TPU_40 (135365) | more than 8 years ago | (#15632545)

Intel supports the 4 privilege levels, however the problem is if you want to write portable code, you are not guarneteed to have 4 levels. I'm not sure if AMD supports 4 levels, if someone knows please post, I do know for a fact that PPC is 2 levels though. The main problem as you can see, is to create an OS that starts using the features, which have been availiable from Intel for a while, you limit the processors it will run on without putting forth some considerable work.

Re:Maybe it's time for some new paradigm (1)

Al Dimond (792444) | more than 8 years ago | (#15632656)

Any processor that's an x86 clone has the 4 privilege levels. AMD's x86 processors should for that reason. I think AMD64 does, too, but I haven't actually read any documents on it.

It certainly is possible to make an OS use more than 2 privilege levels on x86 (a dude I knew in college modified Linux thusly; lots of very frequently-used kernel code and drivers needed modification and IIRC all the userland programs were unmodified because it all runs in ring 3 anyway). As far as portability goes... Linux was originally intended to be an implementation of a Unix kernel for 386. There's no absolute requirement that kernels are as portable as Linux has grown to be.

Re:Maybe it's time for some new paradigm (1)

PB_TPU_40 (135365) | more than 8 years ago | (#15632869)

I know it is, the privilage levels have been around since the 386. They certainly could have written XP, Vista, and even 2000 so that the system would support the ring security model. Its a matter of 1, someone finally doing it, and 2 doing it in such a way that it can easily be adopted. Rewriting every driver, and any other system level item isn't an easy adoption.

A good method to still even maintain portability is to have it as an optional compile, so if you were going to run on a 2 ring processor you could. I dont really see this happening anytime soon, they've ignored this feature for how long already?

Re:Maybe it's time for some new paradigm (1)

orasio (188021) | more than 8 years ago | (#15632783)

I'm not supporting the idea of creating a new OS, at least it could be a way of getting a microkernel architecture.

AST used your same argument, saying that Linux wouldn't be popular, partly because only people with 386 processors could use it.
You just need to make it available for reasonably widespread hardware.

Re:Maybe it's time for some new paradigm (1)

operagost (62405) | more than 8 years ago | (#15632599)

Sounds like VMS.

Re:Maybe it's time for some new paradigm (1)

molarmass192 (608071) | more than 8 years ago | (#15632852)

and 4 privilege levels (instead of 2).

Well, OS/2 (0/2/3) and Linux on Xen (0/1/3) both use 3. If you can take control of the hardware via a Xen-ed kernel, now that would be one for the hacker hall of fame.

Real Beneficiaries of Hardware Virtualization... (3, Interesting)

Anonymous Coward | more than 8 years ago | (#15632446)

So, just as you would expect, the future of having CPUs with hardware support for virtualization will be wonderful for preserving absolutely perfect security and cloaking for rootkits and their owners. In fact, thinking of why a certain class of non-blackhat beneficiaries would very much like such a possibility, this could be why both Intel and AMD are planning to ensure that all future CPUs, including even those in ordinary non-server desktop PCs, will have compulsory (permanently enabled) hardware support for virtualization. You know the routine - think of the children etc etc.

Is this a "root kit"? (2, Interesting)

TheConfusedOne (442158) | more than 8 years ago | (#15632447)

Technically it's not rooting an OS but actually is almost it's own OS (hypervisor actually) that is running the OS in a virtual machine. Couldn't you get the same effect by hacking BIOS?

While the subject is scary (2)

Goblez (928516) | more than 8 years ago | (#15632449)

Is this really a surprise? Given the layered design of software, if you have something that can sit between the hardware and the software (and monitor what passes between, and control said information), they why would it not have complete control? The question is how could this easily be placed on someone's machine? The next question is why can a level of virtualization be introduced between the operating system and the hardware during execution?

"your operating system swallows the Blue Pill and it awakes inside the Matrix controlled by the ultra thin Blue Pill hypervisor. This all happens on-the-fly (i.e. without restarting the system)"

Brilliant (1)

illuminatedwax (537131) | more than 8 years ago | (#15632454)

The Matrix has you.

livecd (1)

Billly Gates (198444) | more than 8 years ago | (#15632458)

Microsoft already working on one to address teh issue. I dont know if you have to pay additional money as MS hinted that ms antivirus will be a subscription service.

Running everything off a livecd is a good idea since most infected pc's are as slow as a 486 and could take hours to days to scan. In this case it would be ineffective.

I wonder if bios virii are next/? Its the only way to go above even booting off a pc and some malware and spyware makers are working on this. That way it can't be removed at all. Claria should be taken out to a field and shot.

Towards a runtime for Voight-Kampff machines (2, Funny)

Elwood P Dowd (16933) | more than 8 years ago | (#15632478)

"Is this testing whether I'm a virtual machine or a lesbian, Mr. Dowd?"

The only defense (0, Troll)

rufusdufus (450462) | more than 8 years ago | (#15632518)

I've been telling people this for a while, mainly to blank stares; you cannot detect if you have a virus/keylogger/spyware on your system. All those utilities people pay so much for are worthless! They only detect the known malware, but nobody knows about the undetected hacks. The technology discussed in this article has been around for longer than the OS's have been!
You must assume in this day and age that if your computers will become infected with undetectable malware within a relatively short time of normal internet connectivity.
Accepting this then, the only truly safe way to compute today is to keep your boot/OS/application drive from being writable. Baring this, the next best step is to re-image your drive from non-writable media daily. Throw away the expensive antivirus scanners, they do nothing.
Are you staring blankly at me? Did you know that you can reimage your drive in 5 minutes and guarantee your computer is clean? Thats far less time than it takes a scanner to scan ineffectively your system files. The main trick is to boot from a DVD and to store the image on an external harddrive. And to use a certain discipline in creating incremental images that keep them malware free. This, along with a firewall, is the only reliable defense today.

Re:The only defense (1)

geekoid (135745) | more than 8 years ago | (#15632537)

that is not true.
All thr AV companies have labds where they make new exploits. Then design a way to detect that TYPE of exlpoit.

Besides, have software to protect your systems helps with the know problems bouncing around out there even if not the zero day ones. Fortuasntly there aren't a lot of zero day issues.

Re:The only defense (1, Funny)

Anonymous Coward | more than 8 years ago | (#15632836)

Are you staring blankly at me?
No, I'm staring at you like you're an effing loon who doesn't know what the hell he's talking about.

Re:The only defense (1)

OverflowingBitBucket (464177) | more than 8 years ago | (#15632911)

I've been telling people this for a while, mainly to blank stares; you cannot detect if you have a virus/keylogger/spyware on your system .... They only detect the known malware, but nobody knows about the undetected hacks.

Not true.

Many detection tools will look for specific signatures of known exploits. Thus this part of the detection will not detect anything else. We're in agreement up to this point.

However...

There are other means of detection. One can look to see if certain system calls have been hooked in some way, files placed in certain places, alternate calls to read the same file return different results, system behaviour typical of an exploit, so forth. Code sequences with known execution times can be run and if the results are too far off, you know something is up. Network traffic can be examined on the machine and passively tapped just off the machine, and the difference can be enlightening. Even if your malware author is a certified genius and masks every single possible activity (ha!), then how on earth are they going to hide the CPU power required to implement it? And so on and on...

I'd be surprised if there were many modern anti-malware utilities that didn't implement a few of the more basic generic checks. Your assertion is not true.

Heck, even in this case, bugs in the implementation of the virtualisation can be used to detect if we're running or not. Code sequences exist that can detect whether you're in a virtual machine by the subtle differences between a true machine and a virtual one. Look at VMware I/O addresses and drive IDs, for example. Any difference between the _huge_ interface between virtual machine and the real machine can potentially be tested for and used for detection.

Re:The only defense (1)

nincehelser (935936) | more than 8 years ago | (#15632934)

>Accepting this then, the only truly safe way to compute today is to keep your
> boot/OS/application drive from being writable. Baring this, the next best
>step is to re-image your drive from non-writable media daily.

You'd certainly get a blank stare from me.

That's not very practical. Depending on your OS and partioning scheme, you would be losing logs, patches, and preferences with each re-image.

A better approach is to start with a clean system, run something like tripwire, and keep an eye out for unusual changes.

The only way to really know your hands are clean (1)

nickheart (557603) | more than 8 years ago | (#15632944)

You need to only use the hot water.
You need 12 bars of new, still in shrink-wrap, soap.
You need to rub 1 min under water per bar of soap.
.....wee bit paranoid?

Re:The only defense (1)

SwashbucklingCowboy (727629) | more than 8 years ago | (#15632964)

They only detect the known malware

That isn't correct. Today's top of the line security software can detect threats that have never been seen before. It works by detecting behavior, not signatures.

Microsoft (1)

Psionicist (561330) | more than 8 years ago | (#15632524)

I remember an article a couple of months ago where Microsoft employees had done something similiar, that is using virtualization to create a low level rootkit.

Because, y'know, the only way to protect yourself against attacks like these are with Trusted Platform Modules.

20 bucks Microsoft sponsored this research in some way.

Re:Microsoft (1)

dfn_deux (535506) | more than 8 years ago | (#15632682)

mod parent up. insightful! It had not occured to me that this is a good argument for "trusted computing platforms". although if the virtulization engine is one of the existing players from vmware, MS, etc I imagine it would alright be "certified" for the platform as the major users of these types of applications are corporate in nature and would require all those hoops to have been jumped through PRIOR to purchasing and implementing these types of software solutions.

So what? (1)

tidewaterblues (784797) | more than 8 years ago | (#15632528)

I don't think that anyone is suprised by this. After all, it is common sense that the virtual OS's security is at the pleasure of the host, in much the same way that the security of a user-mode process is at the pleasure of the operating system. If there is anything between you and the actual naked hardware, then there is always the possiblity that that layer is doing something with your data that you don't lie.

No surprise (0)

Anonymous Coward | more than 8 years ago | (#15632548)

If you ran a VMWare image, and inside it ran a virus scanner, could you expect the scanner to detect viruses outside the image, in your hosting OS?

Since the VM is simulating all privileged instructions, the undetectability really isn't a surprise.

What's really impressive is that she has a way for a user mode program to reach between the OS and hardware and lift Vista onto a VM all without rebooting. Her Blackhat session will prove interesting.

The Reverse: Using Host to Protect Virtual Servers (1)

seawall (549985) | more than 8 years ago | (#15632575)

This is regarding Linux rather than Windows but:

Host machine with Vserver kernel running Tripwire or Aide
    with configuration adjustments to detect changes in client "machines"

Host machine well protected
  client machines doing ftp or web services or email or.....

Although Vserver is particular to Linux: Other schemes doing
reasonably strong virtualization can also do the job in Linux,
Solaris (Zones), BSD (Containers), Windows, etc.

It should greatly decrease the ability of something as clever as
BluePill to do damage if it was infecting a well-partitioned virtual
machine rather than a regular machine.

Vserver: http://linux-vserver.org/ [linux-vserver.org]
AIDE: http://www.securityfocus.com/infocus/1424 [securityfocus.com]

oh fuck! (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15632579)

I rooted a girl called Kit the other night! Oh man!

TPM (1)

throx (42621) | more than 8 years ago | (#15632593)

This is actually the good side to the Trusted Platform Module - you can set up your machine to refuse to boot, warn you, whatever if anything in the boot process changes. As it's implemented in BIOS with hashing of the boot process before it even loads it from disk, there's no real way around this short of having physical access to the machine and turning off the TPM.

The bad side of the TPM is when you lose control of it - then the machine isn't yours any more but the xxAA's.

OT: Regarding Sig (1)

DamnStupidElf (649844) | more than 8 years ago | (#15632700)

Your sig isn't scary, it just returns an error code of 0 (Success) to DOS. I'd be more worried about INT 13 calls...

This is exactly why Linux supports 'TPM' modules. (0)

Anonymous Coward | more than 8 years ago | (#15632955)

Yes I understand that TPM module is redundant as saying ATM machines.

People have know this for YEARS.

TPM is designed to create a tamper-proof non-virtualizable.

You see it goes like this:

Microsoft says to the hardware manufacturers:
"I want you to create these extensions to your motherboards and cpu chips that will allow use to run a protected virtual machine environment for our 'Palladium' project."

They (MS, Intel, AMD, and friends) thought about it for a while and said:
"Being about to provide a 100% virtulized environment for x86 can cause problems. If it's 100% compatable then end users won't be able to tell if they are running in a VM or not. This can lead to security problems. Also we need a way to ensure that Palladium and the system kernel as well a potentionally other software can be proven to be unmodified for security reasons and to impliment more efficient DRM controls"

"TPM will be specificly be designed not be virtualized so that software can tell if it's running in a VM or not. Otherwise it's impossible to tell."

(Palledium was a sort of protect-mode operating system running seperate, but inside of Windows Longhorn for implimenting more efficeient security and DRM controls. They were going to use a virtual machine environment and x86 is difficult to virtualize with speed.. so Microsoft had vendors change how x86 works.)

A year or two later AMD and Intel say:
"Good day Microsoft! We have implimented what you told us to do to run the next generation software! Intel has done VT and AMD has it's Pacifica technology. WOOT!"

Microsoft says:
"Sorry folks. Longhorn has most of it's features on the chopping block and palladium didn't make it"

Xen + Linux VM people said:
"Holy shit! This VT and Pacificia stuff rocks, we want to use it to make our para-virtualization technic work without having to modify the kernels of the operating systems running in the VM!"

Intel + AMD:
"Fuck ya! Here is a bunch of money and documentation. We will help make Xen work efficiently and we have all these other ideas on how to furthur virtualize the I/O of PCI devices and other things and the Linux kernel is perfect for this sort of thing!"

Xen/Linux folks:
"Cool (linus quietly adds support for various TPM hardware into 2.6.12)"

Vmware folks:
"Hey we can use this shit too"

Microsoft:
"Oh-oh shaggy, maybe forcing the hardware makers to bend to our designs then abandoning them wasn't a good idea..."

"Hey! Folks! over hear! We have this virtual server thing, we will release it for free although since it's obviously inferior to Vmware various and usefull VM enterprise server products. No need to look over there, those hippy fucks don't know what they are doing and it's hard to use"

(this has been dramatized slightly for Slashdot-friendly appeal)

Is the solution DRM? (0)

Anonymous Coward | more than 8 years ago | (#15632595)

This idea has been discussed on slashdot before, and it seemed that the consensus was only DRM would be able to thwart this strategy.

Which is kind of interesting, since DRM otherwise sucks.

Your thoughts?

DRM as in Trusted Computing that is... (0)

Anonymous Coward | more than 8 years ago | (#15632644)

For clarity, I mean the technology behind DRM, namely trusted computing and signed executables.

Re:Is the solution DRM? (2, Insightful)

WilliamSChips (793741) | more than 8 years ago | (#15632652)

No, the solution is to not give the malware the path to even be able to do this by using a capability-type system.

Don't expect the trusted machine hardware to save (0)

Anonymous Coward | more than 8 years ago | (#15632602)

The trusted machine hardware, I have heard (from a src I believe), has a command to dump keys that are used. Unfortunately the designers were unable to think of anything better to do, so the key dump dumps them in the clear. Result is that hiding keys there is impossible also. So forget about that avenue saving things.
What could help would be a boot path that could be varied with many such paths on a machine. That at least might afford some way to get into a different OS and examine the underlying hardware from there now and then. Perhaps this should be taken as a reason virtualization in hardware should be made impossible. (It is easy to do that: any nonpriv'd instruction that changes privilege state for example will do that. A "go to user mode" that always works, for instance, would do.)

Virtualisation used for rootkit-safe environments (5, Interesting)

grumbel (592662) | more than 8 years ago | (#15632606)

Can't the same trick be used to make a rootkit-safe environment? Launch a watchdog application and let that watchdog application launch the real OS in a virtualized environment, as soon as a rootkit wants to fiddle the watchdog application takes notice and there would be no way for the rootkit to either detect or by pass the watchdog. Or even more drastic, launch each (or most) process in a virtualized environment, would probally be a little slow, but should provide a extremly secure OS.

Re: Virtualisation used for rootkit-safe environme (1)

OverflowingBitBucket (464177) | more than 8 years ago | (#15632817)

Launch a watchdog application and let that watchdog application launch the real OS in a virtualized environment, as soon as a rootkit wants to fiddle

Or the watchdog could use a similar exploit to jump above the rootkit and look down to see what is running. If we're nested one level too deep then we've got a problem.

Assuming of course we can nest. If we can't, the failure to nest would show the problem.

Or you could always run something using heavy 3D, and if the CPU ignites then something's up. ;)

Whoa. Déjà vu. (4, Funny)

DysenteryInTheRanks (902824) | more than 8 years ago | (#15632629)

"A Slashdot article just went by, and then another one that looks just like it!"

"It's a glitch in the rootkit! It happens when it changes something!"

"No, I said a SLASHDOT article."

"Ah, you're probably fine then."

There's nothing virtual about RootKit (0)

Anonymous Coward | more than 8 years ago | (#15632660)

There is only ONE RootKit! the original Geekboy band

And they need your votes to win google idol!

http://www.roootkitonline.com/ [roootkitonline.com]

Once untrusted software is run on your machine... (1)

ThinkFr33ly (902481) | more than 8 years ago | (#15632676)

... it's not your machine anymore.

Earlier processors secure??? (0)

Anonymous Coward | more than 8 years ago | (#15632719)

From the wikipedia entry;
Hardware availability of VT

Intel calls its hardware assistance for emulation "VT" although it is often referred to by its codename "Vanderpool". It was officially launched at the Intel Developer Forum Spring 2005. It is available on all Pentium 4 6x2, Pentium D 9xx, Xeon 7xxx and Core Duo processors, though in the latter case it is sometimes disabled in the BIOS/EFI.

So does this mean that earlier pentium III processors are secure from this particular rootkit attack? And because it can be disabled in the Core Duo in bios, is their a low-level bios routine that might be used to detect such a rootkit for other processors? I know that there is work to boot directly into linux from the bios firmware.

So let me get this straight... (2, Insightful)

C3ntaur (642283) | more than 8 years ago | (#15632789)

A virtual machine can't tell anything about the state of the host it runs on other than what's exposed to it? Isn't this kinda like saying that if you use an oscilloscope to monitor bit flips on the bus, the OS can't detect it? How is this news?

Is there really no way to detect virtualization? (1)

jdogalt (961241) | more than 8 years ago | (#15632822)

Is there truly no way to detect that the current running OS is running on virtualized hardware?

I mean, sure the toplevel malware kernel can intercept attempts to read the current running kernel and other memory/system locations. And that all becomes a cat and mouse excercise. But thats how rootkit security has always been. Again, what I'm asking to someone knowledgable is- does the new wave of hardware supported virtualization make it truly impossible for a process in the virtualized host to detect that it's been virtualized?

I mean, couldn't you look at the reported processor, and run a suite of simple benchmark code, and detect that a parasite meta-host is sucking away cycles that you expect to be there (this assumes the benchmark/detection code is run as root/kernel, and can therefore stop/ignore all other processes for some inconsequential amount of time).

-jdog

The virus must use some memory (1)

enosys (705759) | more than 8 years ago | (#15632877)

The virus must use some memory. This probably makes it detectable. It would probably appear that your computer has less memory than is actually installed.

What could the virus do? I doubt it could swap to disk to cover that. I guess it could try using compression on a small part of the guest OS.

Bah, humbug! (3, Informative)

davecb (6526) | more than 8 years ago | (#15632879)

Exactly the same thing was done using the ancient "cookie monster" program on Multics, long before Unix was even a gleam in T&R's eye.

The perpetrator created a user-ring instance of a user (a virtual-machine-like process), loaded in the cookie mosnter, then loaded the command interpreter and handed the result to an unsuspecting user, my boss.

He searchrd high and low, never suspecting the program that kept saying "Want cookie!" was down below the shell.

--dave

Undetectable to software maybe (1)

code shady (637051) | more than 8 years ago | (#15632891)

I don't know about you, but when I start up VMWare in windows (or parrellels in OS X) I definatley notice a performance hit. I find it difficult to believe that somebody wouldn't notice the fact that larg(ish depending on how exactly this is implemented) chunks of RAM and disk space are suddenly in use by some rogue program.

DRM? (2, Funny)

sr180 (700526) | more than 8 years ago | (#15632923)

Can we use this to bypass the DRM included in Vista?

LiveCDs? (1)

arkepp (604390) | more than 8 years ago | (#15632930)

Ok, I see how that's a great technical feat, but how is this any different? If I suspect a machine at work I wipe it. If it's a friend asking for help, and there are tons of settings I can't easily copy, I use a LiveCD and hope for the best. The illusion of real-time scanners and programs like AdAware passed a long time ago. Unless the virus flashes the BIOS (kudoz to the writer), the LiveCD should still be able to track it down, right? Provided the signature is known of course. I don't see how this changes anything?

Nothing new, really. (5, Insightful)

Anonymous Coward | more than 8 years ago | (#15632941)

The fundamental question of systems administration: once you have had a root compromise, what can you do to the machine to get it back up and running, in a known good configuration, with all chances of future compromise as a result of the initial compromise removed?

Answer: either compare the system (booted from known good media) to a known good set of files, or reinstall from known good media.

There's no other answer. Any tools you run on the compromised system are by definition suspect; they might be good, or they might be compromised. You have no way of knowing; anything they tell you is suspect. Even if you have tool binaries that you know are good, you don't know that the data they're gathering reflects reality or has been altered to give you a wrong impression.

So the fact that this software is undetectable doesn't really change anything; you're still finding out about the compromise through unusual activity, so that's 'status quo'. The only thing that's different is the layer that's compromised.

The interesting question is how the software gets in place in the first instance to compromise the system. The answer is that it was run as root (or administrator, or supervisor, or whatever the super-user is called). How did it get root privileges? Two possible answers: (1) a flaw in the OS (defined as the kernel, and any processes running with root privileges); or (2) the end user ran it somehow as root.

In the first case, it's the standard security problem. The OS is flawed; anything can get root. That's a bug. In the second case, it's end user stupidity. Nothing you run as an end user should require root privileges. (If the OS is designed in such a way that you do, again, that's a flaw in the OS. If the application expects it when it doesn't really need it, that's a bug in the application, and the vendor should be shot.)

So there's another layer the rootkit can hide in. Be still, my beating heart! This is, and remains, nothing fundamentally new. [acm.org]
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>