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.
Thursday, December 16, 2010
Friday, December 10, 2010
New Quicktime security update
Apple release version 7.6.9 with a number of security fixes for Windows and Mac OS 10.5.8 or earlier. No solution is available for Mac OS 10.6 yet.
Secbrowsing was just updated to point to version 7.6.9 for Windows users.
Secbrowsing was just updated to point to version 7.6.9 for Windows users.
Saturday, December 4, 2010
Chrome's Flash sandbox
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.
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:
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:
Subscribe to:
Posts (Atom)