LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityChrome reflective XSS protectionCross-site scripting (XSS) is one of the biggest problems on the web today. There are daily reports of XSS problems in various web sites and web applications (including LWN, see below). So, it is not surprising that browser makers are looking at ways to combat the problem. Previously, we looked at Mozilla's Content Security Policy (CSP), which is one approach, but the Chrome browser team has come up with something different: reflective XSS protection. There are two basic types of XSS, persistent and reflected (or non-persistent). Persistent XSS is an attack that gets stored at the site, in a comment or some other user-generated content, that can then attack any user viewing that content. Reflected attacks, instead, have the payload stored in the HTTP request itself (as GET parameters or FORM submission values). These attacks are generally disguised and the victim is tricked into submitting them. Reflected XSS flaws well outnumber persistent flaws, so it makes some sense to concentrate on those. The basic idea behind Chrome's reflective protection is to examine each script before it is run to see if it also exists in the request that was sent. If the page contents contain scripts that were sent in the request, it is likely that it is a reflected XSS attack. For example, if a link or form submission contains a parameter foo with the value:
<script>alert("XSS!")</script>
then the browser can recognize it in the response and refuse to run the script.
It isn't quite as simple as a direct string comparison, of course, as there are any number of tricks used by XSS attacks to obfuscate their intent. By using HTML entity encodings, XSS attacks can often slip by naïve tests. Things like:
javascript
may elude simple tests that are meant to prevent XSS, so the browser must
convert the request into a canonical form before doing the comparison.
In fact, a thread on sla.ckers.org shows various types of obfuscation that eludes the Chrome XSS filter. The participants, eventually including Chrome developer Adam Barth, keep attempting—mostly succeeding—to find ways around the filter. Those were then added to a WebKit bugzilla entry and many were fixed. Some of the more complicated cases are not yet handled. Several comparisons to the Internet Explorer 8 XSS filter were made in the thread, generally unfavorably to Chrome's, but the Chrome filter is still relatively new. Certainly, the Chrome developers can learn from IE8's filter. Barth looked at the IE8 algorithm (by extracting it from the binary) and compared the two:
The IE8 filter is based on a dozen or so regular expressions that are
applied to the HTTP response before parsing. Our filter works a bit
differently. It watches the scripts that are being executed after
parsing. That means we're pretty robust to tricky parsing issues (like the
/ thing mentioned above). The trade-off is that we have to be more careful
when matching the script with the request because it's been transformed by
the parser a bit. That's why you get issues like the double-encoded iframe
JavaScript URL issue above. It's being run through the parser twice, which
tripped us up.
The whole thread is worth a read for anyone interested in XSS and the various tricks used by those attacks. While the Chrome reflective protection is fairly recent, with bugs to squash and features to add, it will provide some added protection for users against XSS. It is a much simpler solutions than CSP—and doesn't require web developers to change the way they use Javascript—but it also only handles a subset of the full XSS problem. Both techniques likely have their place, but filtering reflected attacks is something that can be done more quickly than fundamentally changing the Javascript landscape as CSP requires. It seems likely that Mozilla could pick up this technique to add to its XSS protection, while still pushing CSP in the longer term. Given the "popularity" of XSS attacks, it is great to see the browser makers looking at multiple ways to reduce the risk.
Cross-site scripting here at LWNWe would like to thank Marti Raudsepp for letting us know about a security hole in the comment submission code for the site. We believe it is now fixed and, in general, that we have tightened up our HTML handling for comments. As part of that, we removed support for many attributes on HTML tags by whitelisting a small set of attributes. We might very well have been over-zealous and removed support for legitimate attributes. Please let us know at lwn@lwn.net if that is the case. We would also like to remind folks that we encourage anyone who finds a security problem with the site to contact us (lwn@lwn.net works for that too). We give prompt attention to such things and thank anyone reporting them—rather than, say, turning them over to law enforcement.
Brief items Strandboge: AppArmor sVirt security driver for libvirtJamie Strandboge writes about work he has done to add AppArmor support to sVirt on his blog. "Since virtualization is becoming more and more prevalent, improving the security stance for libvirt users is of primary concern. It was very natural to look at adding an AppArmor security driver to libvirt, and as of libvirt 0.7.2 and Ubuntu 9.10, users have just that. In terms of supported features, the AppArmor driver should be on par with the SELinux driver, where the vast majority of libvirt functionality is supported by both drivers out of the box."
Wheeler: Fully Countering Trusting Trust through Diverse Double-CompilingDavid Wheeler announces the defense of his PhD dissertation on countering the classic "Reflections on Trusting Trust" attack, which Ken Thompson spoke about in 1984. That attack subverts compilers to continuously re-infect binaries produced by that compiler (including the compiler binary itself) with some kind of malicious payload (a login back door was Thompson's example). The attack is impossible to detect, except by using Wheeler's technique, which was originally described in a 2005 Annual Computer Security Applications Conference (ACSAC) paper [PDF]. His dissertation expands on that work, and the defense of it is open to the public on November 23 at George Mason University in Fairfax, Virginia. "This 2009 dissertation significantly extends my previous 2005 ACSAC paper. For example, I now have a formal proof that DDC is effective (the ACSAC paper only had an informal justification). I also have additional demonstrations, including one with GCC (to show that it scales up) and one with a maliciously corrupted compiler (to show that it really does detect them in the real world). The dissertation is also more general; the ACSAC paper only considered the special case of a 'self-parenting' compiler, while the dissertation eliminates that assumption."
New vulnerabilities expat: buffer overflow
firefox, xulrunner: multiple vulnerabilities
kernel: null pointer dereference
kernel: null pointer dereference
kernel: denial of service
libhtml-parser-perl: denial of service
mahara: multiple vulnerabilities
proftpd-dfsg: certificate spoofing
rt3: JavaScript injection
squidGuard: buffer overflows
wireshark: multiple vulnerabilities
wireshark: denial of service
Page editor: Jake Edge |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||