[Previous entry: "It seems that Microsoft has let the other shoe drop"] [Next entry: "Corporate Communications 101"]

07/27/2005: "New threats to corporate security"

Got Bluetooth? I've now seen a WinXP machine infected by someone's mobile phone. This is scary because in the the phone could be dragged "behind" the firewall by an unsuspecting employee. This has been done as a proof of concept by a security company, though I can't say . You heard it here, first.

It gets worse.

The scariest tactic I've been told about goes like this; A visitor walks in carrying a Palm Pilot. as he walks by an HP Laserjet with an IR eyeball, he touches the Palm and it beams a executable payload into the Laserjet. The payload sits in the printer collecting passwords off the network interface. When the visitor walks back by after a few hours on his way out, he touches the Palm again and via IR it sucks the collected passwords out of the printer, afterwhich the payload erases itself, leaving no evidence tit was ever there, while the visitor harvested a boatload of credentials without ever touching the printer. This isn't just theory, there are live demos.

And the whole time, the printer was printing away like nothing was going on.

And its not just PCs. Michael Lynn, formerly of Internet Security Systems presented at Blackhat about the newest issue with Cisco's IOS. Lynn had to resign from ISS in order to give his presentation, starting off with, "I'm probably about to be sued to oblivion. (But) the worst thing is to keep this stuff secret."

Luckily, some of the biggest networks have other brands of hardware in critical locations....

Also at Blackhat today, a plug and play USB root kit. In a nutshell, plug this device into an otherwise locked system and it will automatically take control of the system.

Then there's this Day 0 issue with the x86.

Every finite real number, no matter how large, has a well-defined value for sin/cos. Ideally, the floating-point result returned for sin/cos would be the representable floating-point number closest to the mathematically defined result for the floating-point input. A floating-point library having this property is called correctly rounded, which is equivalent to saying the library has an error bound less than or equal to 1/2 an ulp (unit in the last place). For sin/cos, writing a correctly rounding implementation that runs at a reasonable speed is still something of a research problem so in practice platforms often use a library with a 1 ulp error bound instead, which means either of the floating-point numbers adjacent to the true result can be returned. This is the implementation criteria the Java Math library has to meet. The implementation challenge is that sin/cos are implemented using argument reduction whereby any input is mapped into a corresponding input in the [-pi/4, pi/4] range. Since the period of sin/cos is pi and pi is transcendental, this amounts to having to compute a remainder from the division by a transcendental number, which is non-obvious. A few years after the x87 was designed, people figured out how to do this division as if by an exact value of pi. Instead the x87 fsin/fcos use a particular approximation to pi, which effectively means the period of the function is changed, which can lead to large errors outside [-pi/4, pi/4]. For example the value of sine for the floating-point number Math.PI is around

1.2246467991473532E-16

while the computed value from fsin is

1.2246063538223773E-16

In other words, instead of getting the full 15-17 digit accuracy of double, the returned result is only correct to about 5 decimal digits. In terms of ulps, the error is about 1.64e11 ulps, over *ten billion* ulps. With some effort, I'm confident I could find results with the wrong sign, etc. There is a rationale which can justify this behavior; however, it was much more compelling before the argument reduction problem was solved.

This error has tragically become un-fixable because of the compatibility requirements from one generation to the next. The fix for this problem was figured out quite a long time ago. In the excellent paper The K5 transcendental functions by T. Lynch, A. Ahmed, M. Schulte, T. Callaway, and R. Tisdale a technique is described for doing argument reduction as if you had an infinitely precise value for pi. As far as I know, the K5 is the only x86 family CPU that did sin/cos accurately. AMD went back to being bit-for-bit compatibile with the old x87 behavior, assumably because too many applications broke. Oddly enough, this is fixed in Itanium.

I've never been a fan of "fast, but wrong" when "wrong" is roughly random().