How ironic. Yesterday on HN someone said "Google Security Team, here's your call to stop pontificating on the Project Zero blog and throwing cheap muck at Microsoft. You've got an even bigger and more complicated mess to clean up, you dug the hole yourself, it's going to take you longer, and you should have started on it years ago" [1]
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.
Google has 57,000 employees. There is always going to be some good, some bad, in an organization that size.
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.
Android is open source and has a permissive license. Fundamentally this means Google cannot prevent manufacturers like Samsung from shipping insecure phones receiving infrequent software updates. I am curious as to what you think Google "should" do? Make Android closed source like iOS and ship it as binary blobs and a license forcing manufacturers to ship sw updates exactly when Google says to do so? You think phone manufacturers would agree to that? They would promptly fork off the last open source Android and rarely take Google's subsequent updates.
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.
> 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.
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...
$500+ iPhone 5 (2012) user checking in here, currently into the 5th year of updating to the latest (most patched) OS version. I wish android had something like this.
Like I said elsewhere Apple is not always that good. If you bought the iPhone 4S on September 9, 2014 right before it was discontinued, the last iOS update it received was 9.3.5 on August 25, 2016. Just 2 years of support...
That's kind of unfair, the iPhone 4S was released on September 2011, so it was supported 5 years since release. It went through 5 (!) major releases of iOS, from 5.0 to 9.3.5.
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.
This includes a significant VAT that varies by country, so the price isn't comparable to the listed US price which excludes any applicable sales taxes. That being said, the consumer is still paying nearly $1000 USD for their device with the hidden tax.
Back when phones were mostly sold via carriers ("new phone every 2 years"), I suspect OEMs wouldn't want it because updates would almost guarantee no updates for the duration that the phone was supported by Google.
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.
Some of us tried that, right after Google's Motorola acquisition. Didn't work out so well for us. (It was the only "Google" option at the time for those of us who needed to be on Verizon for their network specifics.)
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.
In windows 10, I use procexp (from sysinternals) with totalvirus check enable.
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.
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.
I don't think that, in the grand scheme of things, anti virus programs are really helping. Once you have the machine compromised, hiding from a scan isn't terribly difficult.
What they should do is what Microsoft did - make hardware drivers independent from the OS version. I don't need Dell to recompile the NT Kernel for me every patch Tuesday.
Maybe change the license to one that requires manufacturers provide security patches for three years, except for non-profits? Entities that release only software, like a modding community, would be exempt.
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.
If Microsoft had required Dell, HP, Lenovo, Samsung, Toshiba, Acer, Asus, etc all to provide free operating system upgrades on your PC every time there was a Microsoft security hole, Windows would have been deader than dirt years ago.
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)
> If Microsoft had required Dell, HP, Lenovo, Samsung, Toshiba, Acer, Asus, etc all to provide free operating system upgrades on your PC every time there was a Microsoft security hole, Windows would have been deader than dirt years ago.
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.
> 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.
Kernel ABI is not the dominant part of the problem.
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.
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.
The Galaxy Nexus was released at the same time as the 4S, and its last supported OS was Jelly Bean (4.3). The last update for this OS, 4.3.1, was released in October 2013. It was not supported after this.
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.
Yes the Galaxy Nexus was terrible in that respect. But it doesn't change my main point which is that: Apple security updates may stop as soon as 2 years after purchase. And the last example of this was 8 months ago when 4S support ended.
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.
the galaxy nexus was a special case where shortly after it was released TI pulled out of the SoC making business all together. no other nexus suffered the same fate as that phone.
so your statement that iphone gets more support than the equivalent nexus is spurious at best.
I assume Dell, HP, Lenovo, Samsung, Toshiba, Acer, Asus, etc all have plenty of vulnerabilities in their homegrown drivers, many of which remain unpatched. Fortunately these are small enough market segments that they don't get much attention from the bad guys.
>feet to the fire on the state of Android security, since it is truly a mess
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...
I was referring to the post that the parent linked to, which criticizes Google for letting the various Android partners get away with never shipping security updates. The latest Android on a Pixel phone may have good security, but not the majority of phones out there that are way out of date.
> 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.
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.
Speaking almost entirely unrelated to the topic: Phones need to become general-purpose minicomputers, with the cellular modem "attached" as a peripheral (like over USB). As soon as we start treating them like full-blown computers the better we will get at supporting them. (the modem thing is more of a security want...)
I don't get what's ironic. Does anyone not expect that Android phones overall are going to be the slowest to be patched / have the most stay unpatched?
This is one of the most serious and instructive pieces of technical security work we're likely to see this year. In case it hasn't sunk it:
- 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 :-)
Imagine the havoc you could wreak by walking around a large city downtown, spewing out exploits to anyone who comes into WiFi range :-)
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."
That reminds me of the worm[1] that would patch the system, and then self-destruct. The problem being that it caused massive load on the servers distributing the patches, as well as restarting users computers without warning.
> 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!
Interesting seeing the Project Zero post mentions Android, not Apple. This deference to Cupertino contrasts with Project Zero's willingness to directly call out Microsoft. (Granted, at the time of this Project Zero post Apple had already released a patch. Microsoft, from my recollection, has a habit of blowing through its 90 days.)
It does mention that all iPhones since iPhone 4 are vulnerable. Historically, depending on the patch, Apple has also failed to produce a patch within the 90-day deadline.
That's going to hurt a lot of folks. Especially those whose manufacturers are not doing their bit with respect to updates. It's absolutely incredible to me how sloppy manufacturers are when it comes to keeping phones updated, they seem to see phones that are older than two years as effectively end-of-life.
Even Google is guilty of this, though to a slightly lesser extent.
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.
Manufacturers are used to developing a product and selling that product as-is. The entire idea of needing to maintain (develop, improve, update) a product beyond the point of sale is a fairly new one.
I'm sure manufactures are slow to embrace this new reality because consumers see little value in paying for it.
The entire idea of needing to maintain (develop, improve, update) a product beyond the point of sale is a fairly new one.
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.
And PC manufacturers still screw it up. If you're lucky you'll get 4 updates to a computer spread 6 months apart and delivered by a custom app that is just as likely to crash as it is to update you're system.
I don't see how your point contradicts with what they said. Selling a new version of MS DOS is not developing/improving/updating a product beyond the point of sale. It's creating a new product to sell, which non-software has been doing forever as well.
The sales price was enough to cover not just development and production, but also free long-term maintenance that the manufacturer didn't know to plan for (and possibly couldn't have known to plan for)?
But that they should have planned for. Really, it's not as if security issues are a new thing, we've been dealing with this crap for several decades now.
OP's point is that most consumers are much more sensitive to price than they are to X years of updates as a deciding factor when buying a new phone. If a manufacturer planned for a longer update timeline and hence charged more, they'd lose business to a competitor who didn't.
Consumer understanding and/or regulation needs to change in order to provoke a different response from the manufacturers.
Consumers have no clue how the cell phone ecosystem works in the first place let alone that they would be able to put a value on the security of their devices. They are going on the assumption that the manufacturers/carriers would not sell a product that is defective. Manufacturers make enough profit as it is to update their devices for the expected service life of the devices. They're just not willing to go the distance.
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.
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.
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.
Yes, so now we have this split where you can buy equipment from a whole range of manufacturers and suddenly the phone company doesn't care at all what crap gets on their networks.
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.
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.
I thought some of the fallout from that mess was that they can't impose rules beyond "doesn't break our shit".
If I had to guess, I imagine auto manufacturers allocate some amount of the sales price towards future recalls as well. A little googling seems to indicate I'm at least partially correct:
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.
My 73 year old mom is quite happy with the 2014 Moto G I got her three years ago. I guess she'll need something new now (No idea if it has a BCM wifi chipset, but I'm guessing so - how do you even find this out without having physical access to the device?).
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?)
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.)
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).
But on the other hand they're very friendly when you want to install alternative firmware (eg cyanogenmod). They let you unlock the bootloader and then you can flash at will.
The EU loves creating standardized sticker layouts. In this case I would welcome it.
"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.)
Do you have a resource in which can look up past cases, including small claims court that is not paywalled in some form?
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.
Bookmarked, alas for the UK the only public offerings are pay per search: https://www.trustonline.org.uk/ which does not seem to have Small Claims Court judgments.
That is why I asked as I'm not aware of any non-paywall sites that allow such lookups and neither it seems are you.
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.
I'm fully aware of what he asked for and as I have made clear, unless somebody can link a site that allows such lookup of past cases (including SCC) then there is nothing further I can do beyond express my personal experience, and link to the law in question (which I did).
So unless you are able to link such a site then your not helping at all.
Well, part of the claim is a personal experience, so evidence isn't strictly required, since the source is making the statement. At that point, you have to determine how well you trust the source.
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.
This research is effectively a free audit of Broadcom's firmware by Google. At what point does Broadcom approach Google, have the appropriate NDAs signed, and give them access to the source code? If someone is providing a (very valuable) free service to you, wouldn't you want to make their lives easier?
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.
Yeah... having worked in actual large secretive companies like Broadcom they're more likely thinking "Shiiit they found a security vulnerability using information from the datasheet, a memory-probing utility we provided and some of our open source code. We've got to make all of those secret!"
Which is so silly, as closing their code & datasheets just makes it harder to work with their chips and makes users of their products less secure. And that is why you see all these Single Board Computers not using Broadcom chips, they are nearly impossible to get docs for, let alone decent drivers.
I suspect every time something like this happens, Google gets a little more access into the stack of the various tech used in stuff it sells/runs from third parties. Broadcom of yesterday may never have handed the code over, Broadcom of today would probably send it over with a case of champagne and a stack of hardware to test with.
While I'm risking jumping in on the "me too" bandwagon - I don't think this is how it works. Perhaps Google is large enough for Broadcom to cop a different attitude with, but nothing about large hardware vendors makes me believe they think like you say.
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.
Why would Broadcom sue a large customer like Google? Check out what chips are in the motherboard picture in Wired's article from a few years ago about the Pluto switch.
At the same time, it potentially makes it more likely they'll find more bugs, and all Project Zero bugs are publicly disclosed, which is bad from a marketing point-of-view for Broadcom.
No, it would be a positive: after sending project 0 our source code and fixing everything they've found in the first 6 months they failed to find anything for the last 6 months. Compare to our competitors who are still subject to such finds roughly once per 2 month period.
I think you're assuming a somewhat redeemable codebase. For most I'd be guessing it's a choice between completely rewriting the drivers or a never ending game of wack-a-mole. Management will see both options as costing a lot and delivering zero value.
When has Broadcom ever given a sign that they care about their reputation among end users? They want the OEM design wins, and anything after that is not their problem.
It's not hard to imagine how this might be bad in an alternate universe. But i still dont see how it is going to matter in this universe where Bob doesn't stop shopping at Target or DSW after a big breach and where Alice does not research WiFi chip security history when she goes to buy a toss away IoT device.
They do know they're spending a lot of money on a shiny new samsung s8 and if it's bricked a month after use it's either going to cost samsung a lot in replacements or the person is unlikely to buy a samsung phone again. Just look at the damage the battery disaster had on samsungs brand, that was only a small percentage of phones with a problem.
Alice is going to revolt against Samsung when her s8 is bricked and go buy the new iPhone which also has a Broadcomm chip in it? How is this causing problems for Broadcomm's marketing department? When she goes to the store and explains how frustrated she is with Broadcomm surely the phone rep will point out that some phone makers were good about pushing out the update?
Moreover, heap overflows and videos of batteries exploding dont have the same staying power in consumer minds...
It causes a problem for Broadcomm because Samsung is losing sales and has to use a competitors chipsets. Or Samsung fixes their update issues to try and claw back sales. Or more likely Samsung do it because replacement units are expensive.
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.
> Broadcom have informed me that newer versions of the SoC utilise the MPU, along with several additional hardware security mechanisms. This is an interesting development and a step in the right direction. They are also considering implementing exploit mitigations in future firmware versions.
...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"?
Whoa! This is really impressive stuff, and will cause head-ache in my dayjob where we develop a product using this WiFi SoC.
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.
>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.
I hope so, it will expose two of the biggest cancers in the industry.
How do these certifications deal with e.g. rooted devices (rooted by the device owner, not an attacker)? One suspects that there's not much they can do? If that's the case, why would they worry about this vuln?
Those devices already can’t play DRM content. Or use Android Pay. Or use Snapchat.
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.
Project Zero are seriously doing good work here. This attack can passively own a large portion of all modern smartphones if unpatched against these vulns.
For reference, here is the bug[0] that affected Apple that was discussed yesterday[1]. One commenter on that HN topic noticed that there was 1 other public bug about Broadcom wifi chips, though it was not the specific one that affected Apple.
This blog post points to 4 Project Zero bugs for different Broadcom issues.
There's a bug in Apple's EFI driver for BCM4331 cards present on a lot of older Macs which keeps the card enabled even after handing over control to the OS. A patch went into Linux 4.7 to reset the card in an early quirk, but I suspect other OSes can be taken over via WiFi on the affected machines:
Java please. There's absolutely no way that can run on the kind of microcontroller we're talking about. Did you read the part about having 300 bytes spare?!
I think you are reading too much into the ROM containing "less than 300 unused bytes". It's probably not a coincidence that it just happened to fit in the possible space so snugly!
Anyway, there are commercial Java supporting microcontrollers with smaller hardware (memory & cpu power) than this ARM microcontroller. Eg. MicroEJ.
Am I? Did you read the bit about how they reclaim memory used for initialisation and convert it to heap space? How is that going to work with Java?!
I tried to find information about MicroEJ but their website doesn't really tell you anything. I assume it supports something like Java Card rather than actual Java.
These kind of space restrictions have forces from 2 sides that meet in the middle: (1) sizing the space, for cost reasons (2) spending engineering effort on space usage.
768 kB of RAM (on top of the ROM holding program data) holds a lot of state. There exist TCP/IP stacks and JS interpreters with RAM requirements of 2 kB, ~3 orders of magnitude less.
About jettisoning init code and data, I don't know specifics here but Java the language supports heap space recycling and code (class) unloading very well.
Are there really commercial BASIC and Oberon compilers targeting ARM microcontrollers? It seems the world is a much richer place then I have ever imagined :)
seL4 is written in C and is formally proven correct. If you aren't down doing that kind of extensive work (and nobody using Linux, AFAIK, is), C makes me really, really nervous and should make you really, really nervous too.
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.
[1] https://news.ycombinator.com/item?id=14023969