×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Blue Pill Myth Debunked

CowboyNeal posted more than 8 years ago | from the setting-the-record-straight dept.

128

njyoder writes "As previously posted about, Joanna Rutkowska claimed to have discovered an allegedly undetectable vulnerability in Vista that takes advantage of AMD cpu's virtualization capabilities. a virtualization professional (Anthony Liguori of the Xen project) has now voiced his opinion to state this is bunkum. There are two parts two this — the ability to take over the machine and seamlessly drop the OS into a VM (which is very difficult, but possible) and the ability to have windows run in the VM undetectably (which is impossible). In fact, Rutkowska's prototype is VERY detectable. This is unfortunate mistake that people make when they jump to conclusions based on what is unfounded speculation and that includes the assumption that this would somehow be Vista specific, if it worked (noting that Vista doesn't run with administrator privileges by default)."

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

Oh, *that* blue pill. (1)

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

Thought there was something more exciting than I thought happening with Vista!

I always take (2, Funny)

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

the red pill but I still wake up in hell each morning ... Vista will be shipping.

Detection (5, Insightful)

CastrTroy (595695) | more than 8 years ago | (#15893959)

I think the problem is not whether or not it can be detected by a professional, or a malware detection program, but whether or not it can be detected by the user of the computer. If you can run the entire OS in a VM, without the user knowing, then there's a lot of stuff you can do that would probably be a lot harder to do if you were just running regular malware. Although it's reassuring that this wasn't as bad as we expected, I still expect to see a few exploits that use this method to install malware, and spy on what the user is doing.

Detection-My buddy, the program. (1, Insightful)

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

"I think the problem is not whether or not it can be detected by a professional, or a malware detection program, but whether or not it can be detected by the user of the computer."

And people are going to detect it how? That's right. Using a program. Just like we detect all the other stuff.

Re:Detection-My buddy, the program. (2)

Fordiman (689627) | more than 8 years ago | (#15893996)

Actually, I think most people would be able to detect it when it fails utterly to work, and instead performs a quick BSD.

Re:Detection-My buddy, the program. (4, Funny)

ElleyKitten (715519) | more than 8 years ago | (#15894024)

Actually, I think most people would be able to detect it when it fails utterly to work, and instead performs a quick BSD.
BSOD. Unless Vista has a special feature where it will randomly install BSD over itself. That would be the best Windows ever!

Re:Detection-My buddy, the program. (1)

Vlad_the_Inhaler (32958) | more than 8 years ago | (#15894429)

I seem to remember that some BSD code was found in an earlier version of Windows a few years ago. Adding the rest of it seems like a nice idea.

Re:Detection-My buddy, the program. (1)

Jchord (989338) | more than 8 years ago | (#15895198)

*sigh* only if... only if...

Re:Detection-My buddy, the program. (1)

Poltras (680608) | more than 8 years ago | (#15894080)

You know there are programs to evade those particular programs from the kernel. And they are pretty good at that. Now a VM outside your OS might be detectable (nothing installed on your computer isn't), but it may be harder than to run that latest "vista-running-inside-vm-detector-by-microsoft" thingie. But hey! maybe I'm wrong and rootkits are still the way to go :)

Re:Detection-My buddy, the program. (4, Informative)

Sancho (17056) | more than 8 years ago | (#15894395)

When people talk about Blue Pill as being "undetectable" they mean "through the use of a program."

And that's Joanna's point. Properly constructed, Blue Pill 2 (the successor with full emulation support coded in--she herself admitted that her prototype is imperfect) would be undetectable by software running inside the VM. She discusses the possibility of a timing attack using an external clock, but also notes that this is infeasible in a large deployment. Certainly it would be infeasible for your average person running a computer (evidence by the fact that some of them don't even run antivirus/antimalware programs at all and get horribly infected!)

I was at Joanna's Black Hat briefing. Not once did she imply that this was Vista specific--in fact, she mentioned another briefing with the same sort of rootkit--only running on a MacBook. Her briefing was entitled "Subverting the Vista Kernel for Fun and Profit" because the first half of her talk was about elevating privileges in Vista, which would allow a rootkit such as Blue Pill to run.

I think that the danger here lies somewhere between "The end is very fucking nigh" and "This is absolutely nothing to worry about." Yes, it's extremely hard to implement. But that shouldn't mean we don't worry about it, because one implementation and it will be much easier to reverse engineer/modify to do other nasty things. Also, the eventual inability to detect in software means that if such an attack ever comes to pass, it will be extremely difficult to clean en masse (virtually requiring a reinstall or a livecd).

Re:Detection-My buddy, the program. (1)

nahdude812 (88157) | more than 8 years ago | (#15894473)

I'm curious if this will not give rise to a new breed of network bootups. This breed would be initiated from a BIOS that only allows itself to be flashed with very visible and bright red user confirmation off a non-bootable physically attached disk (such as CD or floppy). This BIOS will only boot off the network, and what it boots would be anti-VM software which confirms the local boot process of your machine, then once determined to be clean, transfers control back to the local machine. The BIOS would have no built in support for booting directly from an attached disk.

Of course this is only useful in corporate installs, but what corporation wouldn't want that kind of security? Similar ideas could be implemented (albeit with less user security) for on-board flash which also has the same sort of restrictions on being updated. Basically the idea is that once you've gotten past the BIOS screen, the BIOS and its anti-VM store cannot be modified any longer, as a hardware design (eg, the POST process sets a read-only bit on these important parts once POST is done).

I guess my point is in the end, there will still be ways to detect this stuff, and it will require BIOS/EFI support for booting from a known-safe location that can test for rootkit VMs. It may not be as convenient as today's antivirus software, but nothing is undetectable. Heck, maybe there's a whole new business here. Front-loading "Security cards" (ROM) from antivirus vendors. You pay a monthly fee, and each month a new card is mailed to your house/business with the latest updates. You shut down, pop out the old one, pop in the new one, and start up, knowing you're protected.

Re:Detection-My buddy, the program. (2, Informative)

Sancho (17056) | more than 8 years ago | (#15894564)

Right. As has been said, "undetectable" means "from within the VM itself". You're also talking about prevention, which is equally important. TPM could also prevent virtualization-based exploits, already exists in a fairly convenient form, is more robust (doesn't require an external server which could be down or bogged down), and fits in fairly well with corporate culture.

Re:Detection-My buddy, the program. (2, Insightful)

Anthony Liguori (820979) | more than 8 years ago | (#15894528)

When people talk about Blue Pill as being "undetectable" they mean "through the use of a program."

And that's Joanna's point. Properly constructed, Blue Pill 2 (the successor with full emulation support coded in--she herself admitted that her prototype is imperfect) would be undetectable by software running inside the VM.


This is the fundamental problem I have. So she has a crappy prototype but claims that the next version will be undetectable? Where's the paper? What is she exploiting to make this actually work?

She's got a theoritically "undetectable" exploit for which there is a theoritical way to detect it. Doesn't that seem a little odd? How big do you think Blue Pill 2 would have to be? Just to make the VMM itself would require something akin to Xen or VMware. We're talking hundreds of thousands of lines of code. Is that really a practical exploit in large enterprises?

Even with a full emulator, you cannot keep the VM from consulting external time sources in general. Just fixing up the TSC is not enough.

Re:Detection-My buddy, the program. (4, Informative)

Sancho (17056) | more than 8 years ago | (#15894578)

The paper was presented at Black Hat. She explained what is required in order to fully "emulate" the instructions required to make it undetectable. Essentially, Blue Pill would need a shim that passes virtualization instructions back up the chain until they could be executed for real, then return everything back down. It's not as huge as everyone thinks, but it's not trivial, either. But yes, she's outlined what has to be done.

I bet you can find a PDF of her slides somewhere online, if you're interested.

Re:Detection-My buddy, the program. (1)

Jeffrey Baker (6191) | more than 8 years ago | (#15894914)

Please rectify the contradiction formed by these competing stories:

1) A Virtual Machine will not defend us from viruses, because the virus can detect when it is running under the VM.

2) Blue Pill or its successor can execute Windows inside an undetectable VM.

Thanks.

Re:Detection-My buddy, the program. (1)

Sancho (17056) | more than 8 years ago | (#15894943)

Simple.

You're talking about two different types of VMs. #1 applies to software VM (like VMWare) and #2 applies to hardware virtualization.

That said, I don't recall making claim #1 at all, so I don't know what you're talking about or why you bring it up. Even if a virus could detect that it was running in a VM, unless it could escape the VM, it still would be contained.

Re:Detection-My buddy, the program. (1)

LiquidAvatar (772805) | more than 8 years ago | (#15895058)

I am a VMware consultant and work with virtualization every day. There are two reasons why I don't believe that this is much of a threat.

Virtualization presents static virtual hardware - whatever virtualization method that they utilize would present the same hardware to every vrtual machine (unless they coded it with a huge library of different virtual devices, which involves recoding the drivers for each device). From the device manager, you could check to see if the hardware in your system matches the hardware in your computer. It would be possible to run a tool that scans the hardware that the system sees and compares it to lists of known virtual hardware, then reports to the user what kind of virtualization is being utilized to run the system (with VMware virtualization, for example, about 8 of the devices listed are labeled with VMware as the hardware vendor - making it very obvious to people in the know that they are using a VM). Then, if there isn't supposed to be any virtualization going on, you could hopefully get your system into safe mode and fix the problem (reboot the system in some mode where it doesn't start the VM).

The second reason why I don't believe that this is much of a threat is because P2V Migrations [vmware.com] - that is, migrating a physical machine into a virtual machine - are pretty tough to do seemlessly. They typically require downtime of the system that we are migrating, while we employ an imaging program (like Ghost) to capture an image, and we then restore that image into the target VM, before stripping out the physical driver information so that the OS can cleanly detect the new virtual hardware. If anyone has much experience with imaging software, you know that it doesn't work too well if the system is still running while you capture the image (I know that there are several programs that do it, but my experience is that those images don't have a perfect success ratio and will often be unusable). The first time a P2Ved system boots, you have to reinstall the all new virtual hardware into it, including setting up the network adapter with IP information (since Windows binds IP information to the adapter, and the physical adapter is no longer present it loses your IP info). This experience would also hopefully alert the user that something is happening, especially since the hacker's virtualizaton platform would probably not have signed drivers, which would harass the user when they install on their non-hardware.

Re:Detection-My buddy, the program. (2, Insightful)

Sancho (17056) | more than 8 years ago | (#15895096)

The problem is that you're thinking of software virtualization rather than hardware virtualization (as in the Core Duo chips and AMD's newer chips). Both of your cases outlined above are dealt with using the instruction sets in these chips.

1) The hardware is the same unless the hypervisor changes what the software sees. All the hardware in the device manager will look just like it did pre-virtualization. This was demonstrated at Black Hat.

2) This is simply not true with hardware virtualization. It may be difficult to do, but Blue Pill was demonstrated through a video file as not requiring a reboot to initialize the VM with the running OS's settings. Furthermore, a live demonstration (first attempt crashed, though the second attempt was successful) on a Macbook showed that this was possible without a reboot.

What you have to realize is that this is all very new stuff on bleeding edge processors. It will be years before the majority of CPUs in homes will have this capability. For most users, what you say above is true--but not with these new chips.

Re:Detection-My buddy, the program. (1)

10101001 10101001 (732688) | more than 8 years ago | (#15895488)

Can I make a guess on how this is possible? Most IDE, SATA, etc HDs are common. So, it would be as simple as stuffing the whole system into a VM, having a very simple pass-through for the HD, and causing a swap out of important system files. Now, the swap out puts important files on the HD. The new pass-through allows one to alter otherwise locked files (as well as hiding malicious files), and since the IDE/SATA/etc hardware is so common, it'd be the least effort to writing a single pass-through exploit. And the reason I can see Vista (and possible Mac OS X) is vulnerable is because, as mentioned previously, these operating systems are hybrids, so important system files (ie, read parts of the effective kernel) are swapped out to the HD. Something like Linux and BSD would be mostly immune, as their kernels are never swapped (AFAIK).

Of course, all of this basically requires root-like authority, so it's not really a security vulnerability per-say. At best, it's a means to attack something more silently. But a lower-level pass-through would almost certainly be just as effective. It seems interesting from a perspective of a "and so this is why you can't let regular users run a VM", but that point is hardly a security surprise (it's why *nix doesn't allow regular users to mount filesystems, except under a strict set of conditions; and why Windows NT (though, AFAIK not later versions, as Direct X can trap any key combination) had a CTRL-ALT-DEL login option). It'd be tons easier to just replace the shell, probably. It'd just probably not being possible to do without a logout. And this could potentially change that.

Re:Detection (2, Insightful)

vertinox (846076) | more than 8 years ago | (#15894016)

If you can run the entire OS in a VM, without the user knowing,

So would the best solution is to try to run 3d FPS games to see if they work?

As far as I know one of the problems with VM is that 3d acceleration may not work as expected, but most VM companies are trying to get around this with much success.

Re:Detection (1)

ZachPruckowski (918562) | more than 8 years ago | (#15894068)

So would the best solution is to try to run 3d FPS games to see if they work?

Well, this is Vista. In theory, most PCs should be able to run some of the 3D effects (maybe not all of them). So you should notice a lack of the 3D effects all of a sudden, and a huge slowdown as Windows is no longer relying on the video card for desktop drawing.

Re:Detection (2, Insightful)

cnettel (836611) | more than 8 years ago | (#15894164)

Well, that's mostly not because of virtualization, but because of coexistence with the host OS. In this case, there is no host, just a hypervisor hacking specific calls. Any call to the graphics hardware could be let through, if desired. The performance hit would be acceptable for the non-inquisitive user.

Re:Detection (4, Informative)

gclef (96311) | more than 8 years ago | (#15894213)

This is hardware virtualization we're talking about, not software. The processor manufacturers have built virtualization calls into their chipsets. The side-effect of this is that the hypervisor can simply tell the bios "I'm the hypervisor...but, only call me when these specific requests are made." So, the hypervisor could simply choose to ignore the sound and video hardware, leaving those as fast as they were before.

The only way to tell the hypervisor is there is to find a CPU call that the hypervisor *does* care about, and compare how long it takes to run that command before & after the rootkit pushes the OS to a guest OS. That's what the Xen guy is talking about.

(I was at Rutkowska's talk...I'm not sure I buy the Xen guy's response.)

Re:Detection (2, Informative)

Sancho (17056) | more than 8 years ago | (#15894433)

It was quite an amazing talk, wasn't it?

She admitted that timing attacks were her weakness, as did the other guy who talked about virtualization-based rootkits. The problem is that you have to have a benchmark to compare it to, and you have to assume that the hypervisor doesn't modify the time whenever it is called. If the time does get modified, then the only way we know of to detect the rootkit is to measure clock skew on the infected PC using a real time source. This, of course, assumes that there isn't any real clock skew, or you get a bunch of false positives.

All of this requires a full implementation of Blue Pill, though, including the ability to virtualize "within" the virtualized OS. That is something that will be awhile coming--then again, mass adoption of CPUs which can handle virtualization will be awhile coming, too.

Re:Detection (1)

Anthony Liguori (820979) | more than 8 years ago | (#15894562)

She admitted that timing attacks were her weakness, as did the other guy who talked about virtualization-based rootkits. The problem is that you have to have a benchmark to compare it to, and you have to assume that the hypervisor doesn't modify the time whenever it is called.

The difference is order of magnitudes. Hypervisor exits incur penalties on the order of thousands of cycles. If you don't know the specifics of the system you're on, you can always compare the cost relative to a similiar instruction. For instance, while you may not know how many cycles a rdmsr should take, you should have a rough idea of the ratio of how many movl $0, %eax's you can do verses rdmsrs within a certain time period.

The hypervisor cannot modify external time sources because it cannot detect the use of an external time source in the general case.

The key to avoid skew is numbers. Do a ton of these operations and any potential skew will be lost in the noise.

Re:Detection (1)

Sancho (17056) | more than 8 years ago | (#15894591)

If I understand your method correctly, it still requires the use of an external clock. If that's the case, there's still no programmatic way to do it, you're still relying on external sources, which is something your average end-user is unlikely to do.

Or do I misunderstand?

Re:Detection (1)

Anthony Liguori (820979) | more than 8 years ago | (#15894997)

If I understand your method correctly, it still requires the use of an external clock. If that's the case, there's still no programmatic way to do it, you're still relying on external sources, which is something your average end-user is unlikely to do.

We're talking about anti-virus software here--not the average end-user. Anti-virus software just has to use NTP (or invent it's own time-keeping protocol) to check external time. There is of course a skew when checking time over the internet so you just make sure that your sample interval is much larger than your potential skew.

For instance, if you can only reliably get time from an NTP server plus or minus .5 seconds, and we're claiming that under blue pill, rdmsr will take 10x longer, then you need run the rdmsr instruction in a tight loop for at least .05 seconds.

Of course, you'd probably run it much longer just to be safe. For instance, if you ran it for 2 seconds, on native hardware it would take 2 seconds (and based on an external clock, you'd get anywhere from 1.5 to 2.5 seconds). Under blue pill, you would measure anywhere between 19.5 and 20.5 seconds. Such a dramatic difference would be a clear sign that you're in a VMM. That assumes that this is the ideal version of Blue Pill too which current doesn't exist. For less than ideal versions, there are much simplier tricks you can do.

Re:Detection (1)

Sancho (17056) | more than 8 years ago | (#15895019)

An excellent idea, however if AV companies start doing this, what will BluePill++ start doing? Blocking NTP? Blocking whatever ports the AV software uses to chec the external time? Is the AV software's inability to function necessarily indicative of BluePill, or could there be something else wrong?

This is a whole new battlefield, and while (as I've said before) I don't think this is the doomsday exploit that some people are claiming it is, I think it's something to be taken seriously if you're concerned about security.

Re:Detection (1)

kmsigel (306018) | more than 8 years ago | (#15895055)

Blocking NTP would be an obvious sign that something is wrong. Modifying NTP packets would be clever, but as I said in an earlier reply you can simply use a companion program on the timing computer to "invent" your own protocol that Blue Pill could never know and could never modify.

Re:Detection (1)

kmsigel (306018) | more than 8 years ago | (#15895035)

(I was at the Black Hat talk also.)

I agree that comparing the run times of instructions that will be trapped to those that won't is the way to go. I also agree that using an external time source would work well. I work with phototiming for a living, and have an external device with a 1PPM (part per million) clock in it. I can ask for the time over the network on any port using any arbitrary format that Blue Pill could not possibly know about. In that situation I know that the time I'm getting is reliable. (Most people, obviously, don't have access to this.)

You could instead use another computer as the time source and guarantee that Blue Pill won't alter your network packets by asking the user to enter a randomly chosen data format and use a randomly chosen port number. (This would require a companion program to run on the "timing" computer to speak the same randomly generated time protocol.) This would work just as well as my first example except that the accuracy of the time source would be lower, which shouldn't be a problem.

I also believe that you could do this test reliably without any external time source. PCs are chock full of devices that rely on timers of various known frequencies. Serial ports, ethernet ports, USB ports, IDE interfaces, PCI-to-whatever bridges, sound devices, etc. As a simple example, if the PC has a serial port just set the baud rate high (for higher precision) and queue a bunch of characters to send. Then run an instruction you want to measure a million (or so) times and then see how many characters are left in the buffer. There's your time! Repeat with other instructions and decide if the difference in execution time is reasonable or not.

Re:Detection (1)

andreyw (798182) | more than 8 years ago | (#15895300)

I hope that by "External time source" you really mean a clock sitting near you and NOT a system device, as those can be intercepted and emulated. Otherwise, yes.

Re:Detection (4, Interesting)

Anthony Liguori (820979) | more than 8 years ago | (#15894499)

This is hardware virtualization we're talking about, not software. The processor manufacturers have built virtualization calls into their chipsets.

They've added extensions to facilitate trap-and-emulate virtualization.

The side-effect of this is that the hypervisor can simply tell the bios "I'm the hypervisor...but, only call me when these specific requests are made."

VT/SVM have absolutely nothing to do with the BIOS. Instead, they both introduce a new processor mode that can be entered at any point that allow certain operations to be trapped. These operations are more or less the set of classic x86-sensitive instructions.

So, the hypervisor could simply choose to ignore the sound and video hardware, leaving those as fast as they were before.

Yup. But we're not talking about hardware here. Keep in mind, that if you do allow direct access to hardware, one now has a channel to access all of memory which could be used to detect a virus in RAM. Let's ignore that for now though :-)

The only way to tell the hypervisor is there is to find a CPU call that the hypervisor *does* care about, and compare how long it takes to run that command before & after the rootkit pushes the OS to a guest OS.

Yup, and as I pointed out to Joanna, there are a number of CPU operations that one would *have* to trap. Things like %cr3 moves, msr reads/writes, etc. Otherwise, one can just search memory for a signature. BTW, how does she hide the memory of the VMM from the guest? I didn't address this because there are some potential solutions (like memory hotplug) but this, in practice, would be a very hard problem to solve. You can just take away memory from an Operating System and expect things to function normally.

Why do you think she addressed this in her talk? I brought it up to her before she presented...

Anyway, you have to take a trap at some point. There are only a small number of possible instructions that trap. A very thorough "detector" could simply check the timing of every trapable instruction.

If she's not trapping any instructions, then the monitor is never getting run so is it really a monitor anymore?

BTW, on VT at least, the VMM doesn't get a choice for certain instructions. They always trap no matter what.

Re:Detection (1)

gclef (96311) | more than 8 years ago | (#15894786)

Why do you think she addressed this in her talk?

Feel free to correct me if I've mis-understood, but your position seems to be that while it may be prohibitively hard to detect the a trojan hypervisor, it's still technically possible. Joanna presented as if BluePill were undetectable, you're contesting that it's detectable, just hard.

From a practical point of view, there's little difference between those two positions. In fact, if it's so hard that no one will do it, there's operationally zero difference between those two positions. To me, this sounds like the beginning of every other arms race between malware writers and detectors, but at a lower level.

Granted, this is all still pretty theoretical, since she's just releasing a PoC, and there aren't enough systems with either VTx or SVM for this to be a practical attack in the real world.

Re:Detection (1)

TheLink (130905) | more than 8 years ago | (#15895031)

Uh, just make sure you own the "topmost" hypervisor in the first place, then you put vista or whatever in it.

The blue pill can continue running vista within itself, but it's not going to be able to put the first hypervisor in it ;).

Go figure.

Any time you suspect something fishy is going on, you could pause the entire thing using the "top most" hypervisor and scan.

IMO it's high level malware that will be harder.

Example: whether the following actually executes malicious code or not is dependent on what the search engine returns.

my ($code,$sig)=&$fetch_updates_via_search_engines($k eywords);
if ($sig eq $valid) {
  eval "$code"; ...
}

Re:Detection (1)

gclef (96311) | more than 8 years ago | (#15895072)

Ummm...the whole problem here is that a running OS can be moved to a guest OS. You can't "own the topmost hypervisor", because anything can still be moved to a guest OS even if it started at the "top." The whole question here isn't whether you can be moved down (you can), but whether you can detect that it's happened.

Re:Detection (1)

kmsigel (306018) | more than 8 years ago | (#15895101)

I don't think that's true. Once you become the first hypervisor nobody can unseat you. You provide a simulation for other hypervisors that might come along, so they also think they are the first hypervisor. They are, in fact, "below" you and you have complete control of them.

Re:Detection (1)

TheLink (130905) | more than 8 years ago | (#15895141)

Once you put the blue pill in your Matrix, it can't get out unless you let it or there is a bug in your Matrix.

It can think it got out, it can relaunch Vista in it's own "blue pill" Matrix, but it is not out.

You may also wish to see:
http://en.wikipedia.org/wiki/X86_virtualization

(we are talking about the new x86 stuff after all).

Re:Detection (1)

andreyw (798182) | more than 8 years ago | (#15895287)

Its nice that you were are Rutkowksa's talk, but try actaully reading the SVM/VT docs, so you don't sound like an incompetent goof. "The side-effect of this is that the hypervisor can simply tell the bios " - wtf? What BIOS? What the hell are you talking about?

Re:Detection (1)

saleenS281 (859657) | more than 8 years ago | (#15894303)

I don't, the size of the app alone to get the OS into a VM would take days to download on most people's "broadband". Knowing most mom and pops the computer would be turned off long before it could finish.

Re:Detection (1)

Sancho (17056) | more than 8 years ago | (#15894411)

Why do you think that the size of the app would "take days to download"?

debunked? I don't think so... (4, Interesting)

v1 (525388) | more than 8 years ago | (#15894340)

Though there is a littlee war the authors neglect to mention. If I am writing a blue pill virus vm, and I KNOW there is software out there that is trying to detect me, it's completely worthless. Since I own the machine at that point, I can modify the programs running, with impunity. That's like all the viruses that are out there right now that are more or less immune to Norton... they know what the "threat" is, and they plan accordingly, they know its weaknesses and simply sidestep right around it.

A vm that sees you load BluePillDetect.exe just goes in and twiddles a few bits here and there in the app before it actually puts it in the execute queue, or subtly mucks with its registers while it's executing. Now the program blissfully reports just what the VM wants it to report... "no VM detected.".

Now how are you going to get around THAT? If you are running on a totally owned system, you cannot tell me there is anything you can do that is guaranteed to work, especiially if you are using a commonly available tool that the vm author had access to..

You simply cannot win at their game if they are the ones writing the rules. You can claim victory for a day or two, until the VM authors get their hands on your tool and make the necessary modifications to their VM to cripple your tool, and then you are back to the drawing board.

Re:debunked? I don't think so... (1)

FLEB (312391) | more than 8 years ago | (#15894410)

Now how are you going to get around THAT?

Periodic live-CD system file scanning?

Re:debunked? I don't think so... (1)

cduffy (652) | more than 8 years ago | (#15894436)

A vm that sees you load BluePillDetect.exe just goes in and twiddles a few bits here and there in the app before it actually puts it in the execute queue, or subtly mucks with its registers while it's executing. Now the program blissfully reports just what the VM wants it to report... "no VM detected.".
Yes, but writing code from the VM to reach inside OS-specific structures (or even read their contents) is difficult and fragile -- you need to find structures with known memory locations and find a way to follow their pointers to find other things that don't, and the memory locations are prone to changing without any kind of warning when the user applies a service pack or something. The non-fragile way to do it is to have some code running inside the virtualized OS using vendor-supported interfaces -- but as soon as you do that, you're detectable by OS-specific measures.

You could get around that by detecting this code at the driver level -- as it's being read or written from disk or received on the network -- but that's still possible to work around: Download it in an encrypted archive (with a key that's different for each download) into an encrypted partition, dearchive and run it there and the disk drivers will never see the byte pattern matching BluePillDetect.exe.

All that said -- I can see how one could twiddle the bits (modifying BPD's code, not the system characteristics) within the VMM to make the system itself undetectable to BluePillDetect on a standalone machine (one would need to look for BluePillDetect only if a pattern appropriate to it is seen -- say, a specific trapped instruction being called very frequently -- though if BPD could be written to need only a small number of common trapped instruction calls, and it's passed through the disk and network drivers only in encrypted form, it's hard to see how its activity could be easily detected from a VMM without serious overhead), but not how to stay undetectable with another networked machine assisting. If BluePillDetect provides a challenge which a system running under a VMM can perform quickly and a system not running under a VMM can't and another system on the network is involved in the test (validating the answers and the times at which they were received), the system under the VMM is sunk -- at least if the challenge is dynamically modifiable enough that it can't patch BluePillDetect with code to provide the remote machine with a precanned answer. Sure, the local system may still not know it's been hacked -- but the remote system will, and that's enough.

To the extent that Blue Pill was claimed to be 100% undetectable, I do believe it's debunked. Might the war continue? Sure -- but it's the same war it's always been.

Re:debunked? I don't think so... (0)

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

Download it in an encrypted archive (with a key that's different for each download) into an encrypted partition, dearchive and run it there and the disk drivers will never see the byte pattern matching BluePillDetect.exe.

Dearchiving [1] can be done without using the disk drivers?

[1] -- in other words, reading the encrypted version, expanding it, and writing out the expanded version.

Or perhaps you meant "unencrypt into memory and run it from there", which might do what you want.

Re:debunked? I don't think so... (1)

jimicus (737525) | more than 8 years ago | (#15894688)

You can claim victory for a day or two, until the VM authors get their hands on your tool and make the necessary modifications to their VM to cripple your tool, and then you are back to the drawing board.
:%s/VM/virus/g
and you've just described the state of the art in virus scanning as it's been since more-or-less forever.

Re:debunked? I don't think so... (1)

smallpaul (65919) | more than 8 years ago | (#15895109)

A vm that sees you load BluePillDetect.exe just goes in and twiddles a few bits here and there in the app

There exists an infinite number of bit patterns performing the task of BluePillDetect.exe. 99.99999% of them will be unrecognized by the malware. If the user can install one of them, or even type one in, then the malware is not "100% undetectable." So the claim has been debunked.

Re:debunked? I don't think so... (0)

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

You forget, my BluePill detect program uses DMA requests to the video card to scan main memory for the presence of any hypervisor.

that's funny. (1)

TheLink (130905) | more than 8 years ago | (#15895003)

Most people can't even detect spyware running until there are like tons of them running!

Anyway, the blue pill stuff is overrated.

AFAIK the new x86 hardware VM features are supposed to allow you to run VMs in VMs and other stuff.

So, just make sure you boot Vista or whatever O/S of you choice in a hardware VM right from the very beginning. Call that sort of thing a "white pill" if you want.

Then the white pill can just scan for or intercept blue pill stuff. The white pill can use whatever tricks the blue pill can, and since it got there first, there's very little the blue pill can do about it.

Yawn...

article motivation (0, Flamebait)

rjdegraaf (712353) | more than 8 years ago | (#15893961)

FTA:
Anthony Liguori: I've been working on the Xen project for approximately 2 years. Like most Xen hackers, I do a little bit of everything. I'm on an extended vacation right now but normally I'm fortunate enough to be a full time Xen hacker.


Read: Anthony Liguori: I've been working on the Xen project for approximately 2 years. Like most Xen hackers, I have no job security. I'm am taking of any project but this article hopefully secures my job.

This is unfortunate mistake. (0, Offtopic)

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

Silly editors, this irony.

When the heart rules the mind.... (2, Interesting)

SubliminalVortex (942332) | more than 8 years ago | (#15893973)

Most operating systems don't take advantage of the facilities the 'processor' provides for them. This has been true for quite some generation of operating systems.

I would probably take heart to this if a hardware (or firmware) engineer spoke up and noted that this is a possibity. Are processors now offering virtualizaton in-chip?

Re:When the heart rules the mind.... (2, Informative)

MindStalker (22827) | more than 8 years ago | (#15894057)

Yes. http://www.intel.com/technology/computing/vptech/ [intel.com]

Of course this is intended for highend systems. Like all other technology expect to see it in regular systems in no time.

Re:When the heart rules the mind.... (1)

SubliminalVortex (942332) | more than 8 years ago | (#15894087)

Unfortunately, it will most likely be exploited. Amazing how intangible effort is quite so easily mis-used; at least in the good ol' days, you keep the kids out with either a harsh word or a baseball bat. :)

Re:When the heart rules the mind.... (1)

frankie (91710) | more than 8 years ago | (#15894248)

Yes, and it's the whole point of this supposed exploit. Rutkowska runs AMD's "Pacifica" instructions in Ring -1 that wrap around your usual OS kernel in Ring 0.

Which, by the way, brings up a THIRD faulty assumption from the demo: this tactic is absolutely NOT AMD-specific. Intel's "Vanderpool" offers a slightly different ISA but ends up at an equivalent Ring -1, with the same theoretical risks and rewards.

Summary (0)

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

Oh well, at least the summary was a good deal more interesting than the norm.

Really? (-1, Troll)

porkThreeWays (895269) | more than 8 years ago | (#15893976)

A woman lied? You don't say...

Re:Really? (0)

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

Bitter?

It won't help you find a good one.

Re:Really? (0, Offtopic)

SubliminalVortex (942332) | more than 8 years ago | (#15893998)

haha, but you *thought* it was a woman. :)

That's great! (0, Flamebait)

liquidpele (663430) | more than 8 years ago | (#15893999)

Vista Status: 1 known vulnerability found to be not so bad, just 50,000 unknowns to go and we're secure!

seriously though, it does sound like they've done quite a bit of work on security, so here's hoping it's still not swiss cheese security.

Re:That's great! (1, Informative)

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

This really has nothing to do with Vista. The premise of the "exploit" is that some piece of malware obtains enough access to the machine to effectively install it's own OS shim which acts as a virtual machine host, or VMM, or hypervisor, which then launches the original natively-executing OS as a guest OS. The shim would be able to perform nefarious acts with full access to the memory and execution of the guest OS while being effectively undetected by the guest OS, since it's not technically running in the memory of the guest OS.

Effectively this vulnerability is a hardware one and would effect any OS which is compatible for the platform. However, as the article states, it would be a Helluva engineering feat to accomplish loading the virtual machine host and then piggybacking the native OS, and even then due to the fact that the virtual machine host has to catch and emulate certain instructions it will always be detectable if just through performance characteristics of those instructions.

That's great!-A shim sham. (0)

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

"seriously though, it does sound like they've done quite a bit of work on security, so here's hoping it's still not swiss cheese security."

Yes, and trusted computing will help in regards to these "shims".

Impossible to not be detected? (2, Insightful)

nurb432 (527695) | more than 8 years ago | (#15894014)

I dont agree with that statement.

While i agree it would really really damned hard to do it, you could create a VM that the host os wont reconize as being a VM. Sure, it would have to accomodate for each new PC out there as hardware changes, and that it would be a massively complex beast that more then likely could never be turned into a worm/virus/trojan that you wouldnt see coming a mile away, but it could be done.

Never say impossible when logic says it could be done. Just say impractical..

Re:Impossible to not be detected? (4, Insightful)

Anthony Liguori (820979) | more than 8 years ago | (#15894134)

Never say impossible when logic says it could be done. Just say impractical..

There are actually things in computer science that are impossible. Usually, they are problems in the form "figure out whether another program has propery X". Classic examples are the halting problem.

Recall, I'm disputing the claim of "100% undetectable". You could make something that's really, really, really hard to detect.

Re:Impossible to not be detected? (1)

Sancho (17056) | more than 8 years ago | (#15894491)

I think that it would be impossible to provably show that a complete Blue Pill implementation is on your system from within that system. The idea being, it might be possible to detect anomalies by using software on the infected VM. It would be impossible to definitively say "You are infected with Blue Pill." The most it could do is say, "I found X, Y, and Z timing/instruction anomalies which lead me to believe that I am running in a VM. User, am I running in a VM to the best of your knowledge?" This is assuming that timing isn't programatically modified (possible), instructions aren't perfectly emulated (possible), and that the user doesn't think to check for clock skew (highly possible).

Undetectability has to be put into context. A livecd should be able to detect signs of malware on a system just fine. Using non-computer metrics (such as stopwatch-based timing) might also detect anomalies, if you have a pre-infection benchmark to compare it to. Sniffing on your LAN should detect any traffic sent out by your box that shouldn't be there. This doesn't make it detectable from within the running, infected system.

my take (4, Interesting)

brennz (715237) | more than 8 years ago | (#15894017)

I'm not so sure Anthony Liguori is right.

Most people in the security community are well aware of http://www.ephemeralsecurity.com/mosref [ephemeralsecurity.com] demo at http://static.ephemeralsecurity.com/mosvm/demo1.ht ml [ephemeralsecurity.com] more detail at http://static.ephemeralsecurity.com/mosvm/Mosref%2 0Howto.html [ephemeralsecurity.com] and the continual move toward VM

If mosquito and similar tools are not moving towards VMMs, I'd be very suprised. After all, it is a logical step (From VM as a payload, to a VMM as a payload).

Re:my take (4, Informative)

Anthony Liguori (820979) | more than 8 years ago | (#15894146)

If mosquito and similar tools are not moving towards VMMs, I'd be very suprised. After all, it is a logical step (From VM as a payload, to a VMM as a payload).

Of course, VMM's can be used to do all sorts of nasty things. VMM-level virus could certainly be nasty. And, an important point to note, is that it may be entirely possible for a virus to be hidden in a VMM and for a virtual machine not to be able to detect that virus. Will VMM's need anti-virus software? I hope they don't suck that much.

What "blue pill" is though is something much different. It's claim is that you can take a native Operating System and turn it into a virtual machine without the OS knowing about it.

Of course it's difficult to do in Vista (4, Interesting)

Ant P. (974313) | more than 8 years ago | (#15894022)

Which is why malware's going to do this on Windows XP, then lie dormant until it detects Vista installed.

Re:Of course it's difficult to do in Vista (1)

YrWrstNtmr (564987) | more than 8 years ago | (#15894247)

Very few will buy Vista to reinstall over XP. Most will just get it with a new PC. And if they DO reinstall, most will probably completely blow away the drive, and do a full install instead of an upgrade install.

Re:Of course it's difficult to do in Vista (0)

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

Are you feeling insecure about your unreleased OS?

Re:Of course it's difficult to do in Vista (1)

Overzeetop (214511) | more than 8 years ago | (#15894466)

You mean everyone except just about every engineering desktop in America, right? Installing all the S/W required for non-admin types is an IT killer. Even if they don't fuck up the installs, it takes them forever to prep each new machine. Hell, we figure one to two weeks of end-user downtime into every machine upgrade.

Joanna is a cunt (-1, Offtopic)

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

Cunt Cunt!

vista running with admin privledges? (2, Interesting)

jtdennis (77869) | more than 8 years ago | (#15894077)

At least with Beta 2 Vista did run with admin privledges, just as all previous versions of Windows. But you have that box that pops up when ever you use those privledges. MS has done a good PR campaign to make people think it doesn't, but install beta 2 for yourself, the user created in setup is an admin just like in XP. I sincerely hope that this is changed with RC1.

Re:vista running with admin privledges? (2, Informative)

Timesprout (579035) | more than 8 years ago | (#15894082)

ffs its a beta, they have said all along the Final RC will not run under admin

Re:vista running with admin privledges? (0)

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

they have said all along the Final RC will not run under admin

They also said WinFS would ship as part of Vista. Oh, and that Vista would ship a long time ago.

Since when does Microsoft have any credibility when announcing features or capabilities of unreleased, much less released, products?

Re:vista running with admin privledges? (1)

dfghjk (711126) | more than 8 years ago | (#15894336)

"the user created in setup is an admin just like in XP"

An admin account does need to be set up after all so you should expect that to continue. OS X does it too.

Re:vista running with admin privledges? (1)

RzUpAnmsCwrds (262647) | more than 8 years ago | (#15894632)

Five minutes on Google would have told you that this is how UAC is supposed to work. "Administrator" accounts are still limited by UAC, but instead of requiring a separate "root" account, UAC allows elevation using your existing credentials.

It's a prototype (2, Insightful)

Bartmoss (16109) | more than 8 years ago | (#15894084)

The exploit is the first of its kind for Vista. Give this a few years and add the high motivation of criminals who make millions by exploiting PCs and you can be sure we'll eventually see some quite nasty stuff.

Re:It's a prototype (0)

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

Blue Pill has very little to do with Vista you fucking moron.

'two' does not equal 'too' (1, Funny)

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

- grammar is pretty bad on /., eh?

Re:'two' does not equal 'too' (1)

feed_me_cereal (452042) | more than 8 years ago | (#15894301)

try reading the article; it gets worse...

Re:'two' does not equal 'too' (1)

sveiki_neliels (870930) | more than 8 years ago | (#15894343)

That's not grammar, that's spelling.

Re:'two' does not equal 'too' (1)

whitehatlurker (867714) | more than 8 years ago | (#15895519)

"Two" is correctly spelled - it is a misuse of the word, which is a mistake in grammar.

Re:'two' does not equal 'too' (1)

ivonic (972040) | more than 8 years ago | (#15894417)

It's meant to be 'to' not 'too' as you suggested, and not 'two' as in the article. There are two parts to this.

Not the only one to come to this conclusion... (2, Informative)

Anthony Liguori (820979) | more than 8 years ago | (#15894176)

FWIW, Keith Adams of VMware posted a recent blog entry "Blue Pill" is quasi-illiterate gibberish [blogspot.com] and there have been a number of other folks that have come to the same conclusion [openrce.org] .

Re:Not the only one to come to this conclusion... (1)

Alex_Ionescu (199153) | more than 8 years ago | (#15894264)

Not to mention the fact the pagefile exploit:
1) Won't work on some systems, by design (like mine)
2) Has a high risk of damaging your data, due to the complete lack of multi-thread race considerations.

Re:Not the only one to come to this conclusion... (0)

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

This is why you shouldn't read blogs. The guy cites bochs, but doesn't appreciate the fact that you need a 1Ghz computer to get emulated performance like a 386. Running XP in an x86 emulator has a huge, obvious performance hit. Virtualisation changes that.
Plus, he doesn't know what the word "illiterate" means, "quasi-" or not.

The OpenRCE guys seem to be much more on the ball.

This is why... (1)

flight_master (867426) | more than 8 years ago | (#15894265)

You're supposed to by a Intel Core Duo CPU...

Why undetectable? (1)

The MAZZTer (911996) | more than 8 years ago | (#15894315)

I'm thinking any subversive VM thing would be like an uber-rootkit. When infected, the user's ntldr or winload.exe (for Vista) would be overwritten to load our new OS instead of Windows. On the next boot (which could come early by the delivery system resetting the computer), the new OS would load which would be little more than a very thin VM wrapper around windows. It would immediately boot up windows, and the user would be none the wiser. Basic things it would do (that would classify it as a rootkit) would be to modify the raw hard drive data running between Windows and the BIOS to hide it's own files as well as hide the ntldr and winload.exe tampering (it would make backups of them before modification and would hide the backups, but would show them in place of its hacked versions).

Theoretically this would be undetectable unless you boot from a CD... even this could potentially be compromised if the BIOS can be "upgraded"... of course there would be no way to protect from moving the HD into another computer and immediately booting from a CD to look at the contents.

this stuff is what bothers me (2, Interesting)

rucs_hack (784150) | more than 8 years ago | (#15894358)

With Open source there's no problem. I can hear about a thing, test it, look at code, and decide whether it's an issue to me. Or if it's outside of my abilities, That wonderful peer review process can do the job for me. People who are being paid to say good things soon fall silent or get drowned out in the face of proof to the contrary from many sources who are not being paid, but do it out of interest.

With closed source code of any type I have no such option. Instead all I get is 'experts' to tell me. But these guys have to eat, so they get paid by someone, and have a vested interest in being paid tomorrow. Therefore there can be no impartial advice.

Heck, if the cheif engineer on the shuttle program can be convinced to retract his refusal to sign off the shuttle because of O-ring problems, what hope is there for trustworthy answer from anyone regarding closed source software?

Ok, possibly I'm being too extreme with my example, but seriously I worry about the *true* safety of using an operating system which has not, in fact, been designed with consumers in mind. It is, by microsofts own cheerful admission, purposely built to help 'rights holders' of stuff you use keep you from deviating from their precious business plan.
Perhaps this is fair enough, but there should be a trade off. I see no evidence that the rights of the OS purchaser are being properly considered. Even XP assumes you are a pirate unless proven otherwise. That reveals a lot about their views of the lowly home consumer.

Re:this stuff is what bothers me (1)

Angostura (703910) | more than 8 years ago | (#15894428)

And how, pray does the openness or otherwise of the OS allow you to know whether you could silently drop it inside a hypervisor without knowing? This is not a Vista-specific exploit.

Re:this stuff is what bothers me (1)

Sloppy (14984) | more than 8 years ago | (#15894670)

His complaint is not about a technical matter. Openness may have a very limited (or no) effect on whether or not a compromise is possible. But it does have an effect on whether or not the threat is analysed and whether or not you can trust that analysis.

It's really a question of integrity and loyalty. It may be strange to talk about an inanimate object (software) having "loyalty" but it's the best analogy I can come up with. Free software gives its ultimate loyalty and allegiance to the user. You can debate how well it does this (i.e. complain about The Gimp's UI) but that it always what it strives for, because if it does something contrary to the user's interest, somebody will fork it. Proprietary software serves someone else. The user's interest is always a secondary priority, and when it does something contrary to the user's interest (e.g. a media player that looks at a bit in a stream to see if it is "allowed" to capture a snapshot) the bug/feature doesn't get forked out.

Furthermore, you may not even know that a bug or vulnerability exists. You just have to take someone's word for it, and that "someone" doesn't have to show their work and is probably ultimately accountable to someone who sure as hell isn't you. When someone analysing free software attests that a vulnerability does or doesn't exist, he isn't necessarily accountable to you either (unless you hired him), but you don't have to trust him, because he does show his work. It's right out in the open for a bunch of his peers to check, and you can pretty much guarantee that those peers do not share any particular compromised agenda or loyalty to the same employer.

Proprietary software can be secure, but whether it is or not, the user cannot trust it (unless its an internal tool developed and used by the same team). Free software can be secure and trusted too.

Re:this stuff is what bothers me (1)

rucs_hack (784150) | more than 8 years ago | (#15895041)

That sir, is *exactly* what I was talking about. However I didn't put it across as well as you.

I'm still amazed by today's AV methods (1)

Sloppy (14984) | more than 8 years ago | (#15894541)

VI: Where are risks in this scenario?

AL: If a virus cannot be removed or detected, it's pretty much a worse case scenario for corporate security. Once there was an outbreak, you couldn't trust any of your systems at all. I'm not sure how one could even mitigate such a threat--perhaps do frequent reinstalls of every system on your network?

I'm still just amazed that people don't do this anyway. My understanding is that today's approach to AV is that people run AV applications on possibly infected systems, while infected, to try to diagnose and remove malware. The blue pill claims to invalidate this approach, but that approach was already invalid. You can't trust an infected system, period. If this is how you approach malware, you are doomed, and whether the blue pill is all it's cracked up to be or not, is irrelevant. They will get you someday, if you trust your system to look at itself. This is absolutely inevitable.

What's so disappointing, is that this is a very, very basic and fundamental principle. You don't have to be a virtualization expert to know this. Indeed, there was a time when everyone knew it. It's so sad that the AV companies have dumbed down the public.

BTW, the interviewee goes on to claim that using an external time source (presumably that is totally un-virtualizable) is a foolproof way to detect when you're running under virtualization. Keep in mind that all you might learn from such a test, is whether or not you're virtualized. This will still not give a user any way to detect whether you're running running malware or not. I think a time is coming when virtualization becomes mainstream, simply for security and compartmentalization reasons. When that happens, users will expect the "am I virtualized?" test to return True, so this test will not necessarily lead anyone to suspect their system is compromised.

So give up on this approach. I promise you: you're absolutely doomed if you rely on AV tools running while possibly compromised. You must boot a known-clean system before you scan.

In theory, the theoretical is practical (1)

Cid Highwind (9258) | more than 8 years ago | (#15894900)

Booting from read-only media and cleaning a compromised machine works well for *nix systems, but there isn't a usable live CD malware removal tool for Windows. Unmodified Windows won't run from read-only media, the lack of a complete, free, legal NTFS driver and automated tools for removing Windows-specific malware makes Linux live DC distros impractical, and the pain of dealing with BartPE makes that a non-starter for all but the most technically adept admins. Until you can pop a disc in the drive, reboot, and click a big red "Kill Malware" button, people are going to keep using AV applications from within compromised Windows environments.

Hmm... (1)

denmarkw00t (892627) | more than 8 years ago | (#15894616)

This is unfortunate mistake

Yes, it is.

Stupid name (1)

77Punker (673758) | more than 8 years ago | (#15894781)

With a name like "blue pill" you know it has to be fake. What is it? Blue pill, developed by h4XX, Inc.?

I can't read anymore (0)

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

Can someone tell me what the hell this sentence means?

"This is unfortunate mistake that people make when they jump to conclusions based on what is unfounded speculation and that includes the assumption that this would somehow be Vista specific, if it worked"

It seems to be saying that there is a proper way of jumping to conclusions based on unfounded speculation, but that sometimes people make a mistake in doing so and that one of those mistakes is assuming that the "blue pill" thing is Windows Vista specific. I can't even begin to figure out how "if it worked" is supposed to fit in with the rest of that sentence. Have our writing classes become that bad, or is the author a homeschooler?

Am I the only one... (2, Funny)

bquickfoo (922325) | more than 8 years ago | (#15894991)

Am I the only person that thought this posting was going to be about Viagra? Must just be the email I've been getting lately.

Debunkers of Myths (-1, Troll)

aminorex (141494) | more than 8 years ago | (#15895181)

Myth debunkers are all alike. Pompous asses, ignoramuses who try to make themselves feel more
important and intelligent by fabricating ludicrous "skeptical" arguments that fool the credulous
layperson with their double-speak.

Don't believe these hoaxsters.

Well, I am glad (1)

whitehatlurker (867714) | more than 8 years ago | (#15895525)

That they're finally debunked that blue pill nonsense. I'm tired of getting spam for that stuff [viagra.com] .
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?