Years Old Bug...
...Patched long ago, but not in all Androids. Fine attention to detail there...
Google is warning owners of some popular Android devices to keep a close eye on their gear following the release of an exploit for an unpatched flaw. A post from the Chocolate Factory's in-house Project Zero crew outlines the flaw, a use-after-free bug in the Android Binder driver that could be exploited by a local app to …
"Not all" meaning the "vast majority", yes. Including Google's own Pixel phones. Google link states "Pixel 1 and Pixel 2 phones will be receiving updates" for this issue as part of the October update. Nice that they are updating them, but why did they wait so long if this was, as you claim, "patched long ago"?
They list some of the phones that are vulnerable, and then in a "statement from Android" below state Pixel 3 and 3a phones are not vulnerable. So basically they list a bunch of non-Google phones that are vulnerable, a couple Google phones that are vulnerable and getting patches this month, and a couple Pixels that aren't vulnerable.
Google Zero seems recently to be used for Google's own marketing purposes to tear down their competition. First Apple, now numerous non-Google Android OEMs. They could mention some other Android phones that aren't vulnerable (I'm guessing Galaxy S10 for example since they only list Galaxy S7/8/9 as vulnerable) but they don't. Hmmm...
...Patched long ago, but not in all Androids. Fine attention to detail there...
Yes, quite. I presume there is a list, somewhere, of devices and kernel versions that are patched, and those that are not? If so, the article could do with a link to it.
If I have kernel 3.18.115 from Motorola, built on 2019-08-26 am I safe? How can I tell?
It’s a regression. The bug was patched. Then they reintroduced it. It can happen, but it’s sloppy.
Also, lol at a 0-day being dropped for Android. Not good for end users sadly, but hopefully it might give PZ some pause for thought re: their politically driven disclosure policy.
Android... keep their systems update....oh how i laughed at that one.
If you have a one year old device, as in in it was released a year ago and not bought in the last year (Lenovo looking at you still selling Marshmallow devices), you have a 50-50 chance of getting an update if your OEM and network provider deigns to bother.
Yes this is the shitty Android designed to destroy Microsoft, rather than designed to be secure and updated from source forever reality coming home to roost.
Option One Microsoft all updates available for all devices from day one, yes it might break some stuff but it is there.
Option Two Android, maybe you will may be you won't, who knows or cares, but as long as you keep giving us your data and internet history we don't care about anything else, but we will make sure everyone else looks bad and spend millions doing it with Google Project Zero.
It's not like you can't make an OS secure and keep it so, while allowing it to run on multiple platforms. Just learn from the errors of Microsoft. The problem is clearly elsewhere.
Android update availability is clearly only for marketing purposes. Think of it, new vulnerabilities help people decide to buy a new phone/tablet/whatever, and that's good for those who sell Android gadgets.
Phones are meant to be consumables, to use & throw away, any effort to make them last more than 6 months is wasted money. Glued batteries, quick & dirty software, everything points to the fact that you're supposed to bin it as soon as the next version hits the stores. Any fixes will be implemented in the new version, but obviously not back ported to what is now supposed to be landfill. That would be counter-productive (to put it mildly): People don't change their gadgets often enough, so phone makers need all incentives (legally available) to make people buy an new phone every year.
The Pixel 1 that I bought (off eBay, used) is being updated (and has already been updated to Android 10). It's well neigh 3 years old at this point. The battery may eventually be an issue (it's ok so far), but much of the cause of glued batteries is the (silly) demand for thinner phones. Obviously none of the phone makers (or carriers selling "free" locked-in phones) give a crap, updates are just an annoying extra expense. Google does have a vested interest in their own brand, though.
"NSO did not sell and will never sell exploits or vulnerabilities,"
But we do lease them for a fee to anyone with the right amount of money.
"This exploit has nothing to do with NSO; our work is focused on the development of products designed to help licensed intelligence and law enforcement agencies save lives."
Just not the lives of investigative journalists, protesters or dissidents or anyone that might disagree with the policies of the governments of said "intelligence and law enforcement agencies"
"do not download any apps from untrusted sources"
What, such as the Google Play Store which has repeatedly been found to be hosting malware and other dodgy apps:
Sorry, my browser didn’t render your comment properly so I missed the bit where you pointed to the slew of malware on Apple’s App Store...
Oh wait, no, you tries the “well so’s your face” argument. The App Store has many flaws (like needing to buy overpriced Apple gear to write and test apps) but malware is very much a Google problem.
The funny part is that Google couldn’t fix it if they wanted to. Deleting 40% of the crapps on Play Store would look bad, and even with Google image > security.
They're all the same... even with Apple's strict policies it's still possible.
I monitor what my kids download on their devices, and they get the following drummed into them:
1 - Check reviews - not just the star rating, but also the number of reviews and what the reviewer names look like (are they spoofed)
2 - Do you actually need another app?
3 - Free games aren't free - if there's a paid for version, request it via the family account and we'll buy the thing.
4 - Keep on the house wifi (we use pi-hole and a few other things on the network to block stuff)
5 - If you need accounts, use the family 1pass account to generate good passwords!
They won't be 100% safe, but hopefully they'll be less likely to get caught out.
Nobody said there was a good alternative. Sometimes, we can say that "X is bad" without saying "We have a good alternative to X, and X is bad so you should use our alternative". In fact, we're often more vocal about it when there isn't a good alternative, because it's not easy to abandon the bad thing.
As for actual alternatives, FDroid is probably the best in that it doesn't have a bunch of malware on it. It also doesn't have many apps that the standard non-reg-reading user wants, because they want things from corporates who in turn don't want to open source their stuff. The Apple app store may have a bunch of problems around monopolistic practices, but they are at least much better at keeping out malware. Of course, that locks you in to using an Apple device, and those are getting far too expensive, so that's an option of tradeoffs. Another alternative is that Google get their act together and fix their store. Oh, sorry, I seem to have accidentally pasted in a line from this science fiction story I was writing.
Because the fact that the thing's a sieve gives them the opportunity to have accidentally gathered data for testing purposes; whereas designing the system with security in mind is not only more expensive in the first instance ("prohibitively so, a Canutian endeavour," they will say) it also raises the question of how the data they accidentally gathered for testing purposes was exfiltrated in the first place.
Most ordinary users look for, in order of importance;
1) fashion ( some people think all phones are iPhones)
2) the usual apps
(Those two killed off the winphone)
3) a wonderful camera that they don't much need
4) ease of use, including paying for stuff with it etc.
and finally err, actually, nothing else. Not security. Not repairability . Not longevity, nothing.
that I do not do things like on-line banking via my mobile 'phone.
I take the attitude that these things are broken and insecure - so I do not do anything which might in any way expose passwords. So: I use it as a 'phone, send/get text messages, modem for my laptop & tiny amount of web browsing. Most of the time Internet access is switched off.
I don't know about you, but I haven't found a feature-phone with a qwerty keyboard. As long as my family prefers SMS to voice, a qwerty keyboard will be a compelling reason to go with a smartphone.
Once in a while I use other smartphone features, particularly GPS and an ebook viewer. I could live without those, though. (And, really, I could live without a qwerty keyboard, but it's a big convenience.)
Then why bother with a smart phone at all?
It's getting harder and harder to find decent "feature phones". And I've been using mine more as a replacement for the much-missed PalmOS/pda. I run as much as possible by way of USB or by temporarily pulling out the microSD card.
What would be nice is to devise a superset of the old PalmOS transfer protocol, and make it so you could sync everything to/from desktop applications on your computer. Would probably require an AOSP-based solution, to prevent Google's filthy fingers from mucking up or blocking the process.
I recall reading about a vulnerability in iOS 12.4 a couple of weeks ago (jailbreak/rooting vuln) which came about due to regression (patch code introduced in 12.3 was inadvertently removed). Two occurrences is hardly a trend, I get that, but I would be curious to see if a trend develops from this...
Main thing I am focused on here is regression = LPE to root / other privileged account vulnerability, with POC / Exploit available soon after, if not before, disclosure. I would be curious to see how often this happens, and if it's purely coincidence that the regressions have resulted in very similar weaknesses being introduced or exposed.
I don't think a CWE entry exists for Security Regressions; maybe one should be created so we can track this sort of stuff (or if one exists and someone knows of it, please correct me).
Biting the hand that feeds IT © 1998–2019