Samsung To Push Monthly Over-the-Air Security Updates For Android

wiredmikey writes: Smartphone maker Samsung said on Wednesday that it soon will implement a new Android security update process that fast tracks mobile security patches over the air when security vulnerabilities are uncovered. The South Korea-based maker of popular Android smartphones said that it recently fast tracked security updates to its Galaxy devices in response to the recent Android "Stagefright" vulnerabilities uncovered late last month by security firm Zimperium. News of the initiative is great for Android users. For years, wireless carriers and phone manufacturers have been accused of putting profits over protection and dragging their feet on regular operating system updates, making Android users vulnerable to malware and other attacks. Nexus is also joining the monthly OTA update club.

Comments

I'll believe it when I get the notification.

[Sowelu]

Promises, promises, promises...

Re:I'll believe it when I get the notification.

[Anonymous Coward]

Microsoft Windows 10 comes with spyware, ads and automatic updates built in, none of which can be disabled.

Which means the Year of the Linux Desktop is right around the corner!

Re:I'll believe it when I get the notification.

[antdude]

Basically, prove it!

But what about profits?

[ausekilis]

I'm curious how they'll "encourage" users to upgrade to the latest shiny if the slightly tarnished shiny is still up-to-date...

Re:But what about profits?

[0123456]

I'm curious how they'll "encourage" users to upgrade to the latest shiny if the slightly tarnished shiny is still up-to-date...

Android's hardware requirements grow more than fast enough to encourage users to upgrade every couple of years.

Re:But what about profits?

[Sowelu]

Google's app upgrades are a minefield at best and a disaster at worst. Chrome seems to get slower every update (typing a website now hangs for a couple seconds after the first letter while it populates the history, and sometimes before you start typing at all, and loses letters typed during the pauses), plus the interface changes at random (pulling down at the top of a page reloads it now, which works great with websites that want you to swipe to control them). Chat->Hangouts drops a lot of information about contact status. Maps, similar issues to their web version.

Re:But what about profits?

[darkain]

It is as simple as this: "We push security updates more often than our competitors" - it isn't just about retaining market share, it is about acquiring it from competitors. This is a highly requested feature from users that handset makers and carriers have been fucking up for years. So if a company delivers on this, it could very well easily be the tipping point between otherwise seemingly similar devices on the market - especially in the enterprise/government sector.

updates, updates, ...

[hjf]

Does anyone remember the time when software just WORKED? When you didn't have an update of something every single day? What is it with phone users? I know everyone seems to want the latest and greatest. But DOZENS of app updates a week is just boring. And when the phone is updating you can barely use it.
I thought the future was going to be full of ads. It seems the future, actually, is just full of updates...

Re:updates, updates, ...

[krelvin]

If an app is built for just that phone then you have a point, but they aren't. They are built for many phones, different versions of Android and as such there is a constant update process to fix issues with the app working on one thing or the next. What phone are you using that makes it so you can barely use it when it is getting an update? Perhaps you have too many apps?

Re:updates, updates, ...

[ledow]

Has software ever "just worked"?

I can name bugs in 30+ year old software that made it into a production release and could never be patched because of the capabilities at the time.

And that was when the "app" was the only thing running on a single processor with complete "kernel" access to the entire machine, so not at all complicated by filesystems, process interactions, security mechanisms, etc. The days when software COULD take advantage of the timing of a particular processor, and even things like undocumented opcodes.

Software is an inherently "unfinishable" product. Just as everything works, something will break somewhere - you get your app going in DOS and then all your clients move to Windows, you get it working on Windows, and then all the Windows versions move to NT-based kernels and the like. It's a never-ending game.

And, with security particularly, there is no point at which you can call the software finished. There isn't a piece of software in existence that is "unbroken" on a general purpose modern machine - even those released dozens of years ago. Nobody was considering timing-based memory cache attacks back then.

Software that stays static is THE WORST culprit of exactly this kind of shit - unfixed bugs that propagate and hang around for years undiscovered until they become much more serious and affect devices that can no longer be commercially-viable to update.

Software is not static, and mainly because our expectations, operating systems and even hardware aren't static either.

You think Word 2.0 for DOS is somehow magically "secure" or better programmed than modern stuff made with optimising compilers that warn about everything and do proper memory separation?

Re:updates, updates, ...

[0123456]

Has software ever "just worked"?

Somewhat. My Sun workstation ran for years with no software updates. It had bugs, but nothing that required a new operating system or application software.

The big difference was that it was behind a firewall and a 19.2k modem, so there wasn't much anyone could do to attack the--probably numerous--security holes.

Re:updates, updates, ...

[Grishnakh]

Does anyone remember the time when software just WORKED?

I remember those days well. It was just like yesterday.

However, back in those days, our computers ran MS-DOS, and weren't connected to the internet. For the few people who did have internet access (mainly college students), they usually didn't have their own computer hooked up to the internet, they shared some VAX or Unix machine, and mainly used it just for email, USENET, and maybe exchanging files via FTP. Some people used Gopher, though I don't remember what for. Since so few people used networked computers, hacking wasn't much of a problem, and was mostly an activity done by bored college students to see if they could.

Also, I do remember some updates back then, mainly to DOS games. Even back then, the games were buggy, but not too much. I remember some of them using some kind of utility (was it called "Patch"?) to update their software, so the updates could be distributed on BBSs. This software actually worked quite well: it only contained the parts that had changed, and the utility would actually modify the binaries on-disk as necessary. I haven't seen anything like it since, which is a shame since we do so many updates these days. For some strange reason, all our updates now involve distributing a bundle that includes all the changed files (rather than just the changed part of a file), so the update bundle is much larger than it needs to be. If some pathetically slow circa-1992 DOS machine could handle modifying binaries on-disk, why can't modern machines? It would save a huge amoung of bandwidth.

Re:updates, updates, ...

[SleepyHappyDoc]

No, nobody remembers that time. I remember when Windows couldn't run more than a few days without crashing. I remember when getting a program to work required arcane knowledge and steps bordering on voodoo. I remember when getting a wireless card working on Linux was the realm of super hackers. I remember Sasser.

Re:updates, updates, ...

[ledow]

And I bet even that firewall and modem had bugs that exposed more of an attack surface than you ever wanted it to.

Systems don't "stop running" without updates. They stop being secure. And now that systems are all online, all the time, it's more important to be secure than almost anything else.

Re:updates, updates, ...

[0123456]

No, nobody remembers that time. I remember when Windows couldn't run more than a few days without crashing.

That's what you get for buying cheap crap. In that same era, the first time I rebooted my Sun was for a CPU upgrade... but it cost at least 5x as much as a Windows PC.

Re:updates, updates, ...

[Anonymous Coward]

The big difference was that it was behind a firewall and a 19.2k modem

ping -c 3 -p "+++ATH0"

Many haynes clone command sets (and even a couple bugged haynes firmwares) did not require the 300ms pause between the +++ "I want to send a command" pattern, and the actual command to the modem. You just had to get the remote system to reply with that command pattern to disconnect.

The best was against email servers. Send an email you know will bounce with a +++ATH0H1DT1900xxxyyyy number under your control and the bounced emails will make the modem hang up and call your toll number over and over, until an admin manually cleared it from the mail queue.

Re:updates, updates, ...

[swillden]

They stop being secure.

They were never secure

Is a system with no security defects known by anyone secure?

This might appear to be a philosophical maundering like "If a tree falls and no one is around to hear it, does it make a sound?", but it's not. It's a very serious question, with real implications... and the answer is yes.

Consider FakeID, a serious vulnerability in the Android app signing infrastructure that basically allowed any app to be claim to be from any provider -- including claiming to be signed by the OEM, to obtain system privileges. The bug was introduced in 2.2.1 in 2010 and existed in all versions of Android until 2014.

But no one knew.

Once the flaw was revealed Google was easily able to go back and examine the certificates of all apps uploaded to Google Play during the entire period of time between when the vulnerability was introduced and when it was fixed. Google also examine the contents of other app stores, and non-store app repositories. There wasn't a single instance of an app with a faked certificate chain, anywhere, until the public disclosure of the bug. Snowden's documents gave no hint that the NSA knew of it. Hacking team's archives had no hint of it. If anyone, anywhere, knew of the bug they were incredibly circumspect and careful with their usage. The more reasonable conclusion is that no one knew.

During those four years, all Android devices were vulnerable to this serious security hole, but none of them were exploited. So, the Android app signing architecture was effectively secure even while it was technically broken.

And as I said above, this is not just a semantic quibble. If your definition of "secure" (under some defined threat model) assumes that the system must have no security defects, then no system of any complexity ever has been or ever will be secure. Security is only meaningful within a defined context, and that context includes the knowledge of the adversaries. Of course, we can never know what the attackers do or do not know, but we can reasonably suppose that if they don't use a devastatingly effective attack it's because they don't know about it. This means that systems actually do get less secure over time, unless they're maintained.

(Note, BTW, that the mere existence of a known security defect also doesn't necessarily make the system insecure. That also depends on threat model and on whatever other mitigations may be in place. For example, take the libstagefright bug. 90% of Android devices in the world are running Ice Cream Sandwich or higher, and have ASLR enabled in their kernels which makes a bug like the one in libstagefright very hard to exploit.)

Hopefully, they'll be able to bypass the carriers

[glsunder]

Samsung can make all of the updates they want, but if Verizon and other companies just sit on them, it won't do us much good.

Re:device not eligible

[Frobnicator]

The devices I can see were launched within the past two years. Looking a few of them up, the oldest I see was launched November 2012 and discontinued November 2014. In my view these should all be getting standard support anyway. We're not talking about an announcement to patch phones from 2007 or 2010.

Supporting a two-year-old product SHOULD be non-news, the true problem (sadly) is that it has become such.

SwiftKey?

[dwheeler]

What about the disastrous SwiftKey vulnerability? It makes Samsung Android systems vulnerable too. Samsung said they'd fix it back in June, but we still have no patch.

When buying an Android phone: Measure how many days it takes from the vulnerability report (at least publicly) until it's patched in phones already used by customers. Focus on phones more than 2 years old, since your phone will be that age someday. Then: Don't buy from unresponsive makers. I suspect that if a few buying guides included those numbers, some manufacturers and service providers would start paying attention.

Re:Hopefully, they'll be able to bypass the carrie

[idontgno]

Came here to say this.

The problem has never really been Android's willingness to correct and publish security-related patches; the problem is that the carriers control OTA and therefore limit OTA update support for phones that are fairly new. According to the carrier, if you want a secure phone, you'll just have to buy a new one from them.

This is a new update mechanism

[Forever Wondering]

This is a new update mechanism for security updates [and bug fixes, hopefully] for the device firmware (e.g. kernel) that makes it less painful for phone vendors and carriers to implement.

A few things to note [most of this is conjecture on my part, as software engineer, until the details emerge]:

- Android source code (e.g. kernel, dalvik, etc.) is maintained via git (with a Google wrapper program called "repo"). I regularly update a source tree via this.

- git has extremely powerful branching and merging capabilities. Thus, it's very easy to create a fix in one version and get git to apply the resulting patch/delta to other branches of the tree. That is git's forte. For example, do the security fix in the latest under development branch and then propagate it to all older branches [can be automated easily].

- Because you're just changing a small portion [we hope that the bug fix is only a hundred lines of code or so], the patch can easily be applied.

- Because the change is relatively small (e.g. 4.4.2 to 4.4.2.1) vs. going from 4.4.x to 5.0.0, it's far less QA testing as the old rev has been extensively QA'ed as a whole.

- This will encourage vendors/carriers to adopt this, even for old phones, because it's just a bug fix and not feature creep that might require more powerful hardware.

- This mechanism won't cut into margins because it is [will be] an automated way to apply just security updates (e.g. [gasp] Windows update). This could still have been done in the past, but it wasn't as easy [as Google seems to want to make it].

- Vendors/carriers will still be able to "up sell" to the latest and greatest for new features. So, no conflict/disincentive.

- Vendors/carriers will be encouraged because it's now easy to do, everybody will be doing it, and [a serious] black eye for any vendor/carrier that doesn't [far more so than in the past].

- And the legal liability for Google, vendors, and carriers for the MMS vulnerability is so severe, that any company that does not implement this could be sued into oblivion. For example, in the PC world, would any motherboard vendor decide they would prohibit critical security bug fixes via Windows update?