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.'"
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.
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.
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.
Except this isn't even beta. I disagree with the assumption that security holes in beta software aren't serious. Beta -- in software at least -- means that real live users are using it.
However, at this point the software is not available to users; if the problem is that the system uses obsolete implementations for some of its APIs, the open source process has worked the way its supposed to. If the problem is inherent in some important APIs, that's a different kettle of fish.
And google mail has been 'beta' for how long? I'm sure nobody will mind a few security holes there, since it's a beta and all. This article isn't a problem as long as they sort it out quickly, but if they do a Microsoft and leave it in for the next few versions, that's when there's a problem.
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?
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 they have designed an update procedure, what's to stop attackers from attacking the update procedure? (Methinks that an unauthorized GSM base station is all that's needed for a man-in-the-middle attack...)
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 requi
who cares? there are exactly zero phones running android in public (meaning outside of pros testing)...so how does this affect anyone? must be a slow news night
It is true that the issue would not currently matter but smart phone technology will soon be big. Very big. It remains to be seen if Google can successfully make the transition into this area with so much competition from names like Apple, Research In Motion, Nokia, Palm and who knows who else by the time Android goes public. IMHO Google has done a fairly good job in its software development (which is to say, I have personally had few issues). Being open source at least lets people know there is a problem. T
And being open source these problems will be sorted out sooner and more effectively.
The exciting thing to me is that this Google project will introduce not only open source software, but open source thinking and open source culture to the masses.
And knowing Google, it will be successful, and being successful it will clear up many of the uninformed stigmas that cling to open source software - hopefully beginning with the kind of FUD that MS spouts.
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.
Sometimes you just don't want your data to be compressed; you want to be able to tell the OS to load the data from storage and have it right there, ready for you to use. Sometimes you just can't afford the overhead of decompression. But PNG, reasonably enough (I suppose) for network graphics, requires all images to be compressed; you can't say "no compression".(*) BMP, on the other hand, is uncompressed by default; aside from the line order problems (which are easily solved by pre-flipping the image), th
Not being able to afford the overhead of compression is a pretty rare case. Often you can get around it by pre loading the image. Not saying that an uncompressed format would never be useful but it without a doubt a rare case and not one I can imagine comming up on Android. But heck if you must use an uncompress format then just us IFF and be done with it:)
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:-)
That's just dumb. Introducing vulnerabilities in newly developed software is unfortunate, but it happens. Using software with known vulnerabilities when these vulnerabilities have been patched is just dumb. Any clues as to why they did this?
anybody who read the bugtraq submission of the flaws would no that google themselves responded with a comment that they knew they were using old version of the libraries adn that they were planning on updating them in the next release. They also pointed out that this iss not BETA code, but merely a release of propsed code to allow potential devlopers to add their insights to the project on which direction the code should go on various portions.
The libraries have now been replaced (evidently) with the newer o
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-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.
That's why it would be good if many people would re-implement these libs directly from the specs. That would weed out incompatible files. That's one of the points of open architectures that content specifications not be tied to implementation.
No, that would greatly increase the number of incompatible files as all those new implementations created fresh bugs and variations on ambiguous parts of the spec.
The Web Developer plugin will give you information on every error encountered when rendering the page. I don't know if it has an option to do so loudly, but it certainly wouldn't be hard to modify.
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 [sun.com] has already been ported to mobile devices...
Several of the vulnerabilities in libPNG are exploitable integer overflow vulnerabilities. Java does absolutely nothing to stop those vulnerabilities. And even if it does, much of the java runtime is written in C, and is just as vulnerable to buffer overflows.
The grandparent was right: 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.
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.
yawn (Score:5, Insightful)
Re:yawn (Score:5, Insightful)
That would be a valid retort if it weren't for Google's perpetual beta mentality.
Parent
Re: (Score:2, Insightful)
Re:yawn (Score:5, Insightful)
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.
Parent
Re:yawn (Score:5, Insightful)
Parent
Re: (Score:2)
Re: (Score:2)
I disagree with the assumption that security holes in beta software aren't serious. Beta -- in software at least -- means that real live users are using it.
However, at this point the software is not available to users; if the problem is that the system uses obsolete implementations for some of its APIs, the open source process has worked the way its supposed to. If the problem is inherent in some important APIs, that's a different kettle of fish.
Still, I expect Android to be a
Re: (Score:2, Funny)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:1)
Outdated software != beta software Please RTFSummary before posting
Tell yourself that.
This SDK hasn't been completed. Nothing to read here.
Re: (Score:2)
Also probably planned.
Google is practically a subcontractor for the NSA. Expect a Google phone to be a hotline to the datamine.
I'm not exactly sure how phone software works... (Score:3, Interesting)
Re:I'm not exactly sure how phone software works.. (Score:3, Insightful)
Re: (Score:3, Interesting)
the point being? (Score:1)
Re: (Score:1)
IMHO Google has done a fairly good job in its software development (which is to say, I have personally had few issues). Being open source at least lets people know there is a problem. T
Re: (Score:2)
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...
Re: (Score:2)
The exciting thing to me is that this Google project will introduce not only open source software, but open source thinking and open source culture to the masses.
And knowing Google, it will be successful, and being successful it will clear up many of the uninformed stigmas that cling to open source software - hopefully beginning with the kind of FUD that MS spouts.
Who The Hell Is Still Using BMP? (Score:5, Funny)
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? (Score:4, Funny)
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!
Parent
People who need uncompressed images. (Score:2)
Sometimes you just don't want your data to be compressed; you want to be able to tell the OS to load the data from storage and have it right there, ready for you to use. Sometimes you just can't afford the overhead of decompression. But PNG, reasonably enough (I suppose) for network graphics, requires all images to be compressed; you can't say "no compression".(*) BMP, on the other hand, is uncompressed by default; aside from the line order problems (which are easily solved by pre-flipping the image), th
Re: (Score:2)
But heck if you must use an uncompress format then just us IFF and be done with it
Re: (Score:3, Funny)
Re: (Score:2)
Already fixed (Score:5, Informative)
Re: (Score:2, Informative)
Re: (Score:2)
Re: (Score:1)
Hoorah for google and open source software.
Re: (Score:3, Insightful)
Re: (Score:1)
Dumb (Score:1)
Re: (Score:2, Informative)
They also pointed out that this iss not BETA code, but merely a release of propsed code to allow potential devlopers to add their insights to the project on which direction the code should go on various portions.
The libraries have now been replaced (evidently) with the newer o
This... (Score:1)
Oh noes! (Score:2, Funny)
that's why it's open source (Score:5, Interesting)
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.
you know what this means... (Score:1)
I'm going to call it "Gaolbreak"
Re:Re-using, Re-using, Not re-inventing the wheel, (Score:4, Insightful)
Parent
Re:Re-using, Re-using, Not re-inventing the wheel, (Score:5, Insightful)
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.
Parent
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Interesting)
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 [sun.com] has already been ported to mobile devices...
Re: (Score:2)
Re:Re-using, Re-using, Not re-inventing the wheel, (Score:4, Informative)
Parent
Re: (Score:2)
The grandparent was right: People should stop thinking that somehow interpreted languages (Java,
Re: (Score:3, Interesting)
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.