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.'"

yawn

Security holes in beta software you say? Wow.

Re:yawn

Security holes in beta software you say? Wow.

That would be a valid retort if it weren't for Google's perpetual beta mentality.

Re:

This is why they have a perpetual beta mentality. They know better then to call newly written software done. Public usage with a warning label is a good thing.

Re:yawn

They know better then to call newly written software done.

So three and a half years is early in the development process? I guess that means Hurd's only 'slightly behind schedule'.
Really, in the hands of Google, the 'beta' tag is only a way to keep things sounding 'hip and new' and to avoid liability when something screws up.

Re:yawn

Did you hear what the plans are for android? It's an OS that is designed to fit nearly any phone hardware, to be configurable to anyones liking, AND can run home brewed Java apps. Four years is not a bad time, It is a MASSIVE undertaking. Personally I think that ALL software is severely under tested. It tends to be pushed out the door not because it's ready but because the higher ups want to start making money on it. How many times did you use software that is 'done' but swamped with bugs? That is beta software, even if they don't admit it.

Re:

| Security holes in beta software you say? Wow. Maybe this is why they kept gmail in beta till now. Perfect excuse for security holes

Re:

Except that Google's software is always in beta.

Re:

He was referring to Android, not the libraries. :-/

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

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:I'm not exactly sure how phone software works..

It would probably be a bit painful. Many cell phones require you to hook up a transfer cable to install a new set of firmware. Of course, this is a fancy new smartphone OS, so it's possible that Google has devised a software update procedure. However, if t

Re:

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

Who The Hell Is Still Using BMP?

Several vulnerabilities have been found in Android's core libraries for processing graphic content in some of the most used image formats (PNG, GIF an BMP)

Having had the ignominious privilege of writing a BMP image parser some years ago, I can state without fear of meaningful contradiction that it's one of the worst image file formats ever devised by creatures claiming to be Man, and that it needs to die die die!

PNG does everything BMP does, and does it better. Just throw away the BMP library and save yourself the maintenance headache. No one will miss it.

Schwab

Re:Who The Hell Is Still Using BMP?

But then we couldn't have fun watching images load from the bottom up! It looks so cool and is totally worth a few extra (mega)bytes!

Re:

It's a fantastic way to learn how to parse and render an image. You get all the basics, plus you get to try and find out why your texture is rendering upside down :-)

Already fixed

This is already fixed [blogspot.com] in m5-rc15 which was released yesterday...

Re:

well, unfortunately the source for Android isn't out yet...so Hoorah for them when they release the source!!

Oh noes!

My new smartphone is vulnerable to malicious haxx0rz! Oh wait, it runs Windows Mobile! I'm *so* relieved!!

that's why it's open source

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,

Re-implement it and you'll likely have the exact same problems as this.. or worse.

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

Re-implement it and you'll likely have the exact same problems as this.. or worse.

Specifically, the 'worse' problem you'll have is compatibility with broken implementations and corrupted data.

I've heard it said, as an example, that only 20% of the code in Gecko is to implement a reliable, standards-compliant rendering engine, and the other 80% is to implement workarounds for (sometimes horribly) broken HTML, and recover from what should rightfully be critical errors. I'm not sure if this statistic is accurate (or, if it was when I heard it, if it still is now); however, at a previous position, our (large-scale) software product, developed over the course of the last decade, large, complex, and convoluted, had a similar statistic. Over 80% of the code that we had in our core product was there to deal with bugs in previous code, bugs in other people's products, bugs in how different vendors implemented the standards (i.e. poorly), bugs with corrupted images, and so on.

Think about that for a second; anyone can re-implement a PNG library by reading the specifications and learning how to do the math on the algorithms; there are probably people at Google who could write a complete PNG library in C inside of a week (they DO have some pretty brilliant people working for them). What they CAN'T do is go out and feed into that library all of the broken, corrupted, or just-a-little-bit-off PNG images that are out there on the web that require little tweaks and adjustments (or horrific workarounds) to process, and find all the fixes to all the glitches that end-users might see.

The extensive experience that the libpng developers have had over the lifetime of the project cannot be simply re-implemented from a textbook. THAT is why simply re-writing it is impractical, and THAT is why code re-use is a good thing. Expand that from PNG images out to every other shared library in the project, and 'not invented here' syndrome turns simple and straightforward bllet-point requirements for Android into a large-scale programming project, and makes the whole thing impractical.

Re:

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

Re:

And someday people will stop thinking of Java as a panacea for security issues.

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

For this type of problem? You bet your horse it is. Buffer overflow problems are so 1970's. Can we please move on?

Re:

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 m

Re:

I can't wait until telemarketers start using exploits to take over mobile phones to make mass calls. I can see the phone bills now...