Non sequitur. Whatever you may think of their politics, it's manifestly true that media companies make more money immediately after a title's release. There's nothing inconsistent about them defending those profits while working towards some complementary long-term goal.
If the encryption is computationally cheaper, then the decryption is computationally cheaper.
What four Slashdot moderators voted this stupid comment up?
No, it's a riff on (a) Black Hat, the industry's leading vulnerability research conference, (b) Black Hat, the term of art for people who break software, and (c) Blue Badges, the slang internal term for MSFT full-timers.
Which is why modern smartcard-protected systems don't have trivial boolean checks; they use the card as an encryption server to decrypt data necessary to access the stream. There is no opcode byte you can patch to bypass the card, because the card is mathematically inline with the stream. It sure sounds like the systems you work on are easy to beat. The P(n) DirecTV cards, not so much.
There are few problems DNSSEC solves that SSL/TLS won't do a far better job solving. SSL/TLS deployment is almost universal. With the vast effort we've spent fighting over how to secure a tiny portion of the Internet protocol stack, we could instead have come up with a way to make verifiable SSL certificates free and easily acquired. I wrote about this at length earlier this year.
Furthermore, DNSSEC is a mess. It has taken over ten years to come up with a protocol that a plurality of operators will agree to deploy --- and that protocol hasn't even been deployed yet. Until NSEC3 (or, in the alternative, whitelies) is standardized, the result of that 10+ year effort is a protocol that publishes full zone contents to the world. And have you looked at how NSEC3 works? It's literally a Unix-style password file encoded into DNS zones. I wrote about this at length earlier this year as well.
Finally, DNSSEC will break the DNS. Everyone who takes the time to read comments on Slashdot has dealt with "expired SSL certificate" dialogs in their browser. Everyone has clicked past them. DNSSEC presents the same problem, across the entire DNS, but offers no "click-through" to deal with the situation: DNSSEC works below the API layer, and there is no chance gethostbyname is going anywhere in the near future.
Did you know that DNSSEC doesn't even secure the DNS communication between your browser and your DNS server? There's a whole other protocol --- TSIG --- that handles the "last mile" of DNS security.
Personally, I would be highly skeptical of "security" analysis from companies like Infoblox that claim DNSSEC adoption has anything to do with the security of the Internet.
Be fair: the only researcher saying that "hypervisors can be detected, but rootkits can't" is Joanna. The rest of us, from what I can see, agree: you might not be able to detect Blue Pill by name, but you can detect unauthorized virtualization, even if you're already legitimately virtualized. Currently, the only source of unauthorized virtualization? Blue Pill.
That's simply not how it works. This isn't DOS, and there isn't a simple BIOS call the OS uses to retrieve the current time. Start here: the X86 has a 64 bit timebase register, the TSC, which reports cycle-count time in about 150 cycles directly from the hardware. Joanna tried to virtualize the TSC and found that she couldn't do it reliably under AMD SVM. She had to resort to dynamic code translation, VMware-style, to detect and modify code that probed the TSC. The problem with that approach is left as an exercise to the reader, who is encouraged to read a few back issues of 40Hex.
It's funny that people can forget the fact that the CPU is itself a clock. Which is why you can time a hypervisor with a simple counter loop, like Edgar Barbosa did. Joanna conceded that she had no effective defense against this approach either.
The threat model facing rootkits is not end-user computer savvy. It's conventional anti-malware software. The question isn't whether the person sitting at the computer is smart enough to notice a 60% slowdown. It's whether the impact the rootkit has on the system is reliably measurable, either directly or through a side-channel, in a way that can be harnessed by Norton Antivirus. If it is, you lose; your "undetectable rootkit" is now literally a bullet point on the packaging of a security product, making the AV companies money.
As for the clocks: there are tens of them in a conventional X86 box. You're probably thinking of the RTC, and you may have heard of the TSC. But what about the high performance clocks? The ACPI timers? Or how about the implied timers driving device events? Remember the VGA blanking interval? Assuming you know where all the clocks are, now figure out some protocol to keep all your perturbations of these clocks consistent.
Joanna is doing great work, but it is being totally misrepresented in comments like these. Her challenge is nowhere nearly as simple as the armchair quarterbacks are making it sound.
You clearly didn't read the paper, because it doesn't simply describe how "industry standard VMs operate". Garfinkel and Ferrie are talking about fundamental X86 architectural issues that make intercepting hardware accesses and emulating them in software perceptable to code running on the same machine. The Blue Pill VMM rootkit doesn't leave important instructions "unvirtualized", but it has to operate within the X86 memory hierarchy, and so remains detectable.
For example, the fact that a transition in and out of the hypervisor flushes TLB entries is not a "shortcut" taken by VMware; it's a design parameter of Intel's VT-x and AMD's SVM extensions. The fact that you can't reliably offset the TSC in AMD's SVM is also not a shortcut. And the fact that you can run a counter loop to detect VM exits regardless of the underlying hardware is not a shortcut.
How, exactly, do you propose that rootkit authors evade these problems?
Judy arrays are kind of silly, but I used to think tries were a great answer for parsing, because they provide O(m) abbreviation matching and access to ambiguous options. But then I realized: it's 1998 (hey, I'm old); why am I optimizing something that will run in individual milliseconds even if I search linearly?
I challenge: cite as an example any fixed set of strings (such as would be applicable for perfect hashing) for which a realistic perfect hashing scheme of any sort outperforms a statically-sized conventional chaining table using a trivial 33/37-style string hash. I don't think you can. Gperf languishes in obscurity for a reason.
Again, on the off chance that this helps anyone reading this pitifully long and silly thread: it is trivial to make getopt work on Win32, just like it was trivial to make strsep work on Linux when it only had strtok. I object to the argument that "portability" has anything whatsoever to do with whether you'd use getopt to parse arguments.
Like most of the other comments on this post, I find the idea of using gperf for "high performance argument parsing" superfluous and convoluted. In fact, I find the idea of a general-purpose perfect hash tool a bit superfluous as well; gperf languishes in obscurity for a reason.
Absolutely. There is no platform for which gperf is a better, more portable option for command line processing than getopt. I'm not sure what you think getopt does that is "tricky" under Win32. Its a string processor.
I'm not sure why people are modding up a post that claims that the MSRC is a "rumor" inside of Microsoft. The MSRC is famous; news stories are written when people move to and from the group. They release all the Microsoft advisories, each of which typically elicit yet another news story. A position in the MSRC was listed as "one of the worst jobs in science" in SciAm (obviously wrong; people compete to get jobs there).
Why don't you tell us more about the security flaw you claim to have found?
No technology company in the world spends more money on security testing than Microsoft does. At any one time, it's likely that Microsoft retains a plurality of the security testing industry to perform code review and black-box testing on the myriad of products they are releasing this cycle. These aren't Microsoft employees; these are team members of the boutique security consultancies being paid directly by Microsoft to find vulnerabilities in products before they ship.
Microsoft is already paying for vulnerabilities. Investigate and you may find that just as Google singlehandledly jacked up the comp for every web-savvy C/C++/Java dev in the valley, Microsoft has amped up the bill rates for security consultants worldwide. Entire consulting outfits are built around pipelines of Microsoft work; some of the best and most famous researchers in the world work for these outfits.
Seven years ago, it was probably valid to single out Microsoft for carelessness about software security. But, just like this essay implies, software security is a problem that money can impact. Microsoft has lots of money. Since Windows XP, they have certainly put it where their mouth is.
There are differences between "true independent security research" and contract work for vendors. They're not clear-cut enough to make a value judgement. Researchers on contract to Microsoft get access to source code, developer documentation, test tools and the dev team. They also find problems before customers are exposed to them. On the other hand, indie researchers don't have to pass phone screens, know how to sell, or have the right contacts. Both groups find stuff.
It's worth noting that the overwhelming majority of external Microsoft findings in 2007 come from vendor-sponsored "research labs", usually attached to IPS signature farms (like the ISS "X-Force"). These groups strain the definition of "indie", are already well-compensated, and will continue to harvest findings whether or not an incentive scheme is created.
In any case, "WabiSabiLabs" is unlikely to have any impact here. Every major product Microsoft releases has been audited by a competant third-party. Microsoft has re-vamped their coding standards, deprecated old C/C++ idioms, introduced new ones, developed internal tools, adopted static analysis, and instituted a culture of security design reviews that starts before the first line of code is even written. As a result, a major "indie" Microsoft finding is a big deal. You'd be naive to put it on some fly-by-night auction site; a Microsoft remote code execution finding is already liquid in the grey market today.
The SPDC VM is not Java. I don't think you've asked the right questions of your "people at IBM who wrote the JVM used to play BD+". Here's Avi Rubin describing the SPDC VM:
The SPDC Virtual Machine specification defines a MIPS-like instruction set consist-
ing of 59 standard machine operations (along with several reserved and vendor-defined operations.) Each machine instruction is encoded as a 32-bit value. The Virtual Machine provides content code with two memory areas, one for the content code and data, and another undefined area which can be used as defined by the device
manufacturer. The VM also defines a set of 32-bit registers, a Program Counter, and
an Instruction Filter, which is applied to instructions before execution.
(In case you're wondering, the JVM is not a "MIPS-like instruction set on 32-bit registers with a Program Counter and an Instruction Filter" --- but that wouldn't stop you from implementing such a VM IN Java, just as the JVM is itself rarely implemented in hardware --- thus the "V" in "VM".)
I think you're grossly underestimating how good computers are at counting stuff. We're not profiling the whole system; we're profiling (when we profile; there's more up our sleeves than that) microarchitectural details changing between trivially tight groups of instructions.
The point of virtualization is to provide enough of an illusion for any given program to run correctly, not to defeat an adversary attempting to fingerprint the platform. It's not hard to make a compelling case for this: detecting VMWare is trivial, and VMWare is far and away the most popular virtualization platform.
I don't know why you assume we're using network servers to perform measurements. You don't need an external reference to detect the fact that thousands of CISC-level X86 instructions are running on a chip any time you invoke CPUID. You also don't need the TSC to do it.
I have no idea why you are assuming that it is hard to differentiate between Qemu and Blue Pill, Blue Pill and VMware, or for that matter VMWare and Parallels. But the fact that you think Transmeta is an obstacle for us, when Transmeta supports neither the AMD nor Intel hardware virtualization extensions in question, tells me we're simply on a different wavelength. I'll take you at your word that there's some important point you're making. If you'd like to produce a hardware-virtualized rootkit for us to (attempt to) detect, we'd be happy to show you the point we're trying to make.
I'm not sure we're talking about same "field", if you think what Joanna is doing is infecting something like VMWare. Joanna is using the trap-and-exec virtualization extensions of the AMD hardware to hide code and intercept system activity. She's not installing a dynamic-code-rewriting full-scheduling virtualization package on the machine.
Hardware virtualization works at a layer above software virtualization. Unless VMWare is now using VTX/SVM (ring -1), you can install a VTX/SVM hypervisor over VMWare (ring 0), and therefore hyperjack a VMWare machine. But if you already have a VTX/SVM hypervisor installed, that hypervisor can trivially prevent ring 0 code from hitting ring -1.
When hardware virtualization is widespread, Blue Pill will be moot; we will be talking about individual vulnerabilities inside of hypervisors, not about a general class of exposure on the platform.
Without conceding anything about "how" we're doing detection (there are a lot of "how"s), can I ask you to explain why timing tests are "impractical" in real-world settings? I can tell when McNortafee starts running because the box slows to a crawl. I lose compute and IO for a solid minute.
Joanna already stipulated: we can't hang the CPU for more than a second. While we don't agree that this is a reasonable requirement (I feel like virtually all commercial AV software violates it routinely --- and they're doing it just to look for viruses!), we concede it freely.
We keep seeing words like "in a lab setting" and "in theory" and "commercial-grade" thrown around. If Joanna chooses to make those words precise by attaching stipulations to them, we are likely to agree, as we have with all her other stipulations (apart from arranging her to get paid $416,000 by McAfee, EMC, or Kaspersky; first we'll arrange to get us paid $416,000, but that will take awhile). But in a free-form argument, I find the words themselves utterly unconvincing.
Slashdot Mirror
Non sequitur. Whatever you may think of their politics, it's manifestly true that media companies make more money immediately after a title's release. There's nothing inconsistent about them defending those profits while working towards some complementary long-term goal.
What, exactly, does that have to do with whether BD+ is going to work or not?
If the encryption is computationally cheaper, then the decryption is computationally cheaper. What four Slashdot moderators voted this stupid comment up?
No, it's a riff on (a) Black Hat, the industry's leading vulnerability research conference, (b) Black Hat, the term of art for people who break software, and (c) Blue Badges, the slang internal term for MSFT full-timers.
Which is why modern smartcard-protected systems don't have trivial boolean checks; they use the card as an encryption server to decrypt data necessary to access the stream. There is no opcode byte you can patch to bypass the card, because the card is mathematically inline with the stream. It sure sounds like the systems you work on are easy to beat. The P(n) DirecTV cards, not so much.
Yeah, because that's pretty much exactly how blogs work today.
There are few problems DNSSEC solves that SSL/TLS won't do a far better job solving. SSL/TLS deployment is almost universal. With the vast effort we've spent fighting over how to secure a tiny portion of the Internet protocol stack, we could instead have come up with a way to make verifiable SSL certificates free and easily acquired. I wrote about this at length earlier this year.
Furthermore, DNSSEC is a mess. It has taken over ten years to come up with a protocol that a plurality of operators will agree to deploy --- and that protocol hasn't even been deployed yet. Until NSEC3 (or, in the alternative, whitelies) is standardized, the result of that 10+ year effort is a protocol that publishes full zone contents to the world. And have you looked at how NSEC3 works? It's literally a Unix-style password file encoded into DNS zones. I wrote about this at length earlier this year as well.
Finally, DNSSEC will break the DNS. Everyone who takes the time to read comments on Slashdot has dealt with "expired SSL certificate" dialogs in their browser. Everyone has clicked past them. DNSSEC presents the same problem, across the entire DNS, but offers no "click-through" to deal with the situation: DNSSEC works below the API layer, and there is no chance gethostbyname is going anywhere in the near future.
Did you know that DNSSEC doesn't even secure the DNS communication between your browser and your DNS server? There's a whole other protocol --- TSIG --- that handles the "last mile" of DNS security.
Personally, I would be highly skeptical of "security" analysis from companies like Infoblox that claim DNSSEC adoption has anything to do with the security of the Internet.
No, you don't. Random number generators are where the keys for AES and RSA come from.
Be fair: the only researcher saying that "hypervisors can be detected, but rootkits can't" is Joanna. The rest of us, from what I can see, agree: you might not be able to detect Blue Pill by name, but you can detect unauthorized virtualization, even if you're already legitimately virtualized. Currently, the only source of unauthorized virtualization? Blue Pill.
That's simply not how it works. This isn't DOS, and there isn't a simple BIOS call the OS uses to retrieve the current time. Start here: the X86 has a 64 bit timebase register, the TSC, which reports cycle-count time in about 150 cycles directly from the hardware. Joanna tried to virtualize the TSC and found that she couldn't do it reliably under AMD SVM. She had to resort to dynamic code translation, VMware-style, to detect and modify code that probed the TSC. The problem with that approach is left as an exercise to the reader, who is encouraged to read a few back issues of 40Hex.
It's funny that people can forget the fact that the CPU is itself a clock. Which is why you can time a hypervisor with a simple counter loop, like Edgar Barbosa did. Joanna conceded that she had no effective defense against this approach either.
"Undetectable to grandad"? Asinine.
The threat model facing rootkits is not end-user computer savvy. It's conventional anti-malware software. The question isn't whether the person sitting at the computer is smart enough to notice a 60% slowdown. It's whether the impact the rootkit has on the system is reliably measurable, either directly or through a side-channel, in a way that can be harnessed by Norton Antivirus. If it is, you lose; your "undetectable rootkit" is now literally a bullet point on the packaging of a security product, making the AV companies money.
As for the clocks: there are tens of them in a conventional X86 box. You're probably thinking of the RTC, and you may have heard of the TSC. But what about the high performance clocks? The ACPI timers? Or how about the implied timers driving device events? Remember the VGA blanking interval? Assuming you know where all the clocks are, now figure out some protocol to keep all your perturbations of these clocks consistent.
Joanna is doing great work, but it is being totally misrepresented in comments like these. Her challenge is nowhere nearly as simple as the armchair quarterbacks are making it sound.
You clearly didn't read the paper, because it doesn't simply describe how "industry standard VMs operate". Garfinkel and Ferrie are talking about fundamental X86 architectural issues that make intercepting hardware accesses and emulating them in software perceptable to code running on the same machine. The Blue Pill VMM rootkit doesn't leave important instructions "unvirtualized", but it has to operate within the X86 memory hierarchy, and so remains detectable.
For example, the fact that a transition in and out of the hypervisor flushes TLB entries is not a "shortcut" taken by VMware; it's a design parameter of Intel's VT-x and AMD's SVM extensions. The fact that you can't reliably offset the TSC in AMD's SVM is also not a shortcut. And the fact that you can run a counter loop to detect VM exits regardless of the underlying hardware is not a shortcut.
How, exactly, do you propose that rootkit authors evade these problems?
Judy arrays are kind of silly, but I used to think tries were a great answer for parsing, because they provide O(m) abbreviation matching and access to ambiguous options. But then I realized: it's 1998 (hey, I'm old); why am I optimizing something that will run in individual milliseconds even if I search linearly?
I challenge: cite as an example any fixed set of strings (such as would be applicable for perfect hashing) for which a realistic perfect hashing scheme of any sort outperforms a statically-sized conventional chaining table using a trivial 33/37-style string hash. I don't think you can. Gperf languishes in obscurity for a reason.
Again, on the off chance that this helps anyone reading this pitifully long and silly thread: it is trivial to make getopt work on Win32, just like it was trivial to make strsep work on Linux when it only had strtok. I object to the argument that "portability" has anything whatsoever to do with whether you'd use getopt to parse arguments.
Like most of the other comments on this post, I find the idea of using gperf for "high performance argument parsing" superfluous and convoluted. In fact, I find the idea of a general-purpose perfect hash tool a bit superfluous as well; gperf languishes in obscurity for a reason.
Absolutely. There is no platform for which gperf is a better, more portable option for command line processing than getopt. I'm not sure what you think getopt does that is "tricky" under Win32. Its a string processor.
Are you seriously trying to argue that gperf is more portable than getopt?
I'm not sure why people are modding up a post that claims that the MSRC is a "rumor" inside of Microsoft. The MSRC is famous; news stories are written when people move to and from the group. They release all the Microsoft advisories, each of which typically elicit yet another news story. A position in the MSRC was listed as "one of the worst jobs in science" in SciAm (obviously wrong; people compete to get jobs there).
Why don't you tell us more about the security flaw you claim to have found?
No technology company in the world spends more money on security testing than Microsoft does. At any one time, it's likely that Microsoft retains a plurality of the security testing industry to perform code review and black-box testing on the myriad of products they are releasing this cycle. These aren't Microsoft employees; these are team members of the boutique security consultancies being paid directly by Microsoft to find vulnerabilities in products before they ship.
Microsoft is already paying for vulnerabilities. Investigate and you may find that just as Google singlehandledly jacked up the comp for every web-savvy C/C++/Java dev in the valley, Microsoft has amped up the bill rates for security consultants worldwide. Entire consulting outfits are built around pipelines of Microsoft work; some of the best and most famous researchers in the world work for these outfits.
Seven years ago, it was probably valid to single out Microsoft for carelessness about software security. But, just like this essay implies, software security is a problem that money can impact. Microsoft has lots of money. Since Windows XP, they have certainly put it where their mouth is.
There are differences between "true independent security research" and contract work for vendors. They're not clear-cut enough to make a value judgement. Researchers on contract to Microsoft get access to source code, developer documentation, test tools and the dev team. They also find problems before customers are exposed to them. On the other hand, indie researchers don't have to pass phone screens, know how to sell, or have the right contacts. Both groups find stuff.
It's worth noting that the overwhelming majority of external Microsoft findings in 2007 come from vendor-sponsored "research labs", usually attached to IPS signature farms (like the ISS "X-Force"). These groups strain the definition of "indie", are already well-compensated, and will continue to harvest findings whether or not an incentive scheme is created.
In any case, "WabiSabiLabs" is unlikely to have any impact here. Every major product Microsoft releases has been audited by a competant third-party. Microsoft has re-vamped their coding standards, deprecated old C/C++ idioms, introduced new ones, developed internal tools, adopted static analysis, and instituted a culture of security design reviews that starts before the first line of code is even written. As a result, a major "indie" Microsoft finding is a big deal. You'd be naive to put it on some fly-by-night auction site; a Microsoft remote code execution finding is already liquid in the grey market today.
The SPDC VM is not Java. I don't think you've asked the right questions of your "people at IBM who wrote the JVM used to play BD+". Here's Avi Rubin describing the SPDC VM:
(In case you're wondering, the JVM is not a "MIPS-like instruction set on 32-bit registers with a Program Counter and an Instruction Filter" --- but that wouldn't stop you from implementing such a VM IN Java, just as the JVM is itself rarely implemented in hardware --- thus the "V" in "VM".)
The person I know who's involved with BD+ co-designed BD+.
I think you're grossly underestimating how good computers are at counting stuff. We're not profiling the whole system; we're profiling (when we profile; there's more up our sleeves than that) microarchitectural details changing between trivially tight groups of instructions.
The point of virtualization is to provide enough of an illusion for any given program to run correctly, not to defeat an adversary attempting to fingerprint the platform. It's not hard to make a compelling case for this: detecting VMWare is trivial, and VMWare is far and away the most popular virtualization platform.
I don't know why you assume we're using network servers to perform measurements. You don't need an external reference to detect the fact that thousands of CISC-level X86 instructions are running on a chip any time you invoke CPUID. You also don't need the TSC to do it.
I have no idea why you are assuming that it is hard to differentiate between Qemu and Blue Pill, Blue Pill and VMware, or for that matter VMWare and Parallels. But the fact that you think Transmeta is an obstacle for us, when Transmeta supports neither the AMD nor Intel hardware virtualization extensions in question, tells me we're simply on a different wavelength. I'll take you at your word that there's some important point you're making. If you'd like to produce a hardware-virtualized rootkit for us to (attempt to) detect, we'd be happy to show you the point we're trying to make.
I'm not sure we're talking about same "field", if you think what Joanna is doing is infecting something like VMWare. Joanna is using the trap-and-exec virtualization extensions of the AMD hardware to hide code and intercept system activity. She's not installing a dynamic-code-rewriting full-scheduling virtualization package on the machine.
Hardware virtualization works at a layer above software virtualization. Unless VMWare is now using VTX/SVM (ring -1), you can install a VTX/SVM hypervisor over VMWare (ring 0), and therefore hyperjack a VMWare machine. But if you already have a VTX/SVM hypervisor installed, that hypervisor can trivially prevent ring 0 code from hitting ring -1.
When hardware virtualization is widespread, Blue Pill will be moot; we will be talking about individual vulnerabilities inside of hypervisors, not about a general class of exposure on the platform.
Without conceding anything about "how" we're doing detection (there are a lot of "how"s), can I ask you to explain why timing tests are "impractical" in real-world settings? I can tell when McNortafee starts running because the box slows to a crawl. I lose compute and IO for a solid minute.
Joanna already stipulated: we can't hang the CPU for more than a second. While we don't agree that this is a reasonable requirement (I feel like virtually all commercial AV software violates it routinely --- and they're doing it just to look for viruses!), we concede it freely.
We keep seeing words like "in a lab setting" and "in theory" and "commercial-grade" thrown around. If Joanna chooses to make those words precise by attaching stipulations to them, we are likely to agree, as we have with all her other stipulations (apart from arranging her to get paid $416,000 by McAfee, EMC, or Kaspersky; first we'll arrange to get us paid $416,000, but that will take awhile). But in a free-form argument, I find the words themselves utterly unconvincing.
The difference between what Joanna "gets paid" and what she bills at is very small.