Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Wait so the kill switch is really just a suggestion that is then handled in the card”s firmware?

I guess that’s how things like cameras status led is compromised?



On linux you can enable most radio cards regardless of the hardware disable status by running "rfkill unblock all". This is the correct behavior according to the spec as otherwise systems using a software button + permanent hardware lockout won't work.

Most webcam use firmware control over the led: https://www.youtube.com/watch?v=ggRU9gGVRzE


There's softblock and hardblock, rfkill shouldn't be able to unblock hardblocks. "unblock all" just attempts to soft unblock all devices. Maybe it could also operate some special software operable hardblock hardware but that doesn't count.

Also/IIRC, the old webcam issue was some cameras had ~1s delay between first image to LED on, and zero for last frame to LED off, so initialization or configuration change commands could be mashed to allow LED to light in user unhelpful ways: e.g. only lit for imperceptible length of time or intermittently lit as shown. Apple and few other vendors modified this behavior as well as added a minimum LED on duration while after this went on media. It's still "controlled by software", sure, not like tapped off of CMOS imager power supply, but not like implemented in /lib/modules/webcam_comforting_led.so.1, either.


I was able to use the rfkill command on a Dell and a Thinkpad with the hardware switch turned off. However I don't know how that was implemented internally, maybe the switch was not connected directly to the mini-pcie slot. I don't have these laptops anymore so I can't check it.

I made the video on the webcams, these are quite modern ones. Nearly all of them have special UVC commands that allow reading and writing the internal CPUs memory (a lot are 8051 based). You can find the register that controls the led GPIO and control it freely. Only on one of them I did not find a way to modify the led behavior without modifying the firmware to add an extra command.


No. I suggest you do skim the article.

The author taped the switch readout pin (mPCIe pin 20) at the card side, and the card was so designed that it assumes the switch is set to not-kill when the switch is not present at all.

We do not know how deep the mechanism goes within the card. It is only shown that the card do work if the pin is open.


Which means that then the switch is _exactly_ "just a suggestion that is then handled in the card”s firmware". It doesn't cut the power to the card.


"in the firmware" part is pure speculation. It's fair to assume worst as a security best practice, but pedantically we just don't know if a mal-firmware can in fact ignore it. There could be like, the kill switch input distributed to radio amplifier and such. A lot of analog components has on-off(usually not-enable) inputs.


We don't actually know that. It's possible that connecting that pin shorts some circuit on the card that prevents it from operating. I suspect you're right though.


It usually is not, most cards will allow software unlocking even if the hardware switch is off. You can run 'rfkill unblock all' on a Linux system to test it.


rfkill shouldn’t be able to unblock hardblocks, “all” means “all cards here”, not “all of those nonsense”. Is that your experience or are you just theorizing?


It's pretty much just a button, if it doesn't physically cuts power, I'd suggest.

I think with billion dollar budget year after year, you pretty much go for firmware level attacks thees days. 0click 0day as-a-service is private economy and.. cheap and very different from what they want: long term backdoor access to everything, without the possiblility to spot it in user space or OS.


It's even more impressive that it's actually connected to a pin on the wifi card rather than just being a key signaling the OS to disconnect wifi.


That's probably the best thing we can do (for now) for a PCIe device. PCIe hotplug [1] is a thing, but your (badly-written) WiFi kernel driver is probably not designed for that.

[1] https://lwn.net/Articles/767885/


You might enjoy a https://frame.work laptop. Camera and microphone are physical kill switches, and you'll see the device drop off USB when you toggle them.

(No wifi killswitch on Framework laptops at this time.)


> (No wifi killswitch on Framework laptops at this time.)

Because it is practically not possible with current hardware. Theoretically it is possible to design PCIe hot-plugging but no WiFi card/driver supports it.

Maybe it is possible to do over Thunderbolt but I wouldn't hold my breath.

Of course there are USB WiFi chips but they are much worse in every aspect than PCIe ones.


Wait till you learn about Apple toggles


The ones that turn themselves back on at 3 AM so it can update itself whether you like it or not




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: