Posts tagged ‘xss’

A couple cool hacks

First off, Flash is vulnerable to by far the most awesome hack I’ve ever seen (there’s also a good summary of that paper). The attack has several different steps with integer overflows and failed memory allocations, but the heart of the matter is that the Flash player uses a 2-step process to validate that the code it’s running is probably safe, and this exploit changes the representation of the code in between the two checkers (it marks more of it as a no-op, so the second checker ignores the code with the exploit in it). This attack is awesome enough that it can carry out its task without disrupting the Flash player, so an unwary user will be none the wiser. and since there’s basically only one Flash player out there, every version of Flash is vulnerable. Yes, on Windows and even on Windows Vista despite their added security systems, as well as in principle on Linux and Mac. Yes, in both IE and Firefox (and presumably Safari also). This is yet another reason to install NoScript and FlashBlock on Firefox, so that sites cannot use Flash unless you give them permission. This is also another reason why standards should be open, so we can have more than one implementation of the Flash player, so not everyone will be vulnerable when something like this comes along.

The second hack I recently read about comes from Defcon celebrity Dan Kaminsky, who recently showed a very dangerous exploit that makes use of the way many ISPs these days turn DNS errors into pages of ads. This practice breaks the Same Origin Policy, so that your browser trusts these pages as though they came from the actual domain you typed in. To give an example, suppose I have an account with Bank of America and I go to ww.bankofamerica.com. Ordinarily, I’d get a DNS error. However, with certain ISPs these days, I would instead get a valid webpage saying the site doesn’t exist, but here are some ads instead. However, my browser asked for a website from bankofamerica.com and got back a website, so it trusts that it came from the bank. Consequently, it trusts the site with any cookies I have from BoA (these cookies are how BoA knows which account I’m logged into). If someone can put an XSS attack on the ISP’s ad injection system, they can grab my cookies and log into the bank as me. Yes, the bank can defend against things like this, but it’s an unusual enough hack that many companies aren’t defending against it. So beware, and if your ISP is doing this (for instance, if ww.bankofamerica.com returns a valid website), opt out of it! In addition to exposing users to this sort of attack, these ad injection systems often break DNS, which in turn breaks non-HTTP error handling (for instance, I could not VPN into work until I opted out of my ISP’s version of this crap).

Adobe PDF exploit

There is an exploit in the Adobe PDF plugin for web browsers. Adobe has already fixed the vulnerability, so you should all update your plugins. This vulnerability affects users of Internet Explorer and Firefox, on Windows and Linux (and any other browser/OS combination that uses the Adobe plugin).

Protected: Adobe PDF exploit: trusted friends version

This content is password protected. To view it please enter your password below: