Archive for January, 2007
Dave G. | January 30th, 2007 | Filed Under: Industry Punditry
Ryan Naraine, formerly of eWeek, now of ZDNet, wrote about Argeniss’ database rootkit being not only available, but for sale as part of their 0Day Exploits Pack.
I don’t know why we haven’t seen more of these in other applications. Lots of places to hide rootkits, especially in the web app space. There are so many places to hide code in web, app or database layers, not to mention CMS systems. The nice part is, most of this is going over SSL, so it’s hard to detect at the network layer. MTAs also have a ton of places for code to run that people are unlikely to notice. And we haven’t even gotten into client-side apps…
2 Comments
Thomas Ptacek | January 27th, 2007 | Filed Under: Disclosure, Uncategorized
Matt Blaze on vulnerability discovery versus causation: “stop saying that researchers ‘break’ systems —- the system was ‘broken’ before they got there”. Short and sweet, unlike anything we write.
11 Comments
Thomas Ptacek | January 27th, 2007 | Filed Under: Disclosure, Industry Punditry, Uncategorized
Abuzz, we apparently are, about Gadi Evron’s ISOI2 event —- a
“worst-kept secret” held on Microsoft campus, a “Yalta”, putting
Microsoft, Cisco, Symantec, and Trend Micro all in the same room.
I have two comments.
First: it can’t be a secret if it has a web page —- complete with an
agenda on it, nor can it be a secret if Cisco’s deck is “NetFlow
Revisited” and Trend’s is “Using DNS as an Early Warning System”. Stab
in the dark: you can get all the technical content from these
presentations from Google. So, don’t feel bad, Alan.
At least, not about ISOI2. Because, second, Microsoft really does
arrange “secret” summits, where “secret” can be defined as “includes
presentations you can’t see”. They’re called Blue Hat, and they’re
about collaborating with researchers to close the holes in Microsoft’s
products. Cisco hosted an “ISOI” last year; next year, my money’s on
Symantec. But no other company (that I can talk about) hosts
anything like Blue Hat. Which is a shame, because Blue Hat seems very
useful.
(Full disclosure: I haven’t presented at or even attended Blue Hat,
but Matasano has presented there multiple times.)
(Caveat: Maybe you can find Blue Hat decks online —- I have no idea,
but, it shows to go ya, nothing important in security today is really
all that secret.)
I’m not sure the ISOI crowd really positioned this meeting as
“secret”; it seems more like the botnet version of the Anti-Phishing
Working Group. But Alan sure seemed to take it personally. Buck up,
Alan!
11 Comments
Dave G. | January 26th, 2007 | Filed Under: Apple
From KF’s petition:
To: Apple Community
It is apparently common knowledge that when operating under Apple’s OSX platform any user with admin privileges already has root access. The public feels that even without putting in a password anyone in the admin group is already the equivalent of root.
In efforts to minimize the apparently unnecessary dialog boxes that ask for permission to go from gid=admin to uid=root we are hereby petitioning Apple to remove any further use of dialog boxes when making the transition from gid=0 to uid=0. Since the admin group is ALREADY root why can’t you just stop asking us for authorization?
I like satire. And I have criticized KF over admin-to-root bugs in the past. I believe I called them Moot. He responded in kind, and brought up some valid points. And he right in saying that they are security vulnerabilities. They just aren’t serious ones. I suspect this petition is in response to the criticisms of some of the recent MOAB findings that are admin-root privilege escalations.
I would also add that application authorization is not just about letting a program temporarily gain privileges, it also lets the user understand that a privileged operation is about to occur. And even for ‘legitimate’ applications there is value in know it is about to occur and allowing it to stop.
From a research perspective, I think there are better findings to be had in Mac OS X. And I’ve seen KF find better bugs.
ps: Technically, admin is gid 80 not 0 
8 Comments
Thomas Ptacek | January 25th, 2007 | Filed Under: Defenses, Uncategorized
Nate Lawson posted this in response to our last story, and I’m promoting it because it says what I tried to say, only clearer and more simply. In fairness, I’ll promote any comment Joanna asks me to as well.
There is a well-known problem of “code trying to understand code”: the Halting Problem. If Tom comes up with a technique for detecting a hypervisor on CPU v1, Joanna can come up with a technique that avoids the detection (assume she can update the hardware for CPU v2).
But then Tom gets to run his old technique on all CPU v1’s and try to find a new technique for CPU v2. And then the cycle can repeat with Joanna updating her approach for CPU v3.
Assuming both people are dedicated to playing this game forever, Tom wins percentage-wise because CPU v1 is not immediately retired and he’s slowly building up a pool of CPUs with different characteristics. It doesn’t matter that his codebase is growing because he only needs one trick per CPU version. But Joanna needs to support all CPU versions and all approaches to all CPU versions (n^m). To win, Joanna would have to force old CPUs to retire more quickly than Tom can update his detection logic.
But you’re also forgetting that at some point, the CPU vendor is not incentivized to keep playing the game. If, for instance, cache timing variance became so sophisticated that the vendor had to consider flushing the cache completely, they’d probably stop there. CPU vendors have other goals (i.e. performance) that directly conflict with hiding virtualization.
You can see the kind of effort it takes to eliminate covert channels in rainbow book systems. That kind of cost is hard to justify in the commodity CPU world, and is only effective for some subset of all possible covert channels.
The way I like to say it, “Show me your undetectable hypervisor, and I’ll show you a CPU that never had any errata.” Take a look at the length of errata sheets for modern CPUs, then add in chipsets and peripherals. We’re headed the opposite direction from Joanna.
1 Comment
Thomas Ptacek | January 24th, 2007 | Filed Under: Reversing, Uncategorized
The new version of Sabre’s BinNavi can single-step, trace, and
graphically navigate Cisco IOS and NetScreen ScreenOS. Without
source. I don’t have much to add to this story. Tally ho!
1 Comment
Thomas Ptacek | January 24th, 2007 | Filed Under: Defenses, Disclosure, Uncategorized
Joanna Rutkowska responded, below.
1.
Recall that hardware-assisted virtualization, as exploited by
Dino’s Vitriol and Rutkowska’s BluePill, hides code in the “ring -1”
hypervisor privilege level carved out by the AMD and Intel
Virtualization Extensions (SVM and VT, respectively). In this
environment, we can arrange for the CPU to trap to our malicious code
any time someone does something to try to detect us, and emulate the
innocuous response.
For example, under VT, the CPUID instruction could betray the presence
of virtualization extensions. So VT traps to the hypervisor (where
we’ve stuck our rootkit) when CPUID is executed, and allows us to
emulate the response. From a functional perspective, you can’t look at
the result and know it was emulated. You can, however, use the cycle
counter to time the CPUID instruction; a trap and the software code
executed to emulate CPUID will take noticeably longer than a “native”
CPUID execution. “Unfortunately”, Intel has arranged for hypervisors
to control the cycle counter as well; the cycles consumed during
virtualization can be trivially masked with about 5 lines of C code.
So the blog debate about detecting virtualization has revolved around
using “trusted” clocks, such as those on an uninfected machine, to
time the instructions. Of course this will work, but it’s a pain.
2.
Last September, Peter Ferrie at Symantec made this blog claim:
Anyway, I found something that you can do in the guest that the
hypervisor can’t see until after it’s happened; so, it can’t hide
the side effects. It doesn’t need a network connection and it
doesn’t need a user to time anything. It’s also quick (it executes
in one timeslice), but, I still can’t tell you how I did it.
Today, I read Ferrie’s paper describing the trick. It’s very similar
to one of the (many) tricks we recently presented in a speaking
engagement.
You can’t trust the TSC timing of the CPUID intruction, because the
hypervisor can simply mask the cycle overhead of any VM trap. But
you might be able to trust the TSC timing of side effects that don’t
cause VM traps.
For instance, you can saturate any of the caches in the system, and
baseline the cycles it takes to read known cached values. Then you
cause VM trap (for instance, by executing CPUID). The VM exit and
entrance, along with the software that runs in the hypervisor to
emulate CPUID, will evict cache entries. When you get control back
from the hypervisor, you loop timing the “cached” values again; if
they differ significantly, you’re virtualized.
Ferrie uses the TLB cache; the TLB keeps you from having to walk the
whole page directory hierarchy when you access a virtual
address. There are other caches you can saturate. I could give details
to Joanna, or just refer you to any of the last N blog posts we’ve
written about timing attacks against cryptosystems; the differences
between timing RSA and timing a hypervisor are:
Unlike the crypto attacks, hypervisor timing is done with the
target on the same CPU core and the same CPU thread and the
same CPU resources as the “attacker”.
Similarly, unlike in a crypto timing attack, a hypervisor
timer can quiesce the whole system (for a few milliseconds),
which dramatically reduces the signal/noise ratio.
Unlike the crypto attacks, the “signal” you’re looking for
isn’t complex; you don’t need a trace of “branches taken” in
a known piece of code, averaged out to eliminate noise. You
just have to observe a causal timing relationship with CPUID
(or something else that causes a VM exit).
Remember also that BluePill “emulates” the SVM instructions, allowing
for nested VMs. BluePill therefore has to pretend to allow code to run
in “ring -1”, to complete the illusion that code is talking directly
to the hardware. The only difference between “ring 0” and “ring -1” is
that there are additional instructions available in “ring -1”. This is
a long-winded way of saying that you can detect a surreptitious
hypervisor even on systems that are “supposed to be” running hypervisors.
3.
So that’s the timing attack on hypervisors. We use the following
terms:
Direct timing executes instruction sequences that are known
to cause VM exits, and counts the cycles they take, looking
for abnormally high results.
Indirect timing executes those same instruction sequences, but
brackets them with code that saturates a chip resource,
baselines the resource, and then checks that the timing
remains invariant after the VM exit.
We demoed Direct Timing, against our Vitriol rootkit, at Black
Hat. We’ve written several Indirect Timing test cases since then; we
hoped to demo at Black Hat this year, but Ferrie has scooped us!
But, at the risk of putting both Ferrie and Rutkowska on our scent,
that is far from the end of the story. Ferrie’s paper is premised on
the idea that hardware virtualization confers “functional
transparency” to a rootkit —- that is to say, there’s no functional
difference to observe if hardware virtualization is being used to hide
a rootkit (Ferrie presents this in stark contrast to software
virtualization, like VMWare and Bochs, which offer a myriad of
observable functional “tells”).
Not so!
Here’s a simple example. It’s not ours, but it illustrates the point
nicely.
AGP, the graphics bus, wants to offer graphics chipsets access to a
physically contiguous buffer of host memory. But it’s hard for a
kernel to promise physically contiguous memory in the quantities
needed; the kernel is better used to assembling large amounts of
memory out of a bunch of physically discontiguous pages; these big
chunks of memory can be “virtually” contiguous on the host, using the
MMU, but that doesn’t do a graphics chipset much good.
So AGP uses a scatter/gather mechanism called the GART. The GART is a
physical-to-physical memory mapping mechanism that establishes an
aperture in system memory. It appears contiguous, but is actually
backed by discontiguous pages and a programmable mapping table.
You can use the GART to alias physical addresses, and scan
memory. Yes, attempts to program the GART can be intercepted and
emulated. But they aren’t. That would be work!
4.
And so you have one of the central challenges of trying to install an
invisible malicious hypervisor. VMware doesn’t have this problem; it
just doesn’t give you a GART to play with, and you don’t care, because
you know you’re being virtualized. But Joanna can’t do that! She has
to perfectly emulate every detail of the CPU and the chipset, while
selectively guarding and emulating behaviors betray the presence of
the hypervisor.
If this sounds suspiciously similar to the problem of passively
observing network traffic between two hosts whose operating systems
you don’t know on a network filled with chaff traffic designed to
confuse the observer, that’s because it’s the exact same
problem. But turned against the attacker. Ah, irony.
So we have the following set of tactics for detecting virtualization:
Timing Challenges
Functional Challenges
5.
It turns out, from where we stand, that virtualization is kind of a
sucky place to hide rootkit code. There’s a jungle full of places to
hide kernel code; “orphaned” kernel threads and backdoored page fault
handlers are probably just scratching the surface. From what we can
see, there’s no one good way to detect all kernel rootkits. But a
virtualized rootkit is a different story: all you ever have to know
is, “on this Pentium 4 633, when I’m in ring -1, does this system
behave in a way that indicates it’s already virtualized?”.
There are some really easy functional and timing traps you can fall
in to. Some of them are easy to defend against, if you know they’re
there. And I didn’t think of all (or most) of them. So instead of
telling you about them, I’ll:
Hope I’ve gotten some credibility from this post, and
Say “95faf2cfb27b4e271a8943ad44f7d865”, which is the
SHA-1 of a quick text file list of the tricks we know about.
When Ferrie or Joanna publish enough of them, I’ll post the
tfile. =)
It’s nonced, by the way.
Virtualized rootkits are detectable, without external clocks.
(By the way: Ferrie’s paper is excellent, and goes into a huge amount
of errata detail he found in software hypervisors).
13 Comments
Dave G. | January 24th, 2007 | Filed Under: Disclosure
Is there any topic in computer security more contested than vulnerability research and disclosure in all of its forms?
Most recently, CSO Magazine had a couple of industry luminaries write essays on the subject, either in support of or against full disclosure. Schneier, Microsoft’s Mark Miller, and Marcus Ranum all voiced their opinions. Schneier favors it. Miller advocates responsible disclosure. Ranum opposes.
I don’t really know why I continuously feel the need to try and change other people’s minds on this subject, but here I go again…
You can sum Marcus’ points up with these quotes:
From where I sit, it looks like the vulnerability rate is pretty much a constant. If the proponents of disclosure were right, their stated objective—browbeating the vendors into making their products better—would have been accomplished years ago. But we’re speaking frankly, here, aren’t we? So, as one adult to another, let me tell you why it won’t work: because it was never about making software better. In fact, it was never about making your security better. That’s right. Now that we can look back at 10 years of what disclosure has brought us, it’s brought us…well, nothing much. Nothing much, that is, except a grey-market economy in exploits, where independent “vulnerability researchers” attempt to cash in by finding new attacks that they can sell to security companies or spyware manufacturers—whichever bids higher. Nothing much unless you count the massive amounts of “free” marketing exposure for companies that trade in exploits. The sad part about it all is that they’ve managed to convince you they’re doing you a favor. It looks like a pretty expensive-looking “favor” to me!
Indeed, from where you sit, Marcus. But I think it’s time you pulled your chair up to the table.
It’s the classic straw-man argument: The number of vulnerabilities remain constant, and therefore vulnerability research isn’t changing the behavior of vendors. Ridiculous. Both the number of researchers and the number of applications they scrutinize have increased dramatically. The only way to measure the success of disclosure is to see how individual projects have managed to reduce both the number and severity of their vulnerabilities. And counting Bugtraq sheep isn’t going to do it.
Here are some projects disclosure has quantitatively improved:
- Linux Distributions
- FreeBSD
- NetBSD
- OpenBSD
- Sendmail
- BIND
- Apache
- IIS
- Windows XPSP2
Marcus concedes:
I think there are a few places where we can see signs of improvement. I know that Microsoft, Oracle and others have spent huge amounts of money improving the security of their software. Never mind the fact that 99.99 percent of the computer users in the world would rather they had spent that money making their software cheaper or faster, I suppose it’s a great thing to see that software security is being taken seriously. Security has gotten more expensive. But do you think security has gotten better?
I do think the security quality of software has improved in some software. You attribute the majority of security improvements in all install OS’s and all installed databases to disclosure. So, apparently, you think so too.
Oracle and Microsoft both spent tons of money because their customers would rather they spent the money on security. Security got expensive because security used to cost nothing. And we got what we paid for. Security got expensive because people wrote applications for years and never once thought about security. And now they have inherited the challenge of having to secure that. If they had thought about these problems sooner, security would have been significantly less expensive.
I know you won’t believe me when I say this, but I would love it if software were secure, so that companies could spend the time making things faster and cheaper. But blaming vulnerability researchers for pointing out that software isn’t secure is silly. The problem is not that vulnerabilities are published, it’s that they exist at all.
If you want to change the vulnerability research community, here’s an idea. Make better software. Build safer languages. Teach developers how to write secure code.
Another thing that I know you take offense to is that researchers say they are doing things to make things more secure, but also benefit personally from their actions. Newsflash, from one adult to another: it’s ok in life to have more than one motivation. If I were to ask you why you work in computer security, I am sure you would come up with a list of benevolent reasons. Would you mention your paycheck anywhere? Would the fact that you were compensated for doing something invalidate everything else? I’m guessing the answers are related to the fact that you didn’t give NFR away for free.
Look. We get it. You don’t like security researchers. You have called us pimps and compared us to buckets of spit.
If you really want to be part of the solution and not part of the problem, lets talk about other things you think the security community should do to bring vendors to the table to get them to take security seriously. Heck, getting companies to build and run fuzzers, source code analyzers and web app security scanners before shipping would put a good number of vulnerability researchers out of business.
7 Comments
Dave G. | January 23rd, 2007 | Filed Under: Apple, Disclosure
On January 1st, The Month of Apple Bugs released an overflow in the Quicktime handler for rtsp URLs:
A vulnerability exists in the handling of the rtsp:// URL handler. By supplying a specially crafted string (rtsp:// [random] + colon + [299 bytes padding + payload]), an attacker could overflow a stack-based buffer, using either HTML, Javascript or a QTL file as attack vector, leading to an exploitable remote arbitrary code execution condition.
Today, 23 days later, Apple released a patch.
QuickTime
CVE-ID: CVE-2007-0015
Available for: QuickTime 7.1.3 on Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.8, Mac OS X Server v10.4.8, Windows XP/2000
Impact: Visiting malicious websites may lead to arbitrary code execution
Description: A buffer overflow exists in QuickTime’s handling of RTSP URLs. By enticing a user to access a maliciously-crafted RTSP URL, an attacker can trigger the buffer overflow, which may lead to arbitrary code execution. A QTL file that triggers this issue has been published on the Month of Apple Bugs web site (MOAB-01-01-2007). This update addresses the issue by performing additional validation of RTSP URLs.
My questions to our readers is:
Did Apple patch this in a reasonable time period?
Was acknowledging MOAB a wise decision on Apple’s part?
18 Comments
Thomas Ptacek | January 20th, 2007 | Filed Under: Defenses
Catching up after a week of travel. A lay-up, from Rothman:
In blog land, it seems that printer attacks are now all the rage
(here). Personally, I think this is a bunch of security research
guys without enough to do. I guess if you have a PC-based printer
controller, then there is a potential problem. But of all the bots
out there, I don’t think a lot of them are spewing out postscript as
their day job.
Allow me to retort:
Malware that can reliably propagate across (say) all HP
JetDirect printers has the potential to disrupt a sizeable
percentage of all the paper-based business processes in
the industrialized world. With a very tiny bit of code, and
minimal cleverness beyond target selection. Nobody says the
Slammer authors had too little to do.
As the @stakers used to say, “printers are file servers. For
the files you tend to care most about.” Nobody says attackers
who target NetApps have too little to do.
There is nothing magical about the printers large enterprises
use to print checks, except perhaps for the MICR ink
cartridges. Nobody says people who attack banks and ATMs have
too little to do.
At the end of the day, networked printers are just embedded
computers, attached to unprotected internal networks. Why
bother with a trivially detectable rootkit when you can hide
yourself in a printer card that nobody has tools to scan?
Nobody says the Agobot authors have too little to do.
Like D.J. Bernstein chided me in 1996 when I accidentally posted a
Unix command that would give attackers control of your machine, “isn’t
security fun?”
6 Comments
