16-Month Old Flash Bug Still Unpatched

Maybe Steve Jobs isn’t wrong about Flash; maybe it really is not reliably maintained. Matthew Dempsey has set up a web page showing a proof-of-concept example of a Flash vulnerability that hasn’t been patched, even though he reported it to Adobe in September 2008. As he says on his web page, “Despite numerous email exchanges with the Flash product manager about the bug, the bug report being hidden from the public for “security” reasons, and Adobe CTO Kevin Lynch’s claims otherwise, it continues to be an issue.” A more detailed explanation of the issue is found here.

Adobe gives a confusing response, suggesting that, since the bug was filed just as Flash 10 was being prepped for release, it wasn’t fixed right away. But they don’t say why it still hasn’t been fixed 16 months later. They claim it will be fixed in Flash 10.1, due to be released soon, though. Rest assured, Adobe will fix that bug someday.

But how about looking more closely at this bug. Why is a bug that causes a crash considered to be a vulnerability? When applications (or, in this case, plug-ins) crash, they open a door, in a way, allowing for the possibility of remote code to be executed, or other objects to be injected into a user’s software. Using Javascript injections on hacked websites, it is possible to provide booby-trapped Flash files to unsuspecting users. These Flash files can then allow remote users to potentially run code that can compromise a computer that simply went to a web page and may not have even seen the corrupted Flash file.

So what are your choices? Deactivate Flash, by uninstalling it? That’s always a possibility; you can download an uninstaller here. But Flash is widely used, for both on-line videos and other animated content such as games, and, alas, ads. For now, Flash is omni-present, and it looks like the only thing is to hope that this vulnerability is not exploited.

Intego’s Virus Monitoring Center is looking out for malicious Flash files, and VirusBarrier X6 will block them if any are found.

Should iPhone Users Worry About Rogue Apps?

What risk is there from “rogue” apps getting installed on iPhones? Swiss researcher Nicolas Seriot thinks it’s very serious, and he’s made a proof-of-concept app to show people. In a talk at this year’s Black Hat security conference, Seriot is discussing how apps on the iPhone can harvest data from a device. He says it’s easy for an application to retrieve the following data on an iPhone:

• Phone number
• Address book info
• File system information
• The 20 most recent Safari searches
• YouTube history
• E-mail account parameters (though not the password)
• The iPhone’s UUID
• The iPhone’s ICCID (it’s SIM card serial number)
• The iPhone’s IMSI (International Mobile Subscriber Identity)
• The keyboard cache (which contains words typed, used for auto-complete)
• Information about photos taken with the phone, such as date, time, and location

Okay, first a reality check: any application on an computer (Mac, Windows or Linux) has access to similar information (not phone numbers, of course, if the device is not a phone). The real problem here is not the access to information – because access to, say, your Address Book or iCal events, on Mac OS X, is a feature, not a bug – but whether than information can surreptitiously be obtained from your device and communicated to a third-party. We’re not saying this isn’t an issue; it’s just part of what happens when you install applications. You can never know exactly what those applications are doing.

Seriot has some valid points, but then he gets lost in speculation that is, well, a bit wild. For example, say someone creates an app to follow Hollywood gossip on the iPhone.

While giving clues about spotting stars, it surreptitiously goes through your address book and edits the email addresses.

Knowing that film industry people are likely to download this application, the emails they send are diverted to a clandestine server, providing potentially compromising private information to a prospective blackmailer.

Blackmailer? Seriously? Anyone who wants to blackmail people will have to do better than that. Seriot does not say that e-mails can be trapped by his “spyware”.

Or how about this one?

An application for Rolls Royce owners or art collectors could report the name, the area, the phone and the geotagged photos of wealthy people. This is enough informations to rob them, especially if it can be determined that the targeted individuals are currently away from home.

Sure, “Rolls Royce owners” are going to all run out and grab an app for their iPhones. To do what? Rolls Royce-spotting?

Or what about VIPs?

It is easy to imagine how an attack could be targeted against a particular individual. For example, French Prime Minister François Fillon is very proud of his iPhone and takes it everywhere. Fillon is a native of the French region called la Sarthe, where he also has his political roots. There is a significant likelihood that he would download an iPhone application designed to provide local breaking political news. It does not take much imagination to see the potential for damage in such a scenario.

I certainly hope that government officials follow a security policy and do not install third-party apps on their devices. Or if they do, they don’t use those devices for sensitive communication.

In short, there are real risks of data harvesting on any mobile device, and the iPhone in particular. However, these same risks exist on computers. Users install plenty of applications that could be stealing data and sending it to a remote server. Since most applications connect to the Internet, if only to check for updates, users can’t know which applications may be doing this and what they may be sending. Intego VirusBarrier X6 includes spyware protection for Mac OS X, offering granular settings per application and port, so users can find out which applications “phone home”. But this type of application is not available for the iPhone, because Apple does not allow third-party apps to run in the background. Perhaps that’s what’s needed to protect iPhone users from these “rogue” apps?

Apple Issues Security Update for iPhone OS

Apple has issue a security update for its iPhone OS, for both the iPhone and iPod touch, fixing five serious bugs in the way audio files and images are handled, in recovery mode, and in WebKit (the framework used for displaying HTML content). Several of these bugs could lead to arbitrary code execution, and the recovery mode bug could allow people with physical access to a locked iPhone to access its data.

Updates for the iPhone and iPod touch are available only through iTunes. More information about this update is available here.

Possible Security Issue Involving .DS_Store Files on Web Servers

Intego’s researchers have discovered an interesting issue related to .DS_Store files and web servers that, in some cases, may lead to security issues. .DS_Store (Desktop Services Store) files are invisible files created by Mac OS X that contain preferences for the display of individual folders on a Mac. They tell the Finder how to display icons (their size and position), whether there is a background color in a folder window, and other information. The Finder creates a .DS_Store for every folder that is opened on a Mac, including remote folders or folders on removable media.

.DS_Store files can also contain data about other files in their folders. For example, a .DS_Store file may contain the names of files that are in its folder, and reading a .DS_Store file can therefore give information about the contents of a folder.

This isn’t a problem on a Mac, but it could be a problem on a web server. Intego’s researchers have found that many .DS_Store files are actually indexed by Google, and that by downloading them, and reading their contents, it can be possible to get a listing of some or all of the files contained in a web directory.

(This was a known issue on Mac OS X, and it no longer affects Apache running on Mac OS X or Mac OS X Server; Apple set up rules in a 2004 security update that prevent access to .DS_Store files on these operating systems.)

But how do .DS_Store files get on a web server? This can happen in several ways:

• A user copies an entire folder of files to a web server via FTP. In this case, the .DS_Store file contained in that folder (or multiple .DS_Store files contained in sub-folders) gets copied to the web server. (Note that some FTP clients do not copy .DS_Store files by default.)
• A user copies the entire contents of a folder via FTP to a web server by selecting all the files in a folder. In normal usage, the .DS_Store file will not be copied, but, if invisible files are displayed in the user’s FTP client, and the user simply selects all files in the folder and copies them to the web server directory, the .DS_Store file – and any other invisible file – will be copied to the server.
• A user mounts a network share in the Finder, and copies files to it. The simple act of mounting the share and displaying a folder in the Finder creates the .DS_Store file.

Here’s why .DS_Store files can be a security issue. In a test we did, we put two files in a folder: My Secret Files.dmg and My Top Secret Product picture.png. We copied that folder to a web server, and loaded the .DS_Store file in Safari. Here’s what we see:

Anyone who stumbles on that .DS_Store file can therefore see some or all of the contents of the folder, even if the items in that folder are not directly linked to a web page. In the above example, anyone could then copy the .dmg and .png files easily, by simply loading the URLs of the files.

In some cases, .DS_Store files are indexed by Google, and searching for the right text strings will turn up thousands of them. But in other cases, enterprising hackers who suspect that Mac users may have copied files to web servers may spend their time trying out different web directories with /.DS_Store to see what turns up. (Obviously, they could automate this with a script, and effectively spider entire web sites in a few seconds.) While this certainly doesn’t allow a hacker to break into a web site, it may allow them to find files that are not meant for public consumption.

Some people use web servers for exchanging files: they’ll give a URL to a colleague or partner to allow them to access specific material. If the web directories are not password-protected, and they contain .DS_Store files, they could be exposing potentially sensitive information to possible discovery. While not a critical issue, this should make web site managers rethink how they use their web sites. At a minimum, it is a good idea to ensure that .DS_Store files are not copied. But to be safe, any folders used to exchange important files should be password-protected.

One more point: this weakness also affects Macs in shared environments. If a network has a shared folder which contains sub-folders with permissions for specific users, any user who can access the main folder will be able to access the .DS_Store file, and will see what folders are there (which they might not be able to see otherwise). This can have a number of consequences, since it is possible to see information that should otherwise not be visible.

How Secure is the iPad?

As the dust settles on the many reports that have focused on Apple’s iPad since its announcement on Wednesday, people are starting to think about the future of the device and how people are going to use it. One issue that comes to mind, for us at least, is the question of iPad security. Is the iPad secure? What are the security risks for the device?

On the surface, the iPad is pretty much the same as the iPod touch or iPhone (without the built-in ability to make phone calls). It uses the same OS, and benefits from the same security features that the iPhone OS contains. One such feature is sandboxing, which Apple explains as follows:

In iPhone OS, each application is put in a sandbox that restricts the application to using only its own files and preferences, and limits the system resources to which the application has access. For example, an application can call the public networking APIs to communicate over a network, but has no direct access to the communications or networking hardware.

The main issue for iPad security remains that of jailbreaking, or hacking the device to allow the user to install software not sold through the Apple Store. We saw, last year, a number of malware attacks on jailbroken iPhones (such as this, this, and this.) If users jailbreak the iPad, it will be just as susceptible to such attacks, though the wifi version will be less at risk because its range will be more limited.

For now, though, the iPad seems as secure as the iPhone, but we’ll know more when the device is released.

The Year in Mac Security 2009

2009 was another busy year for Mac security and malware, with new threats targeting Macs, iPhones being attacked, and a large number of Mac OS X vulnerabilities. We’ve prepared a PDF document with our annual report of all things related to Mac security. Download a copy to get an overview of what’s happened in the world of Mac security over the past 12 months. From Mac Trojan horses to iPhone malware, 2009 was a very busy year.