Security

CVE woes lead some to seek alternatives

A recent discussion of problems with the Common Vulnerabilities and Exposures (CVE) system for security vulnerabilities—coupled with some efforts to supplement or supplant it—has led some to wonder about its future. The problems stem from the difficulty—sometimes impossibility—of getting CVEs assigned for real vulnerabilities. That, in turn, has led some to stop even requesting CVE numbers for vulnerabilities that they find, which further reduces their usefulness.

The system of assigning CVE IDs has been around since 1999—run by the MITRE Corporation. It was set up to provide a way for researchers, users, and others to track specific vulnerabilities, but has been seen as declining in quality over the years. For example, there are many CVE entries that have been assigned but simply show "RESERVED" with no details, which makes those entries less than entirely helpful.

The IDs do provide a way to refer to specific vulnerabilities, but that only works if the CVEs get assigned properly. As Kurt Seifried, who is part of the Red Hat security response team, put it on the oss-security mailing list, there is reason to worry about that:

Beyond that, though, he has heard "about people that may have given up asking for CVEs and publicizing their work at all". He also pointed to a message from Hanno Böck showing his inability to get a CVE assigned for a flaw in the implementation of a cipher used in TLS 1.2. The request was denied because it was "outside the scope of CVE's published priorities". Seifried concluded his message by noting that this new CVE policy that was cited in the message to Böck has two levels of coverage for the priority of CVE assignments, which is something he called "tiered coverage". That policy may lead in undesirable directions, he said:

Others who posted in the thread largely agreed with Seifried's concerns. Others echoed Böck's experience and noted that they had given up even trying to get CVEs for the vulnerabilities that they find. The process to request a CVE ID is in place, but it isn't smoothly functioning these days. Adam Caudill summarized some of the problems:

Caudill (and others) called for a new system of some sort. A participant known as "Tim" posted some detailed thoughts on what a new system might look like. As it turns out, though, Alexander Peslyak (better known as "Solar Designer") had created a bare-bones system to assign OVE IDs (OVE presumably stands for "Openwall Vulnerability Entries"). This assignment mechanism does no verification and simply assigns an ID; it is meant to be a friction-free mechanism to get an ID without needing vetting of any kind.

While the benefit of being able to get IDs quickly and easily was of interest, several in the thread were looking for more. Features such as allowing entries to be updated with more information or be curated in some fashion were mentioned. Solar Designer said that he didn't want to add more features, but encouraged others to pursue that path. As part of that discussion, Tim noted a major problem that he has seen: link rot for advisories and other detailed information. As he put it:

That led "halfdog" to propose a blockchain-based database to contain the vulnerability information, with "proof of work" providing a means to allocate the IDs. In the proposal for a "Distributed Cryptoenhanced Vulnerability Enumeration" (DCVE), there are provisions for storing some information with each entry, though it would not seem to completely eliminate the problem that Tim described.

There was also a pointer in the thread to the Open Vulnerability ID (OVI) system, which is another ID-assigning mechanism.

It's not clear how much traction any of those systems mentioned would actually get, at least partly because they are entirely separate from the CVE ID namespace. Another project, which was announced by Seifried on the list, is the Distributed Weakness Filing (DWF) system. It directly incorporates CVE IDs into its database, so that DWF-2016-NNNN is the same as CVE-2016-NNNN. Other vulnerabilities that did not have CVEs could use numbers outside of the CVE numeric range (which is now arbitrarily long, but has never gone beyond four digits—yet). The DWF project, Seifried noted, is not part of his Red Hat duties; it is a side project that he and others are working on.

DWF provides a number of different ways to get an ID, starting with just trying to get a CVE number as usual, through requesting one from a DWF Number Authority (DNA), to changing the project's database file and making a pull request on GitHub—or by simply emailing the project. As he said in the announcement: "I want to reduce the time and effort needed to get identifiers, something best achieved by pushing assigning out to as close to the vulnerability discover/handling as possible".

So far, there has been little public reaction to the DWF announcement, but it certainly seems to be the furthest along in terms a new system. It complements the existing CVE system, while also setting up something that could replace it someday if the CVE system continues down its current path.

It seems clear that the CVE system is breaking down in various ways. The tiered coverage approach that MITRE has chosen does not look likely to help it back onto a path where it will be the definitive resource for vulnerability IDs. It's also unclear whether any of the proposed alternatives will truly take off, but the free-software community would seem to be a likely candidate to start heading toward some alternative. If independent security researchers make the same choice, we could be seeing the beginning of the end for CVEs—though it is hard to imagine that system fading away completely.

Comments (6 posted)

New vectors for fingerprinting Tor Browser

Browser fingerprinting enables a web site to differentiate between anonymous visitors, capturing enough minor differences between visiting browsers to uniquely associate each browser with a specific profile. The technique lets sites track individual users across multiple visits and IP addresses, which is problematic enough for any user who is concerned about privacy. But fingerprinting that can identify users coming through the Tor anonymizing network is even more worrisome. Recently, research uncovered several new fingerprinting vectors that work against Tor Browser—and, by extension, most other web browsers. How significant the vectors are in practical terms, however, remains to be seen.

Jose Carlos Norte posted his findings at his blog on March 6. In the post, Norte describes five experiments he has run attempting to collect entropy (in the information-theory sense) data about visiting web browsers, which helps uniquely identify users. The tests were conducted with Tor Browser on multiple machines, although under controlled conditions.

Prints

All of the tests involve JavaScript (which is enabled by default in Tor Browser). The first test captures the deltas sent by the mouse wheel's scroll events: a physical wheel will send a "3" for every delta, while a trackpad will send a variable stream of deltas that depends on the characteristics of the trackpad and the user's action.

The second test is related; it captures the scroll speed of the mouse, which Norte notes is linked to both the operating system's settings and the capabilities of the hardware. The third test is the speed of the mouse's movement which, as with the scroll speed, depends at least in part on OS and hardware factors.

The fourth test is a CPU benchmark. A CPU-intensive script is run in a Web Worker and the execution time recorded as the result. Norte pointed out in the post that Tor Browser already implements an anti-fingerprinting countermeasure by limiting the clock resolution of JavaScript's Date.getTime() function to 100ms. He was able to bypass this limitation by incrementing a counter once every millisecond with WindowTimers.setInterval(), though, and speculated that there are other ways to work around the clock-resolution problem.

The fifth test is akin to the canvas fingerprinting techniques already explored in existing research. To recap, canvas fingerprinting involves drawing a known shape into an HTML5 <canvas> element, then hashing the pixels of the resulting image. A number of factors result in small differences in how the shape is rendered, meaning considerable entropy can be collected about the specific machine in use.

Norte's test also exploits differences in the on-screen contents rendered by the browser, but it does not require any special element to be drawn onto the screen. Rather, the script queries the Element.getClientRects() function, which returns the precise pixel positions of each CSS border box for a given page element. That function can be called on any page element; Norte's tests call it on a text block, the size and position of which vary with window size, font configuration, and other factors.

Impact

The blog post links to a test page that users can access to see what data their browsers generate. Norte himself reports data only for two machines, which is far from enough to be meaningful. In particular, it is easy to see for oneself that the mouse-speed, scroll-speed, and CPU-benchmark numbers can vary considerably on a single machine between two test runs.

It might be possible to collect multiple samples across time and compute an average, but the value of doing so is likely to be small. Too many external factors can affect the CPU benchmark, and a fingerprinting technique needs to be reproducible to track users. The scrolling behavior recorded is, at the fundamental level, a measurement of user activity, not of the browser.

On the other hand, there is certainly some entropy to be found in determining whether the visiting machine uses a trackpad or a mouse with a physical scroll wheel. By far the most interesting test, though, is the getClientRects() fingerprint. Tor Browser now takes steps to alert the user whenever a script tries to read data from a <canvas> element, specifically so that users can block canvas-fingerprinting attempts.

It is hard to say how big the entropy contribution of either test is in the wild. The entropy numbers published by projects like the Electronic Frontier Foundation (EFF)'s Panopticlick count on millions of users contributing to the test data; the proportion of users that produce the same result on a particular measurement is what determines the entropy reported in Panopticlick's results. So a scroll-wheel delta of "3" (corresponding to any mouse with a physical wheel) does not contribute much, while the deltas sent by a truly strange trackpad would contribute noticeably more.

Various fingerprinting measurements can also overlap with each other, which reduces the entropy contributed by each metric. For instance, there was a bug opened against Tor Browser in 2015 that speculated on several additional JavaScript-based techniques to detect information about the attached pointing device—which may already be in use by real-world browser fingerprinters. It is not clear that Norte's techniques contribute additional information not already detectable through these other means. For its part, Panopticlick does not yet record pointer-related information about browsers except for whether or not the browser has touchscreen support. The techniques used to detect touchscreen support (such as the MouseEvent.mozInputSource property) may also overlap with Norte's tests for many devices.

Norte posted about his findings on the Tor Browser bug-discussion list. The limitations of the Date.getTime() countermeasure were already a known issue, it seems, but a new bug was opened to discuss the getClientRects() issue. Tor's George Kadianakis noted in the bug report that Tor Browser already takes some steps to sanitize the JavaScript functions used in Norte's test; the packages now bundle in a set of default fonts (so variations in system fonts should not impact how an element is rendered) and the browser rounds off the dimensions it reports for window sizes to the nearest 200 pixels.

Naturally, finding and circumventing fingerprinting vectors in Tor Browser is an ongoing process. The project will, no doubt, implement fixes for the open issues as soon as it is able. If further investigation indicates that the getClientRects() vector is indeed a significant entropy source, that could require more subtle adjustments, since getClientRects() has legitimate uses.

For those users running other browsers, however, Norte's findings are simply more bullet points in the already lengthy list of ways that a web site can track people across sessions. Purists will point out that these fingerprinting vectors, like so many others, require JavaScript to be enabled. But, as an increasing percentage of web sites rely on JavaScript for even basic functionality, Tor Browser's approach—which tries to balance practical function with a measure of anonymity—looks more and more like the only way to avoid being fingerprinted.

Comments (4 posted)

Security quotes of the week

Comments (33 posted)

botan: two vulnerabilities

Comments (none posted)

chromium: multiple vulnerabilities

Comments (none posted)

exiv2: denial of service

Comments (none posted)

ffmpeg: denial of service

Comments (none posted)

gimp: command execution

Comments (none posted)

jasper: multiple vulnerabilities

Comments (none posted)

kernel: multiple vulnerabilities

Comments (none posted)

kernel: denial of service

Comments (none posted)

mozilla: multiple vulnerabilities

Comments (none posted)

mozilla: multiple vulnerabilities

Comments (none posted)

nss: code execution

Comments (none posted)

openstack-nova: information exposure

Comments (none posted)

pcs: two vulnerabilities

Comments (none posted)

phpmyadmin: cross-site scripting

Comments (none posted)

roundup: information leak

Comments (none posted)

samba: two vulnerabilities

Comments (none posted)

squid: denial of service

Comments (none posted)

tomcat: session hijacking

Comments (none posted)

wireshark: multiple dissector crashes

Comments (none posted)

xen: denial of service

Comments (none posted)