Over the Air: Exploiting Broadcom’s Wi-Fi Stack
googleprojectzero.blogspot.com
googleprojectzero.blogspot.com
And today we have this very impressive counter-example of Google putting some engineers to work for months doing vuln research for making, in the end, EVERYONE safer: Apple users, Samsung users, and hundreds of other mobile device vendors who use this popular Broadcom Wi-Fi chipset in products shipped to 1B+ users.
But no, somehow, tomorrow again it is going to be all Google's faults that Android-derived commercial works are insecure and poorly maintained by their respective vendors.
The Project Zero team is excellent and we should all be grateful for their work. But we should also continue to hold Google's feet to the fire on the state of Android security, since it is truly a mess, and they are probably the only player to have the power and ability to fix it.
If you want a phone with top-notch security, buy a Google phone which is guaranteed, by Google, to come with 3 years of monthly security updates.
Basically, it allows all the running .exe programs signatures be checked at once with 56+ virus checking websites and results shows up in the GUI of procexp.
No wasting of CPU cycles to scan every files in the system, typical < 3 seconds to check all the running programs - Light up green/red in GUI.
https://www.youtube.com/watch?v=RnPtuTbqzd4&t=3s
Love to see google do something similar to this in Android.
It is very trivial for Google to dev, deploy these kind of tools/REST API/website. If this is deploy in billions + Android phones, Google should be able to detected/collected/analyze new/potential malwares instantly.
Known good programs with valid signatures - do nothing.
Unknown programs sig - setup special container and monitors app behavior - collect the binaries if needed.
Also, I think google should be able to separate the Google control portions of AOSP from the 3rd party vendors systems drivers/utilities and allow them to be upgrade separately.
I used to work on porting the AOSP on cell/tablet SOC before. It is doable.
THis sounds good, but it can take much less than 3 seconds to compromise user-space data and ship it off.
And thereby lose access to the Play Store?
Amazon would probably let them use their store though...
Samsung alone has more market share (by device) than Apple.[1] Samsung could probably do it, but it would be bumpy.
> Amazon would probably let them use their store though...
Maybe not without major concessions. Amazon subsidizes a lot of apps in their store because of their add serving architecture.
It might come though http://www.androidpolice.com/2017/02/06/no-really-this-time-...
I find it amazing that supporting a $1000 phone for 3 years is considered excellent. It's not very sustainable to make several billion new smartphones every 3 years...
But I agree that $500+ phones (Google AND Apple) should IMHO be security-supported for 5 years. It would be better for all of us.
A 128GB Pixel XL with device protection is $968 US before tax and still has the same 3 year support as the entry level Pixel.
The fact is Google sells a $1000 phone with 3 years of support. They also sell less expensive variants with 3 years of support.
If you buy a phone that you know is already going to be obsoleted soon (it's not like Apple makes its release schedule a mystery), you should assume it will have less support than the latest model.
When phone vendors releases a phone, they can deposit the vendors custom binaries/source in google servers.
Google will maintain and release security updates for vendors for X number of years for Y amount of $$$/Year.
The phone vendors can snap a "Android Security Update Guarantee by Google until year ZZZZ" logo/label on the phone.
In a plateauing market where more customers buy their own phones, it could be a differentiating factor. As an iPhone user I buy an unlocked phone every 3 years or so, updates are therefore important to me -- but clearly not to enough of the Android market right now.
Right now, I'm on a Nexus 5x that works on Verizon while not officially supported. Verizon network, without the Verizon crapware and retarded (as in, delayed or never delivered) security updates. I might move to the Pixel 2, when it comes out. Even then, I'll buy it directly from Google and forego the Verizon crapware-and-delay leash.
Samsung seems to have a renewed commitment to timely updates, and the moxie to pressure U.S. carriers to pass them on -- somewhat.
Other than that, I'd advise most of my friends to stay away from Android on U.S. carriers. It continues to be a shitstorm. My friends with Apple remain mostly simply happy and unstressed. I'm not particularly fond of "walled gardens." But for a lot of people, it's "just a phone" and they want it to "just work."
My point regarding Google itself: They bought Motorola and had Motorola thence promising timely updates for a reasonable period of time. Didn't happen.
I trust Google to do what it perceives to be in its best interest. Including updating its own phones for PR reasons. Beyond that, just like the newer products they launch or buy and then often kill a year later, it's a crapshoot.
P.S. Like others are expressing, Google's a big place with many pieces. As to the topic of the OP, I'm glad Project Zero continues to have support and is doing what it's doing. And that it has the muscle and inertia of Google behind it, to weather the political and legal shitstorm attendant with the mess that is is IS/IT security, these days.
Google gets away with this because it is "free", so the refrain is "you can't complain if it's free". Google could go the same route Microsoft did, but it chooses not to.
Phone manufacturers would be happy to have binary blob updates for free - but it would never happen. Google would have to custom-build, test, and certify every binary blob for every piece of hardware, which is an unjustifiable cost.
If you want a phone with top-notch security, buy an Apple phone. They're supported longer, they fix their security bugs promptly, and they honestly have a better model for their OS anyway. (disclaimer: I hate Apple)
In general yes, but not always. Security updates may stop as soon as 2 years after purchase: the iPhone 4S was discontinued on September 9, 2014, and the last iOS for it is 9.3.5 released on August 25, 2016.
So the iPhone 4S, which you use as an example of a lack of support, was supported for three years longer than the comparable Android.
By contrast the Galaxy Nexus support ended 3.5 years ago and is no longer representative of Google support's policy which is now longer.
so your statement that iphone gets more support than the equivalent nexus is spurious at best.
What? Double what? Microsoft doesn't require this because they don't require they have a stable driver ABI, so Microsoft can ship updates to Microsoft code without requiring that device manufacturers ship updated drivers to go with.
Either Android/Linux needs a stable driver ABI, or somehow (looking at you Google) the hardware vendors have to be convinced to release driver source.
Last weekend I installed the latest Debian on a Pentium II from 1997. What madness that I can't install the latest Android on a three year old phone?
Unfortunately I think this falls to Linus and the kernel developers.
The ARM portions of the kernel are a fucking dumpster fire of epic proportions.
Because every SoC vendor can bolt on different components, there is a truckload of one off code in the kernel to handle every variation of an SoC a vendor makes. Couple this with the fact that there are very few rules governing where and how vendors connect external devices via IO, and you have code for specific boards to ensure they work.
It's simply not maintainable. Many ARM boards ship with heavily patched kernels, which while having their source code released, will never be merged into the mainline kernel because of lack of effort by the manufacturer or simply the kludgy nature of the code offending the good senses of kernel developers.
Where Google can help is by preventing manufacturers from shipping a device with Android unless their kernel changes have been accepted to mainline Linux. This is the only way to ensure support for multiple years.
Actually, that will only help devices which have Google Play Services. Since Android is open source Chinese manufacturers can just release their own builds based off AOSP which don't include Google Play Services and then Google has absolutely no recourse.
The stagefright debacle didn't have anything to do with the kernel or Linux ABIs. libstagefight is Android's own userspace library.
Quadrooter was kind of related to ABIs in that it was inside Qualcomm's driver, but it would still have been trivial for vendors to just pop in a patched driver from Qualcomm and release a software update. They do all have systems ready for making software updates, since phones ~always get OTAs early in their lifetimes. A stable kernel ABI (so all vendors could have samed the same binary of the fixed driver) would not have made this significantly easier.
The main problem is lack of product liability cases due to lack of high profile really bad things happening (malicious worm epidemic etc). If consumers demanded (and won) their money back from phone vendors due to security incidents, diligence wrt updates would get written into contracts between operators, phone vendors, SoC providers etc and it would work.
Yes, this won't be "open-source", but it will be open enough, in that you can still read the source code, modify it, ship a phone without Google's permission, and so on.
The free for all model we have isn't working.
Specifically, by what metric are you calling it a mess? Certainly Apple devices are a little more secure depending on your threat model (except for physical security, where Apple is a leader), but Android seems pretty secure if you stick to the play store. ASLR, ART runtime, sandboxing, safetynet, good tls stack, and a solid bug bounty program have lead to an pretty safe OS imo. Web browsers on the other hand...
This highly technical work is awesome, really. Yet the sad and unrelated part is that this will not trickle down to the massive amount of Android users that won't get any security fix in sight. Yes, carriers and vendors are entirely accountable, but in a way Google is definitely at fault too and should be using all its might and weight to pressure vendors into updating, and carriers to stop fscking with tailored ROMs and having a say in whatever the phone receives as an update. This is not a technical issue but a political one, that Apple sidestepped on the vendor front thanks to vertical integration but took a hard stance on in front of carriers.
- This vulnerability affects tons of smart phones (iPhone, Nexus, Samsung S*). - The attack proceeds silently over WiFi -- you wouldn't see any indication you've been nailed. - Mitigations and protections on WiFi embedded chips are weak. - The second blog post will show how to fully commandeer the main phone processor by _hopping from the WiFi chip to the host_.
Imagine the havoc you could wreak by walking around a large city downtown, spewing out exploits to anyone who comes into WiFi range :-)
[1] https://www.theregister.co.uk/2017/02/27/google_project_zero...
> However, much more interestingly, we see that the implementation for [vendor-specific] command #4 seems relevant to our current pursuit. First, it does not require the existence of a TDLS connection in order to be processed!
An idea that immediately comes to mind is to root everyone's phones, patch the firmware to fix the bugs, and then do nothing more than perhaps leave a short yet profound message: "Thanks to a bug, you now have full control of your device. Was that a bug? You decide. Enjoy responsibly."
Even Google is guilty of this, though to a slightly lesser extent.
See: http://www.androidpolice.com/2016/06/21/google-support-site-...
So three years or 18 months past sale.
Personally I think that a phone is only end-of-life when it stops to work and that manufacturers should either offer to buy them back if they don't want to support them any longer or should be forced to provide security updates.
"Security updates guaranteed for: nn months"
or
"Security updates guaranteed until: YYYY/MM"
There should be a also scheme where companies who claim these things would have to deposit some calculated amount in some offical place.
(Btw, since so there's so much cheap crap being imported from china, I guess the most consumer-protecting approach would be to make both the reseller and producer responsible for the penalties resulting from a lack of security updates.)
Asking as I'm aware of a couple of cases with friends in the past few years. Personally had one case in which was about to go to SCC regarding software update removing some functionality and the company settled out of court and left me most happy with the settlement.
Maybe somebody else knows one, but as I stated, I have personally used this law in comparable circumstances and aware others have. But without the ability to lookup such cases on a non-paywall site then alas we have hit an enpass.
So unless you are able to link such a site then your not helping at all.
You are right, we are not helping at all with proving your unsubstantiated claim.
More evidence would be preferred, and would definitely raise my trust that there wasn't some mistake of memory, but it seems a bit extreme to dogpile on someone who is stating what they believe as fact from personal experience, and when asked for verification seems willing to try to find that but without the knowledge or ability to do so and asking for pointers on how to do that.
Also http://law.stackexchange.com/questions/940/is-there-a-prefer... kinda back's this up alas.
I'm thinking Apple may be the way to go this time, because they maintain security updates for older devices for longer. (Seems like 5+ years.)
Another way of looking at this is that lacking security updates create unnecessary electronic/chemical pollution/waste. I think the EU should tackle this. I'm sure they could come up with some scheme for penalties for lacking security updates. (Does anyone know of any initiative in this area?)
The iPhone SE has a reasonable price and is only a year old. E.g., here in Germany you can still get the 16GB version from before last month's storage bump for 399 Euro. It has the same SoC as the iPhone 6s (A9).
(I still reckon my mom needs a new phone though, there are other less severe exploits out there for this non-updated device.)
Yes, an iPhone is better, but if you're on a budget and don't have those security needs, the Moto G seems fine.
I'm sure manufactures are slow to embrace this new reality because consumers see little value in paying for it.
Consumer understanding and/or regulation needs to change in order to provoke a different response from the manufacturers.
Industries that do not self regulate tend to find that they will then be regulated by the authorities.
The phone companies used to be so anal about this that they would ban 'unlicensed' hardware from their networks to the point that you could only use their overpriced hardware. Now that has changed to the point where they will push whatever junk gives them the biggest margins at the moment of sign-up and never mind the long view.
Yet another example of a place where strict software liability would be a great thing to have.
The phone companies used to be so anal about this that they would ban 'unlicensed' hardware from their networks to the point that you could only use their overpriced hardware.
I thought that was more because it was overpriced than out of any attempt to avoid regulation. And that they were blatant enough about being anti-competitive that they got regulated for it.
This to me clearly indicates that the carriers at least have the option to ensure that the equipment connected to their network is up to certain standards. But since they don't car e (they never did) they'll be happy to sell you a phone from some manufacturer that is most likely not going to outlive the contract because of the extra margin they make on that phone.
So either they should take it back for some residual value (which they can then try to recover from the manufacturer) or they should ensure it keeps working properly.
I thought some of the fallout from that mess was that they can't impose rules beyond "doesn't break our shit".
A major recall that affects a large number of cars can create huge expenses in the aggregate. According to Toyota's Q3 conference call, they have set aside 100 billion yen (approximately $1.12 billion) for these "quality-related expenses" which will be allocated between the third and fourth quarters. (Some products were announced with great hype, only to be pulled from shelves. Find out more in A Year In Product Recalls.)[1]
I suspect that legally required recalls are viewed differently than security updated mainly because they are legally required. I wouldn't mind a consumer law requiring companies to provide at least a minimum period of security updates from the time it's officially available from the manufacturer. I also wouldn't mind if that period was longer for "appliance-like" IoT devices...
It probablt can even use the same justification. Unsafe vehicles on the road are a danger to us all, and so are unsafe devices on our networks.
1: http://www.investopedia.com/financial-edge/0210/the-cost-of-...
But not in computers. Even in the 80ies, we would buy new version of MS-DOS for our existing hardware.
The difference is that on most normal computers (except Apple), software was/is decoupled from hardware, they have different manufacturers. Software developers want to reach an as large as possible audience, so it is typically not in there interest to support only the latest hardware iteration.
I assume there are some important reasons why this wouldn't occur, but at first glance, it seems to me that the pros outweigh the cons.
I think we might need a few incidents like this.
Moreover, heap overflows and videos of batteries exploding dont have the same staying power in consumer minds...
A heap overflow won't change minds, but millions of out of pocket consumers saying how shit Samsung is at every opportunity will.
Remember Samsung is a big brand too, the department that sells TVs aren't going to sit back while the phone department poisons their brand.
I think more likely what is happening now are some execs and lawyers @ bcom HQ right now trying to figure out if they can sue Google over any of this. They likely will not, but I'm sure they'd play hardball with any small player and at minimum cease doing business with them. While I've not dealt with bcom directly myself, I can say this opinion comes from experience.
1000 times this!
...considering implementing exploit mitigations in future firmware versions. I'm somewhat doubtful that they give much shit unless it hurts their bottom line. This sounds like lip service. What else are they gonna say? "We're not considering implementing exploit mitigations"?
Can this vulnerability cause content-owners and DRM vendors to no longer allow such devices to decode 4K content? I'm thinking of for example PlayReady certification that may be withdrawn/downgraded because of this issue, but I'm fuzzy on the details how this would work.
Many apps, and especially all with DRM content, require a fully signed boot, and if the user at any point even can see what any app is doing, or MitM anything, will refuse to work.
Google has published a solution for this which uses TrustZone to create a hash of the system, transmit this to the Google servers, and Google then verifies the hash, and transmits a token to the servers of the app willing to play DRM content.
Rooting, or even unlocking your bootloader, already makes your phone useless today by design. Which makes the work of projects like Replicant harder.
I hope so, it will expose two of the biggest cancers in the industry.
Huawei has provided exactly 1 update to the phone since it was released. And only for those living in New Zealand.
Other than clearing out all the trusted wifis and just keeping the home wifi, is there anything at all that can be done?
This blog post points to 4 Project Zero bugs for different Broadcom issues.
[0] https://bugs.chromium.org/p/project-zero/issues/detail?id=10...
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Also a prime example of why manufacturers should always allow the user to update device the software on his/her device.
Broadcom's closed driver stack has gone from the Linux user's headache to a serious vulnerability in most phones.
When will vendors get it through their respective thick skulls that there is no legitimate reason or benefit to keeping their drivers proprietary?