When people ask for security holes as features
Raymond Chen's blog has an interesting look at companies trying to bypass Windows XP's checks that a driver has been WHQL-certified: My favorite stunt was related to my by a colleague who was installing a video card driver whose setup program displayed a dialog that read, roughly, After clicking OK, do not touch your keyboard or mouse while we prepare your system. After you click OK, the setup program proceeds to move the mouse programmatically all over the screen, opening the Display control panel, clicking on the Advanced button, clicking through various other configuration dialogs, a flurry of activity for what seems like a half a minute. When faced with a setup program that does this, your natural reaction is to scream, Aaaigh! There are many more examples (in followup comments and links) of vendors cheating in the certification and install process: my new Dell laptop came with an usigned bluetooth driver whose setup automatically clicks on the Continue button of the dialogs while installing the driver the driver for a USB memory key [...] would install and auto-push the button on that warning dialog. XP SP2 added a new check for kernel memory pool corruption and guess what? This driver would blue-screen every time the memory key was plugged in. I work on a wifi product that sometimes is bundled with wifi cards. When packaged like that our installer also installs the wifi card dirver. Guess what. The suits are all upset about the unsigned driver warning, and they are sure that a programmer more clever than me could make them go away. Of course actually getting the drivers certified is too expensive. Excuse me while I get back to work on my TPS report. I still remember one of Linksys's Wireless B PCMCIA cards. I went to install the driver, the instructions actually said something to the tune of Ignore this warning box, it doesn't mean anything important. Continue clicking OK on every screen until the driver finishes installing. Hell I could have put a box in that said Click here to format your hard drive and I'm sure some end users would have clicked OK. Cisco is a huge company, surely the WHQL payment isn't much to them. At a company I used to work for they had found away around that dialog box. They would silently launch the System Properties / Driver Signing Options dialog, send windows messages to select Ignore and then click ok, effectively turning off the dialog box (BTW, the code to re-enable the setting was commented out, so the installer made your machine less secure forever -- great stuff coming from a security company). More details at http://blogs.msdn.com/oldnewthing/archive/2005/08/16/452141.aspx. The best suggestion is that the warning be changed to: Warning! Your hardware manufacturer hasn't bothered to test this driver! Do you feel lucky? [Yes] [No] Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Fwd: Tor security advisory: DH handshake flaw
- Forwarded message from Roger Dingledine [EMAIL PROTECTED] -
From: Roger Dingledine [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Thu, 11 Aug 2005 21:31:32 -0400
Subject: Tor security advisory: DH handshake flaw
Versions affected: stable versions up through 0.1.0.13 and experimental
versions up through 0.1.1.4-alpha.
Impact: Tor clients can completely lose anonymity, confidentiality,
and data integrity if the first Tor server in their path is malicious.
Specifically, if the Tor client chooses a malicious Tor server for
her first hop in the circuit, that server can learn all the keys she
negotiates for the rest of the circuit (or just spoof the whole circuit),
and then read and/or modify all her traffic over that circuit.
Solution: upgrade to at least Tor 0.1.0.14 or 0.1.1.5-alpha.
The details:
In Tor, clients negotiate a separate ephemeral DH handshake with each
server in the circuit, such that no single server (Bob) in the circuit
can know both the client (Alice) and her destinations. The DH handshake
is as follows. (See [1,2] for full details.)
Alice - Bob: E_{Bob}(g^x)
Bob - Alice: g^y, H(K)
Encrypting g^x to Bob's public key ensures that only Bob can learn g^x,
so only Bob can generate a K=g^{xy} that Alice will accept. (Alice, of
course, has no need to authenticate herself.)
The problem is that certain weak keys are unsafe for DH handshakes:
Alice - Mallory: E_{Bob}(g^x)
Mallory - Bob: E_{Bob}(g^0)
Bob - Mallory: g^y, H(1^y)
Mallory - Alice: g^0, H(1^y)
Now Alice and Bob have agreed on K=1 and they're both happy. In fact,
we can simplify the attack:
Alice - Mallory: E_{Bob}(g^x)
Mallory - Alice: g^0, H(1)
As far as we can tell, there are two classes of weak keys. The first class
(0, 1, p-1=-1) works great in the above attack. The new versions of Tor
thus refuse handshakes involving these keys, as well as keys 0 and = p.
The second class of weak keys are ones that allow Mallory to solve for y
given g^y and some guessed plaintext. These are rumored to exist when the
key has only one bit set [3]. But in Tor's case, Mallory does not know
g^x, so nothing she can say to Alice will be acceptable. Thus, we believe
Tor's handshake is not vulnerable to this second class of weak keys.
Nonetheless, we refuse those keys too. The current Tor release refuses
all keys with less than 16 0 bits set, with less than 16 1 bits set,
with values less than 2**24, and with values more than p - 2**24. This
is a trivial piece of the overall keyspace, and might help with next
year's weak key discoveries too.
Yay full disclosure,
--Roger
[1] http://tor.eff.org/doc/tor-spec.txt section 0 and section 4.1
[2] http://tor.eff.org/doc/design-paper/tor-design.html#subsec:circuits
[3]
http://www.chiark.greenend.org.uk/ucgi/~cjwatson/cvsweb/openssh/dh.c?rev=1.1.1.7content-type=text/x-cvsweb-markup
and look for dh_pub_is_valid()
- End forwarded message -
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
