Archive for the ‘security’ Category.
I originally wrote this in 2011, but am copying it here for posterity:
Yesterday [in 2011], I rebooted my Android smartphone (i.e., removed and reinserted the battery) in a location with absolutely no cell phone coverage but with great WiFi. I then could access the Internet at large, but Google services (including GMail, Reader, and Plus), did not work (this is to say, locally stored data was still available, but I could not interact with the cloud). When I then moved to an area with cell phone service, Google services started working again. Who can explain why?
I doubt it makes a difference, but I have [had] a Nexus One on T-Mobile. Find the answer below the break! →
Looking at Sun’s take on it and Secunia’s links, there’s a fun little exploit in Java’s calendar objects that can allow a remote user to obtain escalated privileges, allowing them to read, write, and execute any files on your computer that you have access to. The interesting thing about this bug is that it doesn’t depend on memory being set up a certain way, which means it works reliably on a whole bunch of versions of Java, and in Mac, Windows, and *nix environments. You should update to the most recent version of Java to avoid this (see the Resolution section in the link to Sun above). Also, if you don’t use Java applets on the web, you might consider disabling Java in your browser (for Firefox, it’s under Edit > Preferences in the Content tab), so you don’t need to worry about this (programs that you download and run manually are much less likely to have exploits than programs you might automatically start running from visiting the wrong website).
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).
You may remember in November 2005 when I wrote about  the Sony/BMG rootkit scandal. To summarize: they put software on their music CDs that, when run in a computer, automatically installed files you couldn’t detect (this was the rootkit part) that acted a lot like malware, and screwed with your CD-ROM drivers so that if you tried to uninstall it, you could no longer use your CD-ROM drive. The intended purpose was to run DRM software that kept you from copying your CDs, and to hide this software so you couldn’t uninstall it. However, the rootkit could also be exploited by others, so that any malicious software (if installed in the right place) would go completely undetected by any antivirus program you might be running. It was nasty stuff. Sony eventually recalled the CDs and offered to give out software to remove the rootkit if you gave them your name, address, phone number, and a bunch of other information. In the meantime, the FTC ruled that the software was illegal, and Sony paid out millions of dollars in class-action lawsuits.
Why do I bring this up, I hear you ask? Well, it seems that Sony can’t let this idea die: earlier this week it was revealed that Sony is trying a similar thing with their new USB flash drives. Again, this software automatically installs a rootkit on your computer, and again this rootkit can be easily exploited by any other software to hide files on your machine. I suspect this will end similarly, with a recall and a class-action lawsuit, assuming this gets as far in the media as the last rootkit did (I hope the media picks up on this).
I remember back in the day when Sony was a great company, and I really liked them. Things seem to have changed significantly since Howard Stringer became CEO of the company (which happened about 9 months before the first rootkit scandal was born). These days, I’m really dismayed with them. I’m now going to start boycotting Sony products (which shouldn’t be too hard, since I don’t buy much from them anyway).
 Only half the links in my old post still work. Sorry about that. Does anyone have any good ideas for how to avoid this problem in the future?
This weekend I went to Defcon 0xF with psifer and inferno0069, and it was a blast.
 Yes, he’s so awesome that even his tmesis gets tmesis. 
 I admit, I’ve been looking for an excuse to use the word “tmesis” for a while now.
(found while reading the current XKCD)
Java’s “random” number generator has some surprisingly simple patterns in it. Nearly all random number generators on computers are pseudo-random, meaning that they only seem random-ish and are not truly random (with some notable but impractical exceptions). This happens because computers themselves are deterministic and therefore inherently non-random. Most pseudo-random number generators these days use the previous “random” value as an input to create the new value, which will be used to create the next one after that (which is why plots like these are often used to evaluate the effectiveness of a PRNG: by plotting the current value with the previous one, you can see how much the values get scattered around the range of outputs). As an aside, I should note that plotting the same thing in 3-D (with the current value, the previous value, and the value before that as the 3 coordinates) can reveal other problems, such as the problems in Randu, an early PRNG. Anyway, because most PRNGs use their previous value to compute the next one, they will cycle after they get the same value twice. A good PRNG that generates n-bit numbers shouldn’t cycle until it has generated 2n of them. Java’s implementation appears to be much worse than this, which is disappointing. Come on, guys, you can do better! The cryptographically secure hash is my favourite, and I’m currently trying to prove that NC≠P using a variation of this. If it’s any consolation to Sun (the creators of Java), Matlab has similar problems.
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).