Security
Private browsing: not so private?
A team of researchers led by Dan Boneh at Stanford University undertook a study of the "private browsing" feature offered by most web browsers, and found numerous exploitable holes in the wall of protection the features are supposed to maintain. The results, presented at the USENIX Security conference in August, spawned a variety of reactions from browser makers, from defensive posturing to bug reports. In the meantime, the paper provides a practical method to increase private browsing's privacy through a new Firefox extension.
The study examined the private browsing features offered by the four most popular browsers: Internet Explorer, Firefox, Chrome, and Safari with regard to two distinct privacy models. The first is termed the "local attacker," although it need not be a hostile party; browser makers advertise private browsing features as a way to keep family members from learning about birthday present shopping and secret vacation plans. A private browsing failure with regard to the local attacker would allow the attacker to learn what happened during a private session after the session had been terminated — specifically by finding information written to disk somewhere by the browser, as opposed to retrieving proxy caches or other network attacks.
The second model is the "web attacker," namely a hostile site. A web attack flaw would allow the attacker to either discover that a visitor in a private browsing session was the same as a visitor in a previous non-private session, or vice versa. In either case, the attack would be limited to the browser exposing information during the browsing session, not simply by recording the IP address of the visitor or by having the user choose to do something that identifies himself or herself (e.g. log in).
In looking at the ways that a browser can "leak" information during a private browsing session, the team classified all of the possible state changes into four categories. The first category, those changes initiated by the site without user intervention (such as saving cookies, browsing history, and caching data) were actively guarded against by all four browsers. It was in the other three categories that the browsers disagreed, and were internally inconsistent. Those include changes initiated by the site but requiring user action (such as saving a password or generating an SSL client certificate), changes initiated by the user (such as adding a bookmark or downloading a file), and changes that are not user-specific (such as installing an update, or refreshing a block-list).
The leaks
The team performed tests tracking disk writes during private browsing sessions. It also performed an audit of the Firefox source code, and found several leaks, where data generated during a private browsing session was later accessible from a public browsing session. Some problems were the same across all browsers, such as the ability to add bookmarks during a private browsing session, and automatic recording of file downloads (which persist even if the files themselves are removed). None have a separate "private bookmarks" feature; all allow you to add global bookmarks during a private session. Some browsers allow you to manually delete individual entries from the Downloads window's log — if you remember to do so.
Others were limited to some browsers and not others. Internet Explorer, for example, can be tricked into using SMB queries to request page content simply by using the SMB \\servername\resource.ext naming convention, which bypasses IE's private browsing altogether and sends Windows hostname and username information to the server via SMB protocol messages. IE, Safari, and Chrome all permanently save user-approved self-signed SSL certificates encountered during private browsing as well.
Firefox was not immune to private browsing leaks. The team singled out Firefox's "custom protocol handler" function, which a site can use to register a custom protocol with the browser and trigger a desired action — think git:// and torrent:// links, for example. Those protocol handlers live in the document object model (DOM) of the browser and could be detected by a remote site, which could leak information between public and private sessions.
During the in-depth look at Firefox, the team found five different files in a user's profile that were written to during private browsing, including security certificate settings (the cert8.db file), site-specific permissions such as cookie- and pop-up-blocking (in the permissions.sqlite file), download action preferences (in the mimeTypes.rdf file), automatically-discovered search engine add-ons (in the search.sqlite and search.json files), and plugin registrations (in the pluginreg.dat file).
The add-ons
Beyond the individual problems with each browser, however, the team found add-ons to be a far more serious source of private browsing data leaks. Plugins can use their own cookie setting and reading framework unimpeded by the browser's. Extensions are worse, in most cases outright ignoring whether or not the browser is in private browsing mode.
Not all browsers support extensions, of course, but all had problems. Chrome disables all extensions by default while in its private browsing mode, though this setting can be changed on a per-extension basis. IE also defaults to disabling extensions while browsing privately, although this is a preference setting that can only be turned on or turned off across all extensions at once. Safari does not have a public, supported extension API at all, but unsupported extensions continue to run unaltered while private browsing is enabled.
Firefox's extension behavior is the most problematic, starting with the fact that extensions remain enabled when private browsing is turned on. The paper examined the top 40 most popular Firefox extensions in depth. Eight were binary extensions, which constitute a serious security threat in their own right and run with the same read/write privileges of the current user. Of the remaining 32, 16 wrote no data to disk at all when browsing, but only one — Tab Mix Plus — actually checked the privacy mode of the current session through Firefox's nsIPrivateBrowsingService API.
The study's authors indicate that they have begun a similar in-depth examination of the most popular Chrome extensions. Thus far, they have encountered several that can execute arbitrary binary code, and several more that report user information to remote Google Analytics servers, leading them to expect to uncover more privacy violations.
Recommendations
The paper concludes with a discussion of various approaches that the browsers could take to improve the privacy guarantees of private browsing sessions, with particular emphasis on extensions. The ideas include having each extension voluntarily suspend writing information during a private session, having the browser block all extensions from writing data during a private session, and having the browser revert changes made by extensions.
The authors seem to regard the first option as the easiest to implement, and built their own extension named ExtensionBlocker that implements it. ExtensionBlocker works by querying the manifest file of each active Firefox extension, and, during a private session, disabling those that do not include the suggested <privateModeCompatible/> XML tag. Thus far, ExtensionBlocker does not seem to have been released to the public.
Naturally, for ExtensionBlocker to be useful, other extension authors would have to start including the <privateModeCompatible/> tag. So far, no other extensions have adopted it. But the authors do recommend several other privacy-protecting extensions, such as Torbutton, Doppelganger, and Bugnosis. In addition, they suggest that a system similar to the W3C's platform for privacy preferences (P3P) could be used to classify sites as safe for private-mode browsing.
Reaction
Shortly after the paper was published online, ZDNet Asia solicited
feedback from various browser vendors. Opera, surprisingly, was the
harshest in its criticism, reportedly accusing the researchers of
"simply incorrect
" assumptions about the security goals of
private browsing. Opera was not included in the tests, but it did recently
introduce its own private browsing feature, which it (like the others) advertises as offering protection for gift-shoppers, shared-computer users, and "testing websites
" for "cookie and session-related aspects
" of browsing.
Google responded by saying that Chrome's private browsing mode helps you "limit
" the information saved on disk but that it makes clear that the mode "does not remove all records
".
For its part, Mozilla responded both by saying that some of the issues addressed in the paper have already been fixed in the Firefox 4 series, and that others had been filed as new bugs on which there will be new work.
All details aside, perhaps the biggest take-aways for users are that the browser makers do not agree on what "private browsing" mode actually entails, and that none of them make strong guarantees. As always, existing tools like Tor, Privoxy, and NoScript offer the dedicated user with a way to significantly improve the anonymity and security of a browsing session — albeit it at the cost of reduced functionality on certain sites.
Finally, everyone concerned about his or her browsing privacy would do well to remember that private browsing modes offer no protection against certain other types of detection. The Electronic Frontier Foundation's Panopticlick tool, for example, uses combinations of remotely-accessible, non-private data (including the list of installed plugins, fonts, OS version information, and more) to assemble what could be a unique fingerprint for each browser — regardless of what nsIPrivateBrowsingService might report.
Brief items
Security quote of the week
- Users want to click on things.
- Code wants to be wrong.
- Services want to be on.
- Security features can be used to harm.
Die-hard bug bytes Linux kernel for second time (Register)
The Register reports on CVE-2010-3301, a local root vulnerability which has now been fixed - for the second time - in the mainline kernel. "The oversight means that untrusted users with, say, limited SSH access have a trivial means to gain unfettered access to pretty much any 64-bit installation. Consider, too, that the bug has been allowed to fester in the kernel for years and was already fixed once before and we think a measured WTF is in order." It's worth noting that exploits for this vulnerability have been posted.
Felten: Understanding the HDCP Master Key Leak
Ed Felten comments on the apparent release of the HDCP master key. "Now we can understand the implications of the master key leaking. Anyone who knows the master key can do keygen, so the leak allows everyone to do keygen. And this destroys both of the security properties that HDCP is supposed to provide. HDCP encryption is no longer effective because an eavesdropper who sees the initial handshake can use keygen to determine the parties' private keys, thereby allowing the eavesdropper to determine the encryption key that protects the communication. HDCP no longer guarantees that participating devices are licensed, because a maker of unlicensed devices can use keygen to create mathematically correct public/private key pairs. In short, HDCP is now a dead letter, as far as security is concerned." One thing he doesn't mention is that this key might make it possible to create open video components based on free software.
New vulnerabilities
bzip2: code execution
| Package(s): | bzip2 | CVE #(s): | CVE-2010-0405 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | September 20, 2010 | Updated: | January 9, 2013 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
Mikolaj Izdebski has discovered an integer overflow flaw in the BZ2_decompress function in bzip2/libbz2. An attacker could use a crafted bz2 file to cause a denial of service (application crash) or potentially to execute arbitrary code. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
couchdb: cross-site request forgery
| Package(s): | couchdb | CVE #(s): | CVE-2010-2234 | ||||||||
| Created: | September 21, 2010 | Updated: | September 22, 2010 | ||||||||
| Description: | From the Red Hat bugzilla:
Apache CouchDB prior to 0.11.2 and 1.0.1 are vulnerable to cross site request forgery (CSRF) attacks. A malicious web site can POST arbitrary JavaScript code to wellknown CouchDB installation URLs and make the browser execute the injected JavaScript in the security context of CouchDB's admin interface Futon. | ||||||||||
| Alerts: |
| ||||||||||
dovecot: Maildir ACL issue
| Package(s): | dovecot | CVE #(s): | CVE-2010-3304 | ||||||||||||||||||||
| Created: | September 20, 2010 | Updated: | February 8, 2011 | ||||||||||||||||||||
| Description: | From the openSUSE advisory:
When using Maildir all ACLs on INBOX were copied to newly created mailboxes although only default ACLs should have been copied. | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
drupal: multiple vulnerabilities
| Package(s): | drupal6 | CVE #(s): | CVE-2010-3091 CVE-2010-3092 CVE-2010-3093 CVE-2010-3094 | ||||
| Created: | September 20, 2010 | Updated: | September 22, 2010 | ||||
| Description: | From the Debian advisory:
Several issues have been discovered in the OpenID module that allows malicious access to user accounts. (CVE-2010-3091) The upload module includes a potential bypass of access restrictions due to not checking letter case-sensitivity. (CVE-2010-3092) The comment module has a privilege escalation issue that allows certain users to bypass limitations. (CVE-2010-3093) Several cross-site scripting (XSS) issues have been discovered in the Action feature. (CVE-2010-3094) | ||||||
| Alerts: |
| ||||||
flash-plugin: code execution
| Package(s): | flash-plugin | CVE #(s): | CVE-2010-2884 | ||||||||||||||||||||||||||||||||
| Created: | September 21, 2010 | Updated: | January 21, 2011 | ||||||||||||||||||||||||||||||||
| Description: | From the Red Hat advisory:
This vulnerability is detailed on the Adobe security page APSB10-22, listed in the References section. If a victim loaded a page containing specially-crafted SWF content, it could cause flash-plugin to crash or, potentially, execute arbitrary code. | ||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||
fuse-encfs: multiple vulnerabilities
| Package(s): | fuse-encfs | CVE #(s): | CVE-2010-3073 CVE-2010-3074 CVE-2010-3075 | ||||||||||||||||
| Created: | September 22, 2010 | Updated: | December 8, 2010 | ||||||||||||||||
| Description: | From the Red Hat Bugzilla entry: Micha Riser reported three security flaws in EncFS encrypted filesystem:
A security analysis of EncFS has revealed multiple vulnerabilities: | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
kernel: memory leaks
| Package(s): | kernel | CVE #(s): | CVE-2010-2942 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | September 20, 2010 | Updated: | March 28, 2011 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the openSUSE advisory:
Several memory leaks in the net scheduling code were fixed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
kernel: multiple vulnerabilities
| Package(s): | kernel | CVE #(s): | CVE-2010-2954 CVE-2010-3078 CVE-2010-3080 CVE-2010-3081 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | September 17, 2010 | Updated: | April 21, 2011 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
Tavis Ormandy reported an issue in the irda subsystem which may allow local users to cause a denial of service via a NULL pointer dereference. (CVE-2010-2954) Dan Rosenberg discovered an issue in the XFS file system that allows local users to read potentially sensitive kernel memory. (CVE-2010-3078) Tavis Ormandy reported an issue in the ALSA sequencer OSS emulation layer. Local users with sufficient privileges to open /dev/sequencer (by default on Debian, this is members of the 'audio' group) can cause a denial of service via a NULL pointer dereference. (CVE-2010-3080) Ben Hawkes discovered an issue in the 32-bit compatibility code for 64-bit systems. Local users can gain elevated privileges due to insufficient checks in compat_alloc_user_space allocations. (CVE-2010-3081) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
kernel: privilege escalation
| Package(s): | linux, linux-source-2.6.15 | CVE #(s): | CVE-2010-3301 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | September 20, 2010 | Updated: | March 3, 2011 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Ubuntu advisory:
Ben Hawkes discovered that the Linux kernel did not correctly filter registers on 64bit kernels when performing 32bit system calls. On a 64bit system, a local attacker could manipulate 32bit system calls to gain root privileges. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
libtiff: code execution
| Package(s): | libtiff | CVE #(s): | CVE-2010-3087 | ||||||||||||||||||||
| Created: | September 22, 2010 | Updated: | March 15, 2011 | ||||||||||||||||||||
| Description: | From the openSUSE advisory: Specially crafted tiff files could cause a memory corruption in libtiff. Attackers could potentially exploit that to execute arbitrary code in applications that use libtiff for processing tiff files (CVE-2010-3087). | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
python-updater: code execution
| Package(s): | python-updater | CVE #(s): | |||||
| Created: | September 22, 2010 | Updated: | September 22, 2010 | ||||
| Description: | From the Gentoo advisory:
Robert Buchholz of the Gentoo Security Team reported that python-updater includes the current working directory and subdirectories in the Python module search path (sys.path) before calling "import". A local attacker could entice the root user to run "python-updater" from a directory containing a specially crafted Python module, resulting in the execution of arbitrary code with root privileges. | ||||||
| Alerts: |
| ||||||
squid: denial of service
| Package(s): | squid | CVE #(s): | CVE-2010-3072 | ||||||||||||||||||||||||||||||||
| Created: | September 22, 2010 | Updated: | May 19, 2011 | ||||||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla entry: A denial of service flaw was found in the way Squid proxy caching server internally processed NULL buffers. A remote, trusted client could use this flaw to cause squid daemon crash (dereference NULL pointer) when processing specially-crafted request. | ||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||
tomcat: information disclosure
| Package(s): | tomcat | CVE #(s): | CVE-2010-1157 | ||||||||||||
| Created: | September 22, 2010 | Updated: | February 14, 2011 | ||||||||||||
| Description: | From the Novell report: Apache Tomcat 5.5.0 through 5.5.29 and 6.0.0 through 6.0.26 might allow remote attackers to discover the server's hostname or IP address by sending a request for a resource that requires (1) BASIC or (2) DIGEST authentication, and then reading the realm field in the WWW-Authenticate header in the reply. | ||||||||||||||
| Alerts: |
| ||||||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>