Archive for April, 2007
Thomas Ptacek | April 30th, 2007 | Filed Under: Uncategorized
One of the weird thing about Black Hat is that there are no
papers. You pitch a talk and deliver it in slides. The only lasting
artifact is a video of your presentation. Which is too bad; it makes
Black Hat research harder to cite.
If you’re doing vulnerability and reversing research this year, you
have a new venue: the First USENIX Workshop on Offensive Technologies
(WOOT ‘07). Think of WOOT as a peer-reviewed Black Hat and you’re not
far off (from what I can tell, there isn’t a single technical topic
that’s germane at Black Hat and not germane at WOOT).
Read the CFP. You don’t have much time! But then, if you’ve put
together a pitch for Black Hat, you’ve got most of what you need
already. I’m on the program committee, so I guess that means I look
forward to reading your submissions.
[Update: 5/1]
It’s official: you can absolutely submit something to Black Hat and WOOT. Your WOOT submission is an academic paper; your Black Hat submission is a talk.
12 Comments
Thomas Ptacek | April 26th, 2007 | Filed Under: Uncategorized
EXCLUSIVE: MUST CREDIT MATASANO
Numerous confirmed sources reporting to us, at this precise moment,
that successive blog posts turn out to be a crappy way to convey the
details of important vulnerabilities.
Seriously, folks: this started out fun, because we were dealing with a
laboratory-isolated specimen of a problem that Apple was in a position
to easily fix. But it turns out, that’s not the case. There are a lot
of things we’ve learned in the past couple of days that lead us to
believe that the QuickTime hole is going to cause real (read: Mom’s
bank account) problems.
The gathering miasma of unpleasant details about this vulnerability
includes:
… that it affects FireFox as well as Safari
… that it affects Windows as well as OSX
… that it may or may not be auto-updatable on non-Mac platforms
… that it affects IE7
… that it may, or may not, be difficult for bad actors to
reverse the vulnerability from the details already cleared
by 3Com
Thankfully, I think we can put to rest the notion that the exploit is
bouncing around in the wild, but that drama alone is reason enough
for us to think that posting information to our blog piecemeal isn’t a good idea.
3Com has paid $10,000 for this vulnerability, and controls
what details about it can be published. There are things users can and
should do today, before patches are released, to mitigate the
vulnerability. The entire world knows it exists, and a large body of
talented attackers has a head start on where to look for the details.
3Com is in a much better position to fact-check and publish information about this bug than we are. When they provide a URL or a 1-800 number or something to provide up-to-the-minute, fact-checked details about this finding, we’ll post it here.
Thanks for following along. We’ll have more to say about Mac security
in upcoming posts, but much less to say about our friend Dino’s
QuickTime finding.
11 Comments
Thomas Ptacek | April 25th, 2007 | Filed Under: Apple, Uncategorized
Remember what I said about “living dangerously”? Stop living dangerously, right now. Turn Java off in your browser. Watch this space for more details.
[Update: 1:43 EST]
There are unconfirmed reports, from multiple credible sources, that the challenge MacBooks from the contest were exposed to an unprotected wireless network, and that raw packet captures of the successful exploit have been taken by parties unknown to us.
We’re looking for comments from people involved with the contest for more details about the network topology so we can confirm this.
There’s a difference between the exploit being captured and the exploit being successfully hosted by attackers in the wild. Even so, this is a particularly virulent problem. It affects every mainstream browser on every mainstream desktop platform —- possibly excepting Vista. Disable Java in your browser until you’ve received a patch.
[Update: 1:30 EST]
InfoSec Sellout is blogging that they’ve reversed the vulnerability and also captured all the packets from the conference. Those claims have not been verified. InfoSec Sellout is not one of our sources. Their claims aren’t corroborated by any of the public record about the vulnerability, which, contrary to their report, doesn’t appear to involve “the way QuickTime handles Javascript”.
[Update: 2:30 EST]
Comment reprinted in its entirety, contradicting claims that the exploit could have been captured off the CanSec wireless network:
Someone may have reverse-engineered the vulnerability but they didn’t pull it off the network there. The network was very simple:
a WAP that was connected to a hub and to the router to provide Internet access. The Macs sat on the hub and the only other systems on there were the ones we used to monitor the network to ensure rules were followed and then K2’s when he ran the exploit. The WAP was routing traffic from the hub to the Internet, not sending it out over the wireless network.
We were sniffing the traffic on the wireless network and would have noticed if it had been getting traffic from the wired side.
Y’all know routing & switching protocols well enough to know that traffic destined for the Internet wouldn’t end up on the pocket wireless network. The AP doesn’t have enough smarts to mess up routing that way unless someone owned it (which is admittedly possible).
The point is, no one sitting on the wireless network would have been able to sniff the traffic from the wired network to the Internet.
[Update: 2:40EST]
This is turning into a game of telephone. We’re tracking a variety of reports both confirming and denying that information about the exploit has leaked. We have no confirmation that anybody besides 3Com and the affected vendors have details about this exploit. We think it’s important to be aware that there’s controversey about whether that’s the situation: if this exploit has leaked to the wild, it is very important that you update your browser configuration.
We’re going to ratchet down the up-to-the-minute Drudge Report updates on this aspect of the story until we can confirm more details, but we’ll update this post as soon as we have something conclusive.
[Update: 6:55EST]
The bulk of the “it leaked!” leads in this soap opera are not panning out, fortunately for all involved. We’ll post a round-up of the stuff that did happen later on.
26 Comments
Thomas Ptacek | April 24th, 2007 | Filed Under: Apple, Defenses, Disclosure, Industry Punditry, New Findings
This just in: anonymous sources at 3Com confirm Dino’s QuickTime vulnerability is exploitable in IE7 and IE6 on Windows XP.
Watch this space for details (Is XPSP2+DEP reliably exploitable? You can’t run IE7 on XPSP1 —- so, probably! Vista?) as they’re made available to us.
I think we can now safely conclude: this is a hell of a finding. Way to go, Dino!
Irony Alert
Consider the possibility that the one platform this vulnerability won’t work against is Windows Vista.
[Update: 4/25]
As usual, the comments on this post are much more valuable than anything I’ve written. Rosyna Keller and Skywing are discussing the protection mechanisms in IE6/IE7 (anyone know what the equivalent protections are in Safari? Oh, wait…).
More importantly, our source at 3Com has re-confirmed that IE6 and IE7 are vulnerable to this attack. More details about the vulnerability as they become available.
[Update: 4/27]
I’m simply deleting comments that say things like “XXX is not vulnerable” or “YYY is vulnerable” without evidence.
32 Comments
Dave G. | April 24th, 2007 | Filed Under: Apple, Reversing
Believe it or not, we don’t just talk about OS X security, we actively search for new vulnerabilities in it. I have found a number of vulnerabilities, both local and remote in OSX and OSX Server over the years. This post is the start of a series of posts that explain some of the tricks that we use when assessing applications on Mac OS X.
For the most part, these tips apply to both GUI and command line apps. This isn’t rocket science, but is a good primer for people looking to dive into OSX vulnerability analysis. I am going to use Safari as an example, since it is somewhat topical. It isn’t the best example since enough of it is opensource that you can gain a lot more insight via debug builds.
- CrashReporter is probably the most useful utility for identifying that an application crashed, and getting some basic insight into what caused the exception. You have probably seen elements of CrashReporter when an application crashes on you. While it can be customized on a per application basis, most applications use the default. Here is an example of a CrashReporter dialog:
If you click on Report… you will see information on CrashType. This will be your first potential clue into what might have caused the crash. Especially if you see a BAD_ACCESS along with an KERN_INVALID_ACCESS that you control. In this case, it is not obvious that I control this value, although it does look like it is an ASCII value:
Another bad sign is if you see EXC_BAD_INSTRUCTION. Under x86 it is less likely you will see this with a straight up vanilla stack overflow, but there are other forms of memory corruption that can elicit this error.
And scrolling down, you will see register state. There is more information that is useful, including which thread you crashed, as well as which function caused the exception.
One neat OS X feature is the ability to change this behavior via the defaults command. By settings the CrashReporter DialogType to “developer”, you will now have the option to attach to the process via GDB, by clicking a button.
In a Terminal window, execute:
defaults write com.apple.CrashReporter DialogType developer
Now lets look at that same crash:
Note: This won’t work on basic command line UNIX applications.
If you aren’t using the GUI, you can also monitor files in ~/Library/Logs/CrashReporter or /Library/Logs/CrashReporter. Files will be named .crash.log if CrashReporter can figure out the name of the application that crashed. Otherwise you will see names like ???.crash.log or Exited process.crash.log. Finally, if you are fuzzing the kernel, you can find information on kernel panics in /Library/Logs/panic.log.
- Malloc Debugging
The OS X malloc implementation contains a lot of useful features for understanding when (and how) memory corruption is occuring. These features are controlled via environment variables. These variables are both outlined inside of the malloc man page and via setting the environment variable “MallocHelp” and executing a command:
Before I go further, if you are interested in understanding more about exploiting Apple’s malloc() implementation, you must read FelineMenace’s paper on the subject (They also discuss the MallocDebug facilities).
The variables I set are:
MallocLogFile The default behavior for the debugging modes for malloc output to stderr. For GUI apps, setting MallocLogFile makes it much easier to monitor the output. You simply set the environment variable to the name of the file you want output written to.
ThisOldVuln Moment #1: There was a vulnerability associated with this environment variable where a user with an account on the system could overwrite arbitrary files and become root.
MallocGuardEdges Helps identify potential buffer overflows by putting guard pages on either side of large blocks. It won’t detect all issues, but it can help.
MallocScribble Useful for detecting when an application is writing to an region of memory that has already been freed or memory that was never initialized. Both of these conditions can be exploitable security issues.
MallocBadFreeAbort While a simple double free or freeing non malloc()d regions of memory are generally not considered exploitable conditions under OS X, there are more complicated double free() situations that can be exploitable. Besides, in 1996 everyone I knew said that heap overflows were unexploitable.
MallocCheckHeapStart,
MallocCheckHeapEach,
MallocCheckHeapAbort,
MallocCheckHeapSleep
These three variables control when to start checking for heap corruption, how often to check, and what to do when heap corruption is identified. I would generally recommend Abort while fuzzing. When you want to debug, switch to sleep so that you can attach at the point that corruption was identified.
Here is my Info.plist file for Safari:
As you noticed from the above, somethings caused Safari to crash. Figuring out what caused the crash isn’t always easy, especially with complex applications like Safari. In this case, we get another potential clue via the malloc:
Minor Note: The output was edited down.
Less Minor Note: 1.5G is a large number to get passed to vm_allocate (assuming the output here is correct).
This will be a living document (even though I hate that term). I know smarter people read this blog and would love feedback. Future topics will include file system access, deeper dive on debugging facilities and automation.
3 Comments
Thomas Ptacek | April 23rd, 2007 | Filed Under: Apple, New Findings, Uncategorized
New details emerging about Dino’s MacBook finding (don’t you just love vulnerability markets?)
Dino’s finding targets Java handling in QuickTime.
Any Java-enabled browser is a viable attack vector, if QuickTime is installed.
Apple’s vulnerable code ships by default on MacOSX (obviously) and is extremely popular on Windows, where this code introduces a third-party vulnerability. (Irony!)
Firefox and Safari are confirmed vectors on MacIntel. Users of both browsers are placed at risk by this vulnerability in Apple’s code.
Firefox is a presumed vector on Win32, if Apple’s QuickTime code is installed. Users of Firefox on Windows are presumed to be at risk because of this vulnerability in Apple’s code.
Disabling Java stops the vulnerability.
42 Comments
Thomas Ptacek | April 22nd, 2007 | Filed Under: Defenses, Uncategorized
If you read our blog you already read this story, but, Bruce Schneier
wrote an editorial in Wired about how the security market converges to
snake oil just as the used car market converges to lemons, using the
Tweakers.net takedown of the “Secustick” as an example.
Long story short: a “secure USB stick” with “the ability to destroy
itself once an incorrect password has been entered” checks a password
stored in cleartext on the stick in software, with debugging symbols
present, to authorize access to unencrypted files.
And so, from the Tweakers article, a nit:
Checking the password and unlocking the files are two separate
processes. […] The most secure
sticks execute both encryption and unlocking on the chip. A somewhat
less secure method consists in comparing an encrypted password that
resides in the controller with one that is stored on the pc. […]
Less secure still is storing it in the stick’s memory,
since that can lead to the password being read from the chip. The
Secustick is another step lower on the ladder: the processes of
checking the password and unlocking the stick are executed entirely
on the pc
What year is this? None of these rungs on the “security ladder” are
secure; there’s A Right Way to solve this problem, which is, expand a
passphrase into a block encryption key using a slow adaptive hash.
The passphrase is stored nowhere, the encryption/decryption can
occur anywhere (after all, if you’re taking input from the keyboard,
who cares?), and no amount of messing with the code wins you access to
the data, which is encrypted under the passphrase rather than guarded
by the passphrase.
The Tweakers article is great, and this is one of the rare
non-technical Schneier articles that I actually found insightful, but
there’s a lesson being hidden here. If your “secure USB stick” uses
something other than PGP to encrypt data at rest, you should assume
it’s busted. You don’t need to wait for the 6-page Tweakers.net takedown.
[Edit: 4/24]
Ok, I shouldn’t use the words “A Right Way” without knowing The Right Way. Read the comments.
14 Comments
Thomas Ptacek | April 22nd, 2007 | Filed Under: Reversing, Uncategorized
You came for the Mac soap opera. You left to read about
anti-debugging/anti-reversing technology and
driver reverse engineering using virtual machines at Nate’s blog. As usual, Nate’s posts are not to be missed. See you there.
1 Comment
Thomas Ptacek | April 21st, 2007 | Filed Under: Apple, Uncategorized
Apparently this vulnerability is not that big of a deal because it doesn’t break root; it just gives attackers local user-level code execution.
Ok. So, commenters, fire away: name the assets you keep on your computer (email, personal documents, the contents of your Keychain) that I can’t get if I can run code under the same UID as you normally do.
[Update: 4/22]
Read the comments. Rosyna schooled me: Keychain is tighter than I gave it credit for, and X86 xnu made inter-process code injection harder. I hadn’t kept up with either of those things.
But, at the end of the day, it’s all still possible; you can’t ptrace-attach or Mach-inject if you’re an unprivileged user (anymore), but the dynamic linker and the Input Manager Cocoa feature still allows an unprivileged attacker to hop processes.
So, the challenge still stands. I broke your UID with a clientside code exec vulnerability. I got your Keychain secret by spoofing the dialog to you. I got your sudo password and your GPG key. Tell me what I can’t get from your UID that I could get from root —- on your box, right this minute.
77 Comments
Dave G. | April 21st, 2007 | Filed Under: Apple, Industry Punditry
Mac Punditry
I don’t know why I have to respond everytime I see someone trying to debunk myths about Mac OS X security, but apparently I lack free will. Over at Roughly Drafted, there is a long response on what he believes to be Mac OS X security fallacies. Let’s begin:
Opening an email URL that exposes a security flaw in Safari is both news to report and a problem for Apple to tackle, but reporting it as a remote exploit is inaccurate, irresponsible, and sloppy journalism, particularly for IDG’s InfoWorld, which purports to be an authority on computing.
Your definition is behind the times. A browser based vulnerability is considered to be a remote one by just about any person that is in the security industry. I understand what you meant, in that you think of a remote vulnerability being one where a client attacks a server. But, a Safari exploit is a remote.
For example, many schools are full of Macs; if they were easy targets because of wide open security flaws, school populations would see problems with Mac viruses. They do not. There are no real Mac viruses.
Mac OS 9 was no more secure from viruses than DOS was. There were close to 100-200 Mac OS 9 viruses compared to 50,000+ PC viruses. Explain to me how the security architecture of Mac OS 9 protected users from viruses.
Any security expert who is confused on that subject really needs to inform themselves better. IDG’s InfoWorld is doing the world a disservice to offer up such rubbish information on the subject. Perhaps it should be rebranded as ConjectureWorld.
Corvettes aren’t popular targets for theft because they are ubiquitous but rather because they are valuable. Similarly, if it were easy to remotely exploit Macs, they would offer hackers valuable targets both in environments where Macs are plentiful such as education, as well as sites where Macs are high profile goldmines, such as the iTunes Store servers.
How are educational environments high value targets? What other sites besides the iTunes Music Store servers? Because touting one site is not the best argument against the “its a marketshare/installedbase issue” claim. Especially if an exploit against Windows via a Malformed Word document sent as a resume to the HR department (*) has a high probability of compromising a large swath of the Global 2000.
(*) Example ripped from Marc Maiffret’s talk at OWASP.
Finally, even your analogy is wrong. Corvettes are not popular targets for theft. When you do the research on this, you are going to find the sad truth is that most of the commonly stolen vehicles are actually average cars like the Honda Accord’s and Toyota Camry’s. If a Corvette and a Honda were to be characters in an Apple commercial, which one would be played by Justin Long?
Listen up security pundits: hackers aren’t after fame, they’re exploiting security systems for money. As with any business, the easiest route is always to target the low hanging fruit first. In the computing world, that means exploiting PCs running Windows, not because they are common but because they offer an easy exploit for something of value: a way to send spam.
Ok. So, in the business of spam, I think we would all agree that the limiting factor in your ability to grow revenue is based on the amount of spam that you can send. If both Mac OS X and Windows were equally easy to compromise, would you target the smaller or the larger market?
In conclusion, I don’t think you in anyway disproved the notion that marketsize is related to number of exploits. Most of your arguments actually did not contradict the market share argument in any way.
The Office Paradox
Almost every pro Mac OS X security pundit will highlight the scores of zeroday vulnerabilities that affect Windows, and attack the code quality of Windows as being a primary factor.
In recent months/years, many of these have been vulnerabilities in Word, Excel and Powerpoint vulnerabilities. There is a version of Office for the Mac. Why do we not see rampant exploitation of Office/Mac vulnerabilities? Why haven’t we seen one case of it?
32 Comments
