Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Google plasma globe affair of 2012

lcamtuf.coredump.cx

Post reply on HN
Print view View original

41–50 of 103 posts

Re: The Google plasma globe affair of 2012

#41

Post by valleyer »

ryan-c wrote: post #15
Arnavion wrote: post #4

>Another critical optimization boiled down to realizing that the response packet allows up to six keycodes to be reported at once. This might have seemed like a straightforward 6x speed gain, but not so: on MacOS, the keystrokes were dequeued not in the order they appeared in the packet, but from the numerically lowest scancode to the highest. This mind-boggling quirk [...] Reporting multiple keys down in the same pa…

That seems like behavior that had to be actively added though, and I am extremely curious why.

One plausible (to me) explanation is that the received scancodes are added to a bit vector (a "set"), discarding their original order. Some time later, the bit vector is iterated in numerical order.

Re: The Google plasma globe affair of 2012

#42

Post by maxerickson »

kelnos wrote: post #37

The author links to UKIP[0], a Linux daemon that they built to try to protect against these kinds of attacks. Did a quick "apt search" on my Debian machine, but nothing came up. Do any major distros package this, and do any install and enable it by default? I guess it uses heuristics to determine if a device is evil, and that could cause a lot of false positives (which would create spurious bug reports and support ca…

It calculates the times between the most recent 5 keystrokes and if they are too fast it carries out a configured action (logs the event or removes the device driver).

Re: The Google plasma globe affair of 2012

#43

Post by Karliss »

ryan-c wrote: post #15
Arnavion wrote: post #4

>Another critical optimization boiled down to realizing that the response packet allows up to six keycodes to be reported at once. This might have seemed like a straightforward 6x speed gain, but not so: on MacOS, the keystrokes were dequeued not in the order they appeared in the packet, but from the numerically lowest scancode to the highest. This mind-boggling quirk [...] Reporting multiple keys down in the same pa…

That seems like behavior that had to be actively added though, and I am extremely curious why.

There are plenty of ways why it might have been added for other purpose. A lot of keyboard APIs provide keyup/keydown events. The most obvious way for implementing that is by having a array or bitmask of all the keys. And once the keystate array is updated from usb packet, the information about order of keys in packet is lost. It also follows the principle of abstracting away low level hardware details. USB isn't only way you could attach a keyboard, there are also PS2 and bluetooth keyboards with different packet structures. Even for USB-HID the standard packet format consisting of bitmask for modifier keys + array of 6 other keys is only the default format guaranteed to work in BIOS. USB HID specification includes standard mechanism for defining the format of packets (report descriptors), which is one of the ways you can achieve more than 6-key rollover .

Re: The Google plasma globe affair of 2012

#44

Post by Arainach »

godelski wrote: post #40
theptip wrote: post #21

Earlier quoted context omitted.

NSA’s TAO surely has many orders of magnitude more budget than Google’s red team?

I don't think the NSA pays as well though. You also have large restrictions. Not just stuff like never having smoked weed in your life (we are talking about CS people...) but that once you even have a security clearance (a pain to get in the first place) you have a lot of daily life headaches. You have to carefully watch what you say. International travel has to be reported (and can even be a big hassle). Etc. I'm no…

Correct, government pay scale is a huge problem for talent acquisition. Your choices are either someone who is so ideologically devoted that they're willing to work for 5-25% of what they're worth or "work for us or you're going to prison for a long time".

Citations:

https://apply.intelligencecareers.gov/job-description/119486...

Cyber Mitigations Analyst/System Vulnerability Analyst - Entry to Expert Level (Maryland)

Network Cyber Mitigations Engineers and System Vulnerability Analysts analyze vulnerabilities and develop mitigations to strengthen defenses. They produce formal and informal reports, briefings, and guidance to defend against attacks against network infrastructure devices or systems. NSA analysts' competencies run the gamut of data transport possibilities. They work with traditional wired networks, wireless transport, including Wi-Fi and cellular, collaborative platforms such as video teleconferencing, and the hardware and software that support it all.

Pay Plan: GG, Grade: 07/1 to 15/10

https://www.opm.gov/policy-data-oversight/pay-leave/salaries...

In a very high cost of living area, that means that entry level is $31K and the absolute top for expert level is $176,300.

Compare that to what FAMG are paying new college grads.

Re: The Google plasma globe affair of 2012

#45

Post by Karliss »

dpatterbee wrote: post #22
ryan-c wrote: post #15

Earlier quoted context omitted.

That seems like behavior that had to be actively added though, and I am extremely curious why.

Something in the back of my mind is telling me that it's actually spec-compliant to send the 6 scancodes in numerical order. Could very well be misremembering though, and most implementations accept near enough anything from an HID device in my experience

Appendix C: Keyboard Implementation from the Device class definition for HID states "The order of keycodes in array fields has no significance. Order determination is done by the host software comparing the contents of the previous report to the current report. If two or more keys are reported in one report, their order is indeterminate".

Re: The Google plasma globe affair of 2012

#46

Post by jimrandomh »

It seems pretty scandalous to me that most operating systems still haven't implemented any mitigation for pretend-to-be-a-USB-keyboard attacks.

Fixing it isn't trivial, but it's hardly insurmountable. The solution is fairly simple: Whenever a new keyboard is plugged in or types its first keystroke, lock the screen, and don't accept key input to places other than the login form from a new keyboard until that keyboard has typed the user's login password. (You also need to build a way to authorize legit-fake-keyboard devices like barcode scanners that type the barcodes they scan, but that's not to difficult.)

Given the high prevalence of USB devices with infectable firmwares, and the large number of USB cables of questionable provenance that no one pays much attention to, it doesn't seem okay to leave this vulnerability open.

Re: The Google plasma globe affair of 2012

#47

Post by tellmemore145 »

wil421 wrote: post #2

This seems pretty cool. It reminds me of a story I heard recently. Crooks were knocking doorbell cameras off of wifi by an assumed deauth attack. I looked it up and there are “maker watches” that will do deauth “bombs” for you, no soldering required. A nefarious plasma globe could hide of lot of nasty stuff, you don’t even need to plug it in via USB to cause harm.

Can you link to one of these watches? If they're being sold with that purpose-build functionality, that's probably a federal crime. You cannot make, possess, or operate a signal jammer in the US.

Re: The Google plasma globe affair of 2012

#48

Post by pitaj »

jimrandomh wrote: post #46

It seems pretty scandalous to me that most operating systems still haven't implemented any mitigation for pretend-to-be-a-USB-keyboard attacks. Fixing it isn't trivial, but it's hardly insurmountable. The solution is fairly simple: Whenever a new keyboard is plugged in or types its first keystroke, lock the screen, and don't accept key input to places other than the login form from a new keyboard until that keyboard…

That's actually a really good idea, but I think it could cause problems for things like external numpads.

Maybe require the user to type a random combination of keys shown on the screen before enabling a given input device, instead of their own password?

Re: The Google plasma globe affair of 2012

#49

Post by dzhiurgis »

jimrandomh wrote: post #46

It seems pretty scandalous to me that most operating systems still haven't implemented any mitigation for pretend-to-be-a-USB-keyboard attacks. Fixing it isn't trivial, but it's hardly insurmountable. The solution is fairly simple: Whenever a new keyboard is plugged in or types its first keystroke, lock the screen, and don't accept key input to places other than the login form from a new keyboard until that keyboard…

That doesn't stop a keyboard that is actually backdoored to execute payload sometime much later after setup.

Re: The Google plasma globe affair of 2012

#50

Post by paranoidrobot »

pitaj wrote: post #48
jimrandomh wrote: post #46

It seems pretty scandalous to me that most operating systems still haven't implemented any mitigation for pretend-to-be-a-USB-keyboard attacks. Fixing it isn't trivial, but it's hardly insurmountable. The solution is fairly simple: Whenever a new keyboard is plugged in or types its first keystroke, lock the screen, and don't accept key input to places other than the login form from a new keyboard until that keyboard…

That's actually a really good idea, but I think it could cause problems for things like external numpads. Maybe require the user to type a random combination of keys shown on the screen before enabling a given input device, instead of their own password?

> require the user to type a random combination of keys shown on the screen before enabling a given input device

If you could type it on any device, and you could guarantee that the OS could remember that device, I could see that being workable.

I would also worry about:

Ensuring that the keys shown bit is properly accessible to screen readers/braile devices, etc.

Ensuring that automation could authorise a device, or disable the prompt requirements

Ensuring that the OS actually remembered it. Plugging into different docks at home/work/conference room and having it prompt you to re-authorise your keyboard would drive people up the wall. eg: because during USB Enumeration the port numbers on your dock got switched, or they plugged the dock into the other side of their computer, or the Wireless USB controller is slow at starting up.

How to handle an unauthorised device when there's no other usable input devices. eg I started up my HTPC, and a few seconds later the IR receiver wakes up and is now marked as unauthorised - the device may not have a keyboard but that receiver appears as one. Or maybe I'm trying to fix a laptop and the on-board keyboard is broken, so how do I plug in a USB keyboard to get at the data on it (Maybe I can't reboot)

Some of these things might conflict with having such a lockout.

Post reply on HN