Live data from Hacker News

Remotely compromise devices by using bugs in Marvell Avastar Wi-Fi

embedi.org

41–50 of 51 posts

Re: Remotely compromise devices by using bugs in Marvell Avastar Wi-Fi

#41

Earlier quoted context omitted.

Wi-fi adapters are some of the most processing-heavy peripherals people have. After the memory controller, bus bridges, GPUs, and DMA controller, it's probably the largest one.

Does processing-heavy imply it has an RTOS in it? (Do all the things you mentioned have RTOSes in them?)

>> After the memory controller, bus bridges, GPUs, and DMA controller, it's probably the largest one

Probably best to distinguish between processing-heavy and throughput-heavy; apart from the GPU, all those are throughput-heavy but do very little to the data, and I think would not normally have a recognisable processor or an OS. There's the additional problem that they're required to boot, so nowhere convenient to load the OS from unless you scatter SPI flash across the board.

GPUs on the other hand have a full task-switching operating system.

Re: Remotely compromise devices by using bugs in Marvell Avastar Wi-Fi

#42

Given that Wifi chips already have their own ARM CPU, at this point I'd rather have that CPU which already runs its own OS to just present as a network device to do NAT. Connect it to the fixed network, use a serial link - anything will do. At least, I'd rather have anything but the current alternative: a device on the PCI bus having DMA with a firmware I can't audit. Same thing with WWAN device by the way.

My understanding is that all modern OSes now use the IOMMU to protect system memory from rogue devices. Of course that protection is only as good as the PCIe implementation and the drivers doing the mapping and operating on the mapped structures.

Re: Remotely compromise devices by using bugs in Marvell Avastar Wi-Fi

#43
post #13

Earlier quoted context omitted.

Cards: https://www.bunniestudios.com/blog/?page_id=3592

Wow. I wonder if my mental image of an RTOS on the devices is correct? I would've imagined there's some sort of firmware inside any device that communicates with a host, but when I hear RTOS I think of something fairly generic that would be deployed across a range of device types (like a Linux system but real time) rather than specialized firmware... is that accurate?

For the Wifi device mentioned in the original article, they dissasembled the firmware and found out that it uses "ThreadX": https://en.wikipedia.org/wiki/ThreadX

> "hreadX provides priority-based, preemptive scheduling, fast interrupt response, memory management, interthread communication, mutual exclusion, event notification, and thread synchronization features. Major distinguishing technology characteristics of ThreadX include preemption-threshold, priority inheritance, efficient timer management, picokernel design, event-chaining, fast software timers, and compact size. The minimal footprint of ThreadX on an ARM processor is on the order of 2KB"

ie it's generic code that gets built into a unikernel-style image with the device-specific code that actually implements the various tasks required of a wifi controller.

Re: Remotely compromise devices by using bugs in Marvell Avastar Wi-Fi

#44
post #28

Can someone please do a crowdfunding for a fully open source 802.11ac chipset and mini PCI express device? For security purposes we do not want any binary drivers, blobs, bloated boat loaders and other fancy non-security in the hardware. This is really really basic security level.

Some of the openwrt people believe they can write an open source replacement firmware for the ath10k-based devices. Someone should fund them.

Writing new firmware would be a lot easier than designing a new chipset.

Re: Remotely compromise devices by using bugs in Marvell Avastar Wi-Fi

#45
post #39
post #28

Can someone please do a crowdfunding for a fully open source 802.11ac chipset and mini PCI express device? For security purposes we do not want any binary drivers, blobs, bloated boat loaders and other fancy non-security in the hardware. This is really really basic security level.

This is a lot harder to achieve than it sounds. Open source hardware projects that go as far as chip design - are there any of these that have been successful? It needs a lot of money. You'd have to sell people a free virtual spaceship with the thousand-dollar tiers, maybe. And persuade people to accept higher per-unit costs than the cheap Chinese equivalents.

There are a lot of open-source SDR projects around for things like LTE - you'll never get the per-unit costs of fixed function taped-out designs but it should be doable. SDR stacks already exist for WiFi monitoring and analysis although most of the stacks are CPU based and therefore too slow to associate with networks because they can't send ACKs in time. With an FPGA based system the latency requirements are probably achievable.

The better approach is probably a fully open firmware for an existing ASIC - let someone else subsidize your production costs. Obviously there's still attack surface in the fixed-function ASIC components but the attack surface is way smaller and the boundary could probably be audited fairly well.

Re: Remotely compromise devices by using bugs in Marvell Avastar Wi-Fi

#46
post #28

Can someone please do a crowdfunding for a fully open source 802.11ac chipset and mini PCI express device? For security purposes we do not want any binary drivers, blobs, bloated boat loaders and other fancy non-security in the hardware. This is really really basic security level.

> Can someone please do a crowdfunding for a fully open source 802.11ac chipset and mini PCI express device? A few RF transceivers and an FPGA like an Artix-7 (which has PCIe capability) might do the trick. It wouldn't be as cheap as a mass produced chipset, but a completely open 802.11ac chipset is unlikely to be mass produced anyway. We already have examples of LTE base stations being run with SDR hardware like the…

unfortunately the FPGA ecosystem is even more closed and open source unfriendly than the wifi hardware one, you aren't allowed to know anything about the chips, how code runs, or how to upload your own code, and you even have to use vendor specific IDEs and language extensions you are lucky if work anywhere outside of windows.

Current market FPGAs definitely aren't some shining beacon alternative to shitty hardware vendors, they are amongst the worst of the lot.

Re: Remotely compromise devices by using bugs in Marvell Avastar Wi-Fi

#47

Good. I hope that vulnerabilities like this continue to surface until legislators take notice. Morally bankrupt vendors will never stop locking down hardware unless governments get involved. Fuck each and every company that does this. Fuck them all to hell.

While I agree with you that vendors need to be held accountable for shipping crap, we also have to beware that we don't end up in a world of devices we cannot do anything on. All kinds of jailbreaks, no matter if for the first generations of iPhones, for consoles, or for rooting Android devices, are based on vendors implementing shoddy security. Take it away and whoops, now we as users are fully in the death grip of…

An actionable way to discourage this outcome is to use the General Public License version 3 or later, which contains "right to repair/right to tinker" provisions: https://www.gnu.org/licenses/quick-guide-gplv3.en.html

In the United States, you can also join The Repair Association advocacy group: https://repair.org/

Re: Remotely compromise devices by using bugs in Marvell Avastar Wi-Fi

#48

Good. I hope that vulnerabilities like this continue to surface until legislators take notice. Morally bankrupt vendors will never stop locking down hardware unless governments get involved. Fuck each and every company that does this. Fuck them all to hell.

While I agree with you that vendors need to be held accountable for shipping crap, we also have to beware that we don't end up in a world of devices we cannot do anything on. All kinds of jailbreaks, no matter if for the first generations of iPhones, for consoles, or for rooting Android devices, are based on vendors implementing shoddy security. Take it away and whoops, now we as users are fully in the death grip of…

We're actually on the same page here. I should have worded my comment more clearly: Governments should get involved and force vendors to allow device owners full control over their devices. Not only to secure them selves from vendor mistakes, but also to repurpose the device to fit their needs.

Re: Remotely compromise devices by using bugs in Marvell Avastar Wi-Fi

#49
Hiring a hacker these days is a bit difficult because lots of people fall for scams. Does that mean there aren't real hackers online? NO definitely!! Make foundings about us. You can check us up at hackerone(dot)com Check our profile on Google to see what we've been up to, where we've worked and what we specialised in. Ask us questions. I prove myself beyond reasonable doubts on all Hacking jobs. Be sure you are making the right decision. Don't just make payment without knowing what approach specifically. You need a professional hacker? Send a mail to the Email on my bio hacktech@hackermail.com Be safe out there!!!

Re: Remotely compromise devices by using bugs in Marvell Avastar Wi-Fi

#50

Earlier quoted context omitted.

> Can someone please do a crowdfunding for a fully open source 802.11ac chipset and mini PCI express device? A few RF transceivers and an FPGA like an Artix-7 (which has PCIe capability) might do the trick. It wouldn't be as cheap as a mass produced chipset, but a completely open 802.11ac chipset is unlikely to be mass produced anyway. We already have examples of LTE base stations being run with SDR hardware like the…

unfortunately the FPGA ecosystem is even more closed and open source unfriendly than the wifi hardware one, you aren't allowed to know anything about the chips, how code runs, or how to upload your own code, and you even have to use vendor specific IDEs and language extensions you are lucky if work anywhere outside of windows. Current market FPGAs definitely aren't some shining beacon alternative to shitty hardware v…

A few years ago that was true, and commercial tools are still horrid and closed and necessary for certain FPGA families.

But as of right now you can use[1] the Lattice iCE40 (small, 8k LUTs), Lattice UltraPlus (5k LUTs, DSPs) and Lattice ECP5[2] (~85k LUTs, with 5G SerDes and PCIe Gen 2) with completely open tools. The ECP5 in particular would be well suited for it.

And there is a productive effort[3] to do the same for the Artix-7 and other Xilinx 7 Series parts.

Even for those parts that are still very much closed, you can load an existing bitstream on them using open tools. Intel Max10, which is the part found on the LimeSDR Mini, is one of those even though we don't have open bitstream documentation for it yet.

The major commercial FPGA tools all work Linux at this point too, I use most of them on Ubuntu routinely including Lattice Diamond, Altera/Intel Quartus, and Xilinx ISE/Vivado.

[1] http://www.clifford.at/icestorm/

[2] https://github.com/SymbiFlow/prjtrellis

[3] https://github.com/SymbiFlow/prjxray

Post reply on HN