
Remotely compromise devices by using bugs in Marvell Avastar Wi-Fi - skeetmtp
https://embedi.org/blog/remotely-compromise-devices-by-using-bugs-in-marvell-avastar-wi-fi-from-zero-knowledge-to-zero-click-rce/
======
cataflam
WiFi chips and baseband processors are particularly attractive targets for
exploitation, since they are network entry point for devices, and running
systems that have probably been less investigated (at least publicly).

Very nice research and writeup. For those who haven't seen it a couple of
years ago, Project Zero also had a series of articles about exploiting
Broadcom's WiFi stack [0].

[0] [https://googleprojectzero.blogspot.com/2017/04/over-air-
expl...](https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-
broadcoms-wi-fi_4.html)

------
acd
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.

~~~
mrsteveman1
> 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 LimeSDR, which is just an RF transceiver and an Altera FPGA, with a USB3
connection to the FPGA fabric.

In fact there are some SDR/FPGA dev kits that are Mini PCIe size and intended
for use inside a laptop, specifically designed with LTE in mind[1].

So WiFi seems doable, even if you end up with a soft core CPU in the FPGA to
do the same jobs WiFi chipset firmware is doing right now, at least you'd have
full control over it and the firmware running on it.

[1]
[https://www.crowdsupply.com/fairwaves/xtrx](https://www.crowdsupply.com/fairwaves/xtrx)

~~~
throwaway2048
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.

~~~
mrsteveman1
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/](http://www.clifford.at/icestorm/)

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

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

------
devereaux
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.

~~~
minipci1321
Not speaking specifically of the OP case, but CPU gets less and less involved
in the datapath starting from a certain requirement of the max throughput.
Insisting on it's going through the CPU still would raise the bar on the CPU
(as a consequence, more fast RAM and increased overall power consumption,
shorter battery life).

> with a firmware I can't audit.

In modern fast datapaths, there is a good deal of hardware acceleration
involved, the firmware code would probably be incomprehensible without
intimately knowing these.

~~~
devereaux
Yes, there would be a IO load.

Tradeoffs, as always.

For some applications, I want low latency and high throughput. For others, I
want security.

------
ComodoHacker
> Patches are in the works.

Does than mean the procedure of responsible disclosure was followed but vendor
failed to patch on time?

------
PappaPatat
TL;DR Reseacher finds super cool RCE over (unconnected) WiFi for the Marvell
Avastar Wi-Fi chipset family firmware and one to (locally) exploit the AP
device driver.

List of impacted devices includes PS4, Xbox One, Samsung Chromebooks, and
Microsoft Surface devices.

Nicely written paper from Embedi researcher Denis Selianin himself:

[https://embedi.org/blog/remotely-compromise-devices-by-
using...](https://embedi.org/blog/remotely-compromise-devices-by-using-bugs-
in-marvell-avastar-wi-fi-from-zero-knowledge-to-zero-click-rce/)

~~~
sctb
Thanks! We've updated the link from [https://www.zdnet.com/article/wifi-
firmware-bug-affects-lapt...](https://www.zdnet.com/article/wifi-firmware-bug-
affects-laptops-smartphones-routers-gaming-devices/).

------
jake_the_third
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.

~~~
mschuster91
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 what vendors and RIAA/MAFIAA allow us to do.

~~~
userbinator
_we also have to beware that we don 't end up in a world of devices we cannot
do anything on._

IMHO it's already gotten a bit too far in that direction, and if there's no
mass revolt (which is itself quite unlikely), it's only going to get worse.
The old Franklin quote has never been so relevant... people these days are so
highly valuing "safe" over "free", that they don't realise they're building
prisons around themselves.

------
mehrdadn
I'm confused.. so Wi-Fi chips run OSes inside them now?

~~~
ccnafr
A RTOS is not really an OS, just a super-fast way of dealing with I/O streams.
More driver/firmware than OS, if you ask me. But some companies need fancy
words for marketing, I guess.

~~~
cataflam
> not really an OS, just a super-fast way of dealing with I/O streams

Saying this without any animosity, but you would probably be interested in
reading about the history of operating systems. Desktop OSes are a (very
visible) minority, and it's the opposite way in my opinion: a desktop OS is an
OS + a large suite of tools + a shell.

It's literally something that operates the system so that every program
written doesn't have to handle all the low level IO, that enables task
management, etc.

[https://en.wikipedia.org/wiki/History_of_operating_systems](https://en.wikipedia.org/wiki/History_of_operating_systems)

