Security
Web tracking and "Do Not Track"
Web site visits are increasingly being tracked by advertisers and others ostensibly to better target advertising. But recording which sites we visit as we click our way around the web is not only an invasion of privacy, but one that has multiple avenues for abuse. Both Mozilla and Google have recently announced browser features that could reduce or eliminate tracking—at least for advertisers that comply.
Using a wide variety of techniques: browser or Flash cookies, web "bugs", JavaScript trickery, browser fingerprinting, and so forth, advertising and tracking companies are getting a detailed look at the web sites we visit. Most web advertising also provides a means to track web site visitors on a wide variety of sites, not just the single site where that particular ad appears. It is somewhere between difficult and impossible for users to stop this behavior, if they even know it is taking place. The information is then stored by these third-parties for their use—or to sell to others
What privacy advocates would like is a way for users to opt-out of tracking. It would be better still if users had to opt-in to tracking, but an initiative like that is vanishingly unlikely because of opposition from advertising/tracking companies. A subset of advertising companies have come together in a group called the Network Advertising Initiative (NAI), which provides an opt-out service to disable tracking by member companies. That web page gives an eye-opening list of advertisers and the status of their cookies in your browser. On can then choose which to opt-out from (with a helpful "Select All" button if one is willing to turn on JavaScript for that site).
There are a number of problems with the NAI approach, as outlined in a recent Electronic Frontier Foundation (EFF) blog posting. The biggest problem from a privacy perspective is that some members interpret opting out differently than others:
Another problem is that the opt-out choice is recorded in a cookie for each different advertising or tracking company, so one must visit that page frequently as additional companies join the NAI. Privacy conscious users will also periodically delete their cookies, which also necessitates revisiting that page. Overall, it is a fairly fragile solution.
Google's idea is to provide a Chrome extension ("Keep My Opt-Outs") that blocks the deletion of the opt-out cookies (both browser and Flash cookies) so that users can still delete the rest of their cookies without having to re-up at the NAI web site. It is fundamentally just a list of cookies that shouldn't be deleted, and that list will need to be updated periodically, presumably through the extension update mechanism. It is similar to the Beef TACO (Targeted Advertising Cookie Opt-Out) Firefox extension, though TACO handles more than just the NAI-listed companies' cookies.
Keep My Opt-Outs and TACO are useful today, though they can't address the problem of differing interpretations of the opt-out. Mozilla has gone a step further and implemented a more sweeping change with its "Do Not Track" HTTP header. Do Not Track is going to require buy-in from other browsers and the tracking companies before it can even work, but it "solves" the problem in a much simpler way.
The basic idea is straightforward: a user can indicate that they do not wish to be tracked and Firefox will send a Do Not Track HTTP header with every request. That header could be interpreted by the tracking companies as the equivalent of their opt-out cookies. It would be even better if they interpreted it to mean what it clearly says and would turn off all tracking, rather than just turning off targeted (i.e. behavioral) advertising. The latter will undoubtedly take some major convincing—or regulatory pressure.
Using an HTTP header for this purpose is a far superior technical solution in that users (or their browsers) don't have to keep track of lists of advertisers and their cookies, while clearly indicating to the web sites that the user has requested that tracking be disabled. No new cookies need to be installed or preserved and violators will be fairly easily spotted. While the EFF has made it clear that it is backing the Do Not Track header approach, there are still several groups that will need to be convinced: advertising networks, tracking companies, and browser makers (some of which run their own ad networks: Google and Apple).
Though there are already Firefox extensions that implement the X-Do-Not-Track header (and the related X-Behavioral-Ad-Opt-Out header), like Universal Behavioral Advertising Opt-out and NoScript, but, for now at least, they are just "feel good" extensions. It remains to be seen if the NAI and other advertisers/trackers start to handle these headers. One might guess they would be resistant—probably will be—but there's no real reason to believe that users would opt-out in droves. There are also reasonable arguments that Do Not Track will have a minimal impact on online advertising.
Of course, even if there were, miraculously, full adoption by advertisers or, rather less miraculously, regulations from the US Federal Trade Commission (FTC) and other, similar, agencies that require advertisers to adopt it, there will still be some amount of tracking. Whether those violators are outside of the FTC's jurisdiction or just flying below the radar, clickstream information has value and there will always be those trying to extract that value. Unfortunately, there doesn't seem to be any possible technical—or regulatory—solution to that particular problem.
Brief items
Security quotes of the week
EFF: Don't Sacrifice Security on Mobile Devices
The Electronic Frontier Foundation has sent out a release on mobile device security, noting that open devices can be made more secure even if the original vendor is not interested. "By contrast, mobile systems lag far behind the established industry standard for open disclosure about problems and regular patch distribution. For example, Google has never made an announcement to its android-security-announce mailing list, although of course they have released many patches to resolve many security problems, just like any OS vendor. But Android open source releases are made only occasionally and contain security fixes unmarked, in among many other fixes and enhancements."
New vulnerabilities
awstats: arbitrary code injection
Package(s): | awstats | CVE #(s): | CVE-2010-4369 | ||||||||
Created: | January 24, 2011 | Updated: | February 21, 2011 | ||||||||
Description: | From the Ubuntu advisory:
It was discovered that AWStats did not correctly filter the LoadPlugin configuration option. A local attacker on a shared system could use this to inject arbitrary code into AWStats. | ||||||||||
Alerts: |
|
dpkg: symlink attack
Package(s): | dpkg | CVE #(s): | CVE-2011-0402 | ||||||||
Created: | January 24, 2011 | Updated: | January 26, 2011 | ||||||||
Description: | From the CVE entry:
dpkg-source in dpkg before 1.14.31 and 1.15.x allows user-assisted remote attackers to modify arbitrary files via a symlink attack on unspecified files in the .pc directory. | ||||||||||
Alerts: |
|
fuse: denial of service
Package(s): | fuse | CVE #(s): | CVE-2010-3879 | ||||||||||||||||||||||||||||||||||||||||
Created: | January 20, 2011 | Updated: | April 29, 2013 | ||||||||||||||||||||||||||||||||||||||||
Description: | From the Ubuntu advisory: It was discovered that FUSE could be tricked into incorrectly updating the mtab file when mounting filesystems. A local attacker, with access to use FUSE, could unmount arbitrary locations, leading to a denial of service. | ||||||||||||||||||||||||||||||||||||||||||
Alerts: |
|
libuser: default user password
Package(s): | libuser | CVE #(s): | CVE-2011-0002 | ||||||||||||||||||||||||
Created: | January 20, 2011 | Updated: | April 21, 2011 | ||||||||||||||||||||||||
Description: | From the Red Hat advisory: It was discovered that libuser did not set the password entry correctly when creating LDAP (Lightweight Directory Access Protocol) users. If an administrator did not assign a password to an LDAP based user account, either at account creation with luseradd, or with lpasswd after account creation, an attacker could use this flaw to log into that account with a default password string that should have been rejected. (CVE-2011-0002) | ||||||||||||||||||||||||||
Alerts: |
|
openoffice.org: multiple vulnerabilities
Package(s): | openoffice.org | CVE #(s): | CVE-2010-3450 CVE-2010-3451 CVE-2010-3452 CVE-2010-3453 CVE-2010-3454 CVE-2010-3689 CVE-2010-4253 CVE-2010-4643 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Created: | January 26, 2011 | Updated: | May 9, 2011 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description: | From the Debian advisory:
During an internal security audit within Red Hat, a directory traversal vulnerability has been discovered in the way OpenOffice.org 3.1.1 through 3.2.1 processes XML filter files. If a local user is tricked into opening a specially-crafted OOo XML filters package file, this problem could allow remote attackers to create or overwrite arbitrary files belonging to local user or, potentially, execute arbitrary code. (CVE-2010-3450) During his work as a consultant at Virtual Security Research (VSR), Dan Rosenberg discovered a vulnerability in OpenOffice.org's RTF parsing functionality. Opening a maliciously crafted RTF document can caus an out-of-bounds memory read into previously allocated heap memory, which may lead to the execution of arbitrary code. (CVE-2010-3451) Dan Rosenberg discovered a vulnerability in the RTF file parser which can be leveraged by attackers to achieve arbitrary code execution by convincing a victim to open a maliciously crafted RTF file. (CVE-2010-3452) As part of his work with Virtual Security Research, Dan Rosenberg discovered a vulnerability in the WW8ListManager::WW8ListManager() function of OpenOffice.org that allows a maliciously crafted file to cause the execution of arbitrary code. (CVE-2010-3453) As part of his work with Virtual Security Research, Dan Rosenberg discovered a vulnerability in the WW8DopTypography::ReadFromMem() function in OpenOffice.org that may be exploited by a maliciously crafted file which allowins an attacker to control program flow and potentially execute arbitrary code. (CVE-2010-3454) Dmitri Gribenko discovered that the soffice script does not treat an empty LD_LIBRARY_PATH variable like an unset one, may lead to the execution of arbitrary code. (CVE-2010-3689) A heap based buffer overflow has been discovered with unknown impact. (CVE-2010-4253) A vulnerability has been discovered in the way OpenOffice.org handles TGA graphics which can be tricked by a specially crafted TGA file that could cause the program to crash due to a heap-based buffer overflow with unknown impact. (CVE-2010-4643) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Alerts: |
|
perl-Convert-UUlib: buffer overflow
Package(s): | perl-Convert-UUlib | CVE #(s): | |||||||||
Created: | January 20, 2011 | Updated: | January 26, 2011 | ||||||||
Description: | From the Fedora advisory: Fix a one-byte-past-end-write buffer overflow in UURepairData (reported, analysed and testcase provided by Marco Walther) | ||||||||||
Alerts: |
|
request-tracker: unsalted password hashing
Package(s): | request-tracker3.6 | CVE #(s): | CVE-2011-0009 | ||||
Created: | January 24, 2011 | Updated: | May 25, 2012 | ||||
Description: | From the Debian advisory:
It was discovered that Request Tracker, an issue tracking system, stored passwords in its database by using an insufficiently strong hashing method. If an attacker would have access to the password database, he could decode the passwords stored in it. | ||||||
Alerts: |
|
tomcat: cross-site scripting
Package(s): | tomcat6 | CVE #(s): | CVE-2010-4172 | ||||||||||||||||||||||||
Created: | January 24, 2011 | Updated: | May 19, 2011 | ||||||||||||||||||||||||
Description: | From the Ubuntu advisory:
It was discovered that Tomcat did not properly escape certain parameters in the Manager application which could result in browsers becoming vulnerable to cross-site scripting attacks when processing the output. With cross-site scripting vulnerabilities, if a user were tricked into viewing server output during a crafted server request, a remote attacker could exploit this to modify the contents, or steal confidential data (such as passwords), within the same domain. | ||||||||||||||||||||||||||
Alerts: |
|
wordpress: cross-site scripting
Package(s): | wordpress | CVE #(s): | CVE-2010-4536 | ||||||||
Created: | January 20, 2011 | Updated: | January 26, 2011 | ||||||||
Description: | From the Red Hat bugzilla entry: A Cross-site scripting(XSS) flaw was found in KSES, which is the wordpress HTML sanitation library. | ||||||||||
Alerts: |
|
wordpress-mu: multiple cross-site scripting vulnerabilities
Package(s): | wordpress-mu | CVE #(s): | CVE-2010-4536 | ||||||||
Created: | January 24, 2011 | Updated: | January 26, 2011 | ||||||||
Description: | From the CVE entry:
Multiple cross-site scripting (XSS) vulnerabilities in KSES, as used in WordPress before 3.0.4, allow remote attackers to inject arbitrary web script or HTML via vectors related to (1) the & (ampersand) character, (2) the case of an attribute name, (3) a padded entity, and (4) an entity that is not in normalized form. | ||||||||||
Alerts: |
|
Page editor: Jake Edge
Next page:
Kernel development>>