Interesting Stuff

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).

(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 2ⁿ 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.