Security Holes In Google's Android SDK

Redon Buckeye writes "Google's Android software development kit is using several outdated and vulnerable open-source image processing libraries, some of which can be exploited to take complete control of mobile devices running the Android platform. From the article: 'Several vulnerabilities have been found in Android's core libraries for processing graphic content in some of the most used image formats (PNG, GIF, and BMP). While some of these vulnerabilities stem from the use of outdated and vulnerable open source image-processing libraries, other were introduced by native Android code that uses them or that implements new functionality.'"

Comments

I'm not exactly sure how phone software works...

[ZanySpyDude]

If this had been in the final version that was released, is it an easy fix for google or is it a pain in the ass for end consumers to get a fix/upgrade from google?

Re:Re-using, Re-using, Not re-inventing the wheel,

[AKAImBatman]

Unless you reimplement it in Java. Which Android happens to run. (For the most part, anyway.)

While it's neither here nor there in relation to this story (and wouldn't perform very well, anyway), I just thought it was an interesting observation. Perhaps one day developers will stop looking at Java as a nice sandbox environment for tiny applications and start realizing that there are real benefits to deploying a high-performance JVM. Especially when HotSpot has already been ported to mobile devices...

Re:I'm not exactly sure how phone software works..

[Firehed]

Look how the iPhone handles firmware updates - plug in, download, click install. I think it's safe to assume that a Google-supported device is going to be rather heavily standards-based (I can't say I know much about Android), and as such will have a mini-USB port. Why overcomplicate things? As much as I like the idea of having my Google-centric data accessible everywhere over the air, they really need better interoperability in terms of desktop data syncing (Gmail is pretty good that way, but Gcal requires third-party tools, docs - understandably so - is limited to exporting rather than just mounting your Google account as a network drive, and contact management is pretty much worthless as it exists online, let alone syncing to Outlook or Address Book). As such, it's safe to assume that people are going to want to be able to pull that non-syncable data from their computer to their phone which means plugging in or at least WiFi proximity. Handle firmware updates that way. I'd say it's almost easier to infect a computer with a bad HOSTS file pointing androidupdates.google.com to some bad addressed with an apparently-legitimate SSL cert than to carry around a portable cell broadcasting station, but neither constitutes that much of a threat.

that's why it's open source

[nguy]

That's why people make software open source.

I think the only thing that bothers me about Android is that the full source code has not been released yet, although Google claims they will be making that available.

Re:Re-using, Re-using, Not re-inventing the wheel,

[AKAImBatman]

Several of the vulnerabilities in libPNG are exploitable integer overflow vulnerabilities. Java does absolutely nothing to stop those vulnerabilities.

Bull. Java will overflow the integer, but how exactly will it result in an underflow or an overflow of a memory buffer if Java does not have pointers? All you have is a negative value. At best you'll cause an IndexArrayOutOfBoundsException when you attempt to access an invalid array location. At worst, the code will detect it as an invalid value and move on.

And even if it does, much of the java runtime is written in C, and is just as vulnerable to buffer overflows.

Oh noes! Not C! That must make it, like, automagically vunlnerables!

Yeah.

The JVM is a design that is logically proven to be 100% absolutely secure. If Java code can reach down and manipulate memory at the level of the JVM, then there is a serious flaw in the JVM's implementation. A flaw that means that it does NOT meet the Java spec. Thankfully, Sun has a Test Kit that checks for compliance before a VM can be called "Java". It does a pretty decent job of ensuring the correctness of a VM.

People should stop thinking that somehow interpreted languages (Java, .Net, VB6, etc) are solutions to security problems. All they do is to raise the bar.

Raising the bar is exactly what I'm talking about. Java is impervious to buffer overflows because it does NOT allow for memory management. Memory management is the responsibility of the JVM.

Oh, and Java is not interpreted. Strike 3, you're out.