LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityWebGL vulnerabilitiesA recent report that highlighted some potential and actual security vulnerabilities in WebGL has been widely circulated. It should probably not come as a surprise that a new whiz-bang feature that is meant to allow web content to interact with complex 3D graphics hardware might lead to problems. Since it is all-but-certain that browser makers will be enabling—in many cases already have enabled—this feature, it will be interesting to see how the security holes will be filled as they make their way from theoretical to actual vulnerabilities. WebGL is a low-level 3D graphics API that is based on the OpenGL ES 2.0 standard implemented by libraries for most fairly recent 3D graphics cards. For browsers with WebGL support, the HTML canvas element can be used to display accelerated graphics in the browser that can be controlled via JavaScript. For gaming, exploring 3D landscapes, undoubtedly annoying advertisements, and plenty of other uses, WebGL will be a welcome addition to web browsers. But allowing arbitrary content flowing across the internet to interact with complex hardware certainly seems like it might lead to security problems. Graphics hardware typically consists of one or more graphics processing units (GPUs) that are accessed through a driver. The driver provides some standardized interface to higher-level libraries that implement a graphics standard like OpenGL. But, in order to provide the most flexibility for graphics programmers, much of what gets handed off to the libraries are special-purpose programs called shaders. Shaders are written to handle the complexities of the graphics to be rendered, and the libraries and drivers turn those programs into the proper form for the GPU(s) in the hardware. Essentially it means that malicious web sites can craft semi-arbitrary programs to run on the hardware of the user. That alone should be enough to give one pause from a security perspective. One obvious outcome is that malicious shaders could be written to essentially monopolize the graphics hardware, to the detriment of anything else that's trying to write to the display (e.g. other windows). In the worst case, it could lead to the user having to reinitialize the graphics hardware—possibly requiring a reboot. That kind of denial of service could be extremely annoying to users, but doesn't really directly impact the security of the desktop. It would not leak user data to the malicious site, though it could potentially result in data loss depending on what else the user was doing at the time. It is, in some ways, similar to the problems of malicious, infinitely looping JavaScript, which can lock up a browser (but not generally the whole desktop). Running browser tabs as separate processes, as Chromium does and Firefox is moving to, also mitigates the JavaScript problem to a large extent. But that's not the only problem that the report from Context, a UK-based security consulting company, outlined. Another potential attack is a cross-domain image theft. When canvas elements include cross-domain content, say an image from another site, there is a "origin-clean" flag that gets cleared in the browser which disables some of the JavaScript functions that might be used to extract the, potentially sensitive, image data from the other domain. However, a malicious canvas element could create shaders that will effectively leak the image contents. The attack relies on a technique long-used to extract cryptographic keys by doing a timing analysis. If shaders were written to take longer based on the "brightness" of a pixel, JavaScript could be used to regenerate the image based on how long each pixel takes to render. It is a complicated attack to do, and finding real-world exploits using it may be somewhat convoluted, but it is a cross-domain vulnerability. An example that Context gives is a victim site that puts up a specific profile image based on the session information stored in a browser cookie for the site, which gets sent to the site as part of the request for the image. The malicious site that included the victim image couldn't get at the cookie, but could infer the logged-in user by comparing the displayed image to a list of known "interesting" profile images. Mozilla hacker JP Rosevear responded to Context's report noting that the cross-domain image theft problem is real, even though it may be difficult to exploit in practice: "While it is not immediately obvious that it can be exploited in a practical attack right now, experience in security shows that this is a matter of when, not if." His suggested fix is the cross-origin resource sharing (CORS) proposal that would allow sites to explicitly list which other sites can include their content. The denial of service problem is harder, though. The only real defense against maliciously written shaders is to validate that code in ways that, hopefully, eliminates bad shaders. That, of course, is something of an arms race, so Rosevear also suggests that some kind of user confirmation before displaying WebGL content may be required. There are also some efforts afoot to try to handle denial of service issues in the hardware itself. GL_ARB_robustness (and GL_ARB_robustness_2) are mechanisms that the hardware makers can use to detect these kinds of problems and reset the hardware when they occur. As Context's FAQ indicates, though, that may not be real solution in the long term:
The resetting of the graphics card and driver should be seen as a crutch to
OS stability when exceptional conditions occur and not as a mechanism to
protect users from malicious code. Resetting the graphics card isn't
guaranteed to be a trouble free operation; all other users of the graphics
subsystem will need to correctly handle the event. The graphics stack would
have to ensure that any hardware resources are recreated before use to
guard against another application misusing it. This operation, while not
causing a DoS [denial of service] directly, could still indirectly [affect] the entire system and
the applications running on it.
From a security standpoint, allowing any random web site to send code that is more-or-less directly executed on system hardware is always going to be somewhat problematic. Rosevear points out that there is separation between the components of WebGL that should provide some isolation: "Nevertheless, claims of kernel level hardware access via WebGL are speculative at best since WebGL shaders run on the GPU and shader compilers run in user mode." That assumes that the libraries and drivers don't have exploitable bugs of their own, of course. As Rosevear notes, "significant attacks against [WebGL] may be possible". This is clearly an area that bears watching.
Brief items Security quotes of the week
And per-system-call permissions are very dubious. What system calls
don't you want to succeed? That ioctl? You just made it impossible to
do a modern graphical application. Yet the kind of thing where we
would _want_ to help users is in making it easier to sandbox something
like the adobe flash player. But without accelerated direct rendering,
that's not going to fly, is it?
-- Linus Torvalds
So I'm sorry for throwing cold water on you guys, but the whole "let's come up with a new security gadget" thing just makes me go "oh no, not again".
I may be one of very few people in this room who actually makes his living personally by creating what these gentlemen are pleased to call "intellectual property." I don't regard my expression as a form of property. Property is something that can be taken from me. If I don't have it, somebody else does.
-- John
Perry Barlow speaking at the e-G8 conference
Expression is not like that. The notion that expression is like that is entirely a consequence of taking a system of expression and transporting it around, which was necessary before there was the Internet, which has the capacity to do this infinitely at almost no cost.
Suppose that an attacker knows some of your past purchases on a site: for
example, past item reviews, social networking profiles, or real-world
interactions are a rich source of information. New purchases will affect
the perceived similarity between the new items and your past purchases,
possibility causing visible changes to the recommendations provided for
your previously purchased items. We demonstrate that an attacker can
leverage these observable changes to infer your purchases. Among other
things, these attacks are complicated by the fact that multiple users
simultaneously interact with a system and updates are not immediate
following a transaction.
-- Joe
Calandrino in the Freedom to Tinker blog
Successful timing attacks on elliptic curve cryptography (The H)The H reports on a successful timing attack against the Elliptic Curve digital signature algorithm in OpenSSL:
For their tests, the researchers set up
an SSL server with OpenSSL and measured the time it took to create a
digital signature using Elliptic Curve DSA (ECDSA). This allowed them to
calculate the server's secret key. When establishing an SSL connection via
the local loopback interface, they managed to do this almost
instantaneously. While packet transfer times on a local network caused
measurement uncertainties, these uncertainties could be compensated for
with some further calculations.
Overall, the attack described in Remote Timing Attacks are Still Practical [PDF] also proved feasible over a network.
No working countermeasures have so far been found; the US-CERT advises that ECDSA should no longer be used for digital signatures. To prevent this type of attack, the researchers recommend implementing time-independent functions for operations on elliptic curves.
OneSwarm: Privacy preserving peer-to-peer data sharingA BitTorrent-compatible peer-to-peer application, with privacy preservation features, called OneSwarm, has released version 0.7.5. The code is available on github and uses source address rewriting and SSL encryption to protect the privacy of its users. "OneSwarm is a new peer-to-peer tool that provides users with explicit control over their privacy by letting them determine how data is shared. Instead of sharing data indiscriminately, data shared with OneSwarm can be made public, it can be shared with friends, shared with some friends but not others, and so forth. We call this friend-to-friend (F2F) data sharing."
New vulnerabilities apr: denial of service
cyrus-imapd: man-in-the-middle attack
feh: remote code execution
gnome-screensaver: lock bypass
kernel: multiple vulnerabilities
kernel: multiple vulnerabilities
kvm: code execution
mediawiki: multiple vulnerabilities
opera: memory corruption
pure-ftpd: denial of service
ruby: arbitrary code execution
syslog-ng: denial of service
thunar: denial of service
tigervnc: password disclosure
viewvc: resource-consumption attack
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||