As of yesterday, SecBrowsing was updated to point to version 12.0.1.633 of the RealPlayer plug-in for Windows, which is the latest version released by Real and addresses a security issue in Windows.
As of yesterday, SecBrowsing was updated to point to version 12.0.1.609 of the RealPlayer plug-in, which is the latest version released by Real and addresses security issues in many platforms.
I've verified this is the version reported by Real Player on Windows XP and Vista. If you happen to have RealPlayer Enterprise or Mac RealPlayer or Linux RealPlayer, and you are at the latest version, please let me know what version SecBrowsing detects for you, if any.
On Dec 1, 2010, Google developers Justin Schuh and Carlos Pizano announced the release of the first iteration of the security sandbox for the Adobe Flash plugin in Google Chrome (for Windows). It's currently on the dev-channel of Chrome, which is an unstable build targeted at users who like to browse on the edge.
How the security sandbox works
One of the basic concepts that the operating system provides is that of a process. A process has its own piece of memory, and is a concept quite familiar even to end users. On Windows, hitting Ctrl-Alt-Delete lists (some of) the running processes of the system at any time, and lets you "kill" a process that you think is misbehaving. Bugs and crashes in one process do not (usually) affect other processes.
Chrome uses multiple process: One for the browser (networking, cache, cookies, bookmarks, sync, among others), one per website renderer (HTML, JS, CSS parsing, javascript execution, actual rendering of the page in the screen), and one per plug-in such as Java and Flash.
Multiple processes in Chrome. 1 for the browser, 1 for Flash, and 1 per tab.
The immediate impact is that a crash or a slowdown in the renderer does not slow down the other renderers, or the main browser. In addition, one can use this to enhance a browser's security by asking the operating systems to restrict a process' access to the machine's resources.
For example, the tab renderer processes are not allowed to read or write to the disk or network of the computer. They may only talk to the browser process to request resources (images, html etc).
Traditionally, browser plugins were not restricted to what they can access on a computer. In fact, the reason plugins were adopted is because they provide access to resources the browser does not typically provide, such as video rendering or access to the webcam or raw network access. So, most plugins need to access the filesystem and the network, which makes them a security concern. Many plugins come with many security vulnerabilities, and taking over a plugin that has unrestricted access to the disk and network means one can easily force it to download and store malware on the machine.
This is exactly what the plugin sandbox tries to stop. I'm looking forward to the release of the Flash sandbox in the stable version, in all operating systems, and in other browsers such as Firefox.
Update: Google released a nice video that explains the sandbox as well as the importance of updating the plugins:
If your Flash version in Chrome is out-of-date, one of a few things could be happening:
You have not restarted Chrome in a while. If you just restart, you should get the latest version.
You are on the beta or the developer channel. If you don't know what this is, you are probably not on them. If you are, please wait a few days. Chrome will ask you to update itself. Sometimes Flash for dev channel is released a few days later than stable.
You are not using the bundled Flash plugin that ships with Chrome. Type "about:plugins" and then "Details" on the top-right. Find the Flash files you use, and enable the bundled Flash, which is typically the most up-to-date.
If you also use Flash in Firefox or Safari, use one of these browsers and get the latest version at http://get.adobe.com/flashplayer/.
A new version of Shockwave for Director was released today, with critical security fixes. SecBrowsing was just updated to point to the latest secure version, 11.5.9.615.
SecBrowsing was just updated to point to Adobe Reader 9.4.0, which was released a couple of days ago, and is available at http://get.adobe.com/reader/.
Many security vulnerabilities were fixed. The advisory from Adobe is available here: http://goo.gl/RCiD.
On Sep 20, 2010, Adobe released Flash Player version 10.1.85, with critical security fixes for all platforms.
SecBrowsing has been warning users since. Note that Chrome auto-updates the bundled Flash plugin automatically, all you have to do is restart it.
The release notes are here: http://support.apple.com/kb/HT4339. This release fixes a couple of vulnerabilities (CVE-2010-1818 and CVE-2010-1819), at least one of which was seen being exploited for a few days.
Is there any way to protect yourself against this without blocking Flash, until you get the update (due Sept 27)? I would try the --safe-plugins option, which runs all your plugins in a sandbox. It could break some features, like Flash might not be able to access your webcam or microphone anymore. If I get the chance I'll try this out and let you know if anything breaks.
Note that as of today, Sept 13, virtually all web users are vulnerable to zero-day exploits for 3 different browser plugins, for which no fix is available:
It seems that the latest developer version of Chrome (7.0.517.0) adds an option to auto-run plugins that are sandboxed, and prompt for the others.
It can be enabled by The Tools menu, then "Preferences", "Under the hood", "Content settings". In "Plug-ins", you can select "Allow only sandboxed plug-ins"
Then, embedded objects that require a plug-in to run will be replaced with a button. There's also an infobar that lets you enable the plug-in for the whole page.
Quicktime's latest version (7.6.7) is currently being exploited by a known bug. All IE users on Windows are affected. The majority of the readers of this blog are Chrome users (since most of you come here via the Chrome extension), but, for completeness, I thought I'd write about this. There's no fix yet, so the only way to keep yourself safe is to disable the Quicktime plug-in from IE.
[safe] Use alternative PDF viewers. Preview on Mac, or for Windows, Brian Krebs suggests FoxIt, Sumatra or Nitro PDF. On Linux, I've used evince and kpdf in the past. There's also xpdf. All of these are usually less targeted.
[risky] Download it in your desktop, and open it in Adobe Reader. This is still dangerous, but at least random hacked pages won't auto-load invisible PDFs. If you do this, at least disable Javascript from Adobe Reader.
SecBrowsing allows users to report their plugins, by clicking on the "Send to server" button. We use the data to see if we are missing any important plugins with known security vulnerabilities. In this post, I've aggregated the reports for 1 month, producing some hopefully interesting statistics.
How many plugins are there?
Over 600 plugins (including different versions of the same plugin) were reported by over 3000 users , in the month of Aug 2010. That by itself was interesting to me.
How many plugins does a user have?
50% of the users reported over 20 plugins. (This is the median. The average is 21 plugins.)
25% of the users reported over 26 plugins.
5% of the users reported over 30 plugins.
One user reported 52 plugins!
Note that some plugins are reported multiple times: Java is reported twice, Realplayer 2-3 times, and Quicktime on Windows is reported 7 times. So the number of unique plugins is probably around 10 on average.
The most popular plugins
38 plugins were reported by over 10% of the 3000 users.
They are listed here - after dropping some plug-ins that come bundled with Chrome.
98% Shockwave Flash
83% Silverlight Plug-In
78% Adobe Acrobat
66% QuickTime Plug-in
61% Microsoft® DRM
45% iTunes Application Detector
44% Windows Presentation Foundation
42% Google Earth Plugin
39% Picasa
38% Java(TM) Platform SE 6 U21
36% Microsoft® Windows Media Player Firefox Plugin
.png)
