It was too long-form to continue the discussion on Twitter, so here we go:
The bug is, basically, that when looking for a hidden AP, Android doesn't care what the BSSID of the response is, ie, it doesn't cache the BSSID of known hidden SSID APs.
This actually doesn't seem, to me, like a bug at all. The BSSID is not relevant to association, the SSID defines the network. On a multi-AP roaming network any number of BSSIDs could reply to a probe request for a hidden network.
The assumption that being able to reply as the hidden network leads to loss of credentials doesn't make any sense either: Sure, the client will try to talk to you to do a WPA handshake, but if you don't know the key, it won't succeed, and it trying to associate won't give you insight into the key. Also this doesn't give you anything that setting up a generic rogue wouldn't give you.
So unless there's something I don't understand going on, I don't see the threat. I don't even see the bug - when you send out a probe to see who is out there, you have to expect any number of responses, and the whole mechanism of roaming is to go to a new BSSID. From the bugtraq post:
5. Turn off the first AP 6. Turn on the other AP 7. See your Android device automatically connect to the second AP
This is exactly how roaming is SUPPOSED to work, this
doesn't seem like a bug to me.
Anyone see something I don't?