Chris Evans discovered a stack buffer overflow in the libPNG library. This means that an attacker could create a malicious PNG image file to take advantage of the flaw. If you were to view that malicious image on your system then it could execute arbitrary code as you. Since most applications that display PNG files are linked to libPNG or contain libPNG code, that increases the risk of this flaw.
Whilst researching affected applications we found that most browsers were affected - so an attacker would simply have to put a malicious image onto a web site that you visit. You'd still need to be forced to visit that web site though. Or maybe the attacker can act as a man-in-the-middle and inject the malicious image file (as was reported recently at DefCon where wireless surfers had all their images replaced). More worrying are perhaps email applications that might load images by default, which could allow propegation of a worm. This isn't an issue that only affects Linux; just sending malicious images in attachments to someone using AppleMail on MAC OSX is enough to trigger the flaw.
Although i've not yet seen an exploit containing shellcode for this issue we believe it is triviallly exploitable. This is a "Critical" update.
Red Hat Enterprise Linux users need to update their libpng and Mozilla (which contained it's own copy of libpng) packages. Updating libpng is sufficient to protect all the applications that use that library to decode images (although you'll need to restart any applications you've already got running to pick up the change, it's probably easiest just to restart your system if you're unsure).
Fedora Core users should be protected against possible exploits of this issue by exec-shield, but should still upgrade (as a malicious PNG file would still crash an application).
Because libpng is under a BSD-style license, anyone is basically free to use or include libpng even in closed-source products. So expect to see a whole raft of advisories over the coming weeks as other vendors come to discover that they're vulnerable to this issue.
They got that information from a Connectiva security advisory. That advisory actually says "trigger the execution of arbitrary commands" but if you read the context you'll find that in fact what it means is that a cunning attacker could use a minor flaw in Apache that allows it to log escape characters in order to exploit possible flaws in terminal emulators to execure arbitrary commands if you view the log file. [source].
So we've magically turned an issue which is of quite minor risk and minor severity into one classed as "Moderately Critical". Using the same logic you could then use publicised (but fixed) flaws in the Linux kernel to gain root privileges and we've got a remote root exploit in Apache folks! It's Chinese Whisper Security Advisories at their best.
What is disturbing is a report from a third party company who is vulnerable to one of the Denial of service issues that said that it wasn't a security issue as their were hundreds of other possible DoS attacks. Actually, this attack causes OpenSSL to crash. We've got a proof of concept, you don't have to send more than a kb of data to get OpenSSL to crash remotely. This can be quite serious if you have a service that can't recover from that. Things like Apache (when running in its default prefork memory model) can recover quite well - they just spawn off a new child to replace the dead one. This is going to use up some extra resources, but depending on the platform it's quite minor (and will stop as soon as the attacker stops sending malicious packets). Not everything that listens to the network that uses OpenSSL is so resiliant.
Going to be in London next weekend?
Over the years there have been many times when we've thought about stopping production, usually when a competitor announced some other Apache magazine that we thought would do a better job than we do. But most of them gave up. They probably realised that there wasn't any money to be made from an Apache httpd journal.
UK Web became C2Net which became Red Hat, and Apache Week is still going strong. We'll have to think of something exciting to do for our tenth birthday.
House modifications are coming along well, with updates to the Home Automation security software (a few suprises for any intruder), and some large black marble balls on a rockery out the front. Tracy has been spending a few days pressure-washing the driveway which is fun apart from the occasional lump of sand that gets blasted at random parts of your body. Sand in your nose is quite annoying.
Then, suddenly, the ISS team announced the same issue publically causing us to go into firefighting mode and release the advisory (which I'd fortunately already drafted and got positive feedback on), followed by seemingly hundreds of press calls, lots of additional analysis, and reading ISS say I was untrustworthy in some Chicago newspaper ;-)
Now for some sleep
# Extended X10 control of LW11G dimmer # # Unlike other L*11* modules the LW11G # seems to only respond to code 53. Set the data to # # 0 = immediate off # 255 = immediate on # 1-254 = slowly dim or bright to that level, turns on if not already