Developers plug critical PNG graphic bug

Developers have plugged a critical hole in a PNG reference library used by many browsers to render graphics file. The 1.2.44 and 1.4.3 updates to the libpng open source reference library address a bug that, left unfixed, created a mechanism for hackers to inject code onto vulnerable systems. Older versions of the Portable …

[Anonymous Coward]

Rewrite This For You

"The bug was discovered by developers at Mozilla. It's unclear which browsers supported the vulnerable library files"

Must read:

"The bug was discovered by developers at Mozilla. It's unclear which browsers USED the vulnerable library files"

[Graham Bartlett]

FFS

I don't believe we're *still* seeing buffer overrun bugs! How incompetent do you have to be to not check length against array size? Especially these days, when security vulnerabilities are big news.

[Anonymous Coward]

How Can You Use C/C++ these Days ?

Oh wait, it's the "industry standard".

[Skizz]

FFS

I think this is a case of a buffer overrun in an old library that no one, until now, has looked at. There's a lot of code out there that was written before security was a big issue and there just isn't the quantity of good developers to go over all that code and look for potential issues.

[YumDogfood]

Nobody use C/C++

More job security for me.

And lo, when everything was moved into the managed VM, it came to pass the malware moved also, so sparky the bright spark did invent the managed-managed VM, and all was well for a at least a week. Then did it come to pass also that he did learn of recursion, (having only a PhD in Javascript and plastering) and ejected the lappy with a mighty heave, out the bloody window.

Job done.

[Graham Bartlett]

@joeuro

C/C++ isn't necessarily the problem - the problem is people metaphorically running with scissors. You want to stop people having accidents, you either issue them all with safety scissors which protect them at the cost of some inefficiency at doing the job, or you tell them not to be stupid and careless. There's plenty of safety-related/critical code written in C/C++ and done well. Besides which, it's still possible to kill things in "safe" languages - maybe you can't do buffer overruns, but you can still land yourself with a deadlock or a livelock, for example. Or it simply might not do what it's supposed to. A crap coder will continue to be a crap coder and will continue to produce crap and unreliable code, regardless of the language they use.

[dr2chase]

bugs vs bugs

Not all bugs are equal -- a buffer overrun is a much easier route in than a deadlock (and yes, there are rare cases where you can use a deadlock for a security vulnerability).

I think we have to take for granted that most people will run with scissors, given half a chance. That some person, somewhere, coded something safety-critical in C/C++, and it has not yet exhibited embarrassing bugs, does not mean that most programmers are capable of consistently writing in C or C++ without making silly security mistakes. And of course, the truly safety-critical guys get much of their safety from using simple, draconian rules that cut out large hunks of the language. (malloc and recursion come to mind, never mind that they're probably not connected to a network).

Once upon a time I worked for a company that made debugging tools (CenterLine). When I went trolling for test data (i.e., other people's programs), I only found one that made it through the tool without at least a puzzling have-a-look-at-this-carefully diagnostic, and that was gzip -- which was subsequently revealed to have a buffer-overrun vulnerability. Lots of stuff in "production" use at the time, had use of freed memory, casts to incorrect type, that sort of thing.

[heyrick]

Don't just blindly blame C

"Lots of stuff in "production" use at the time, had use of freed memory, casts to incorrect type, that sort of thing."

While I agree that the power-nerd mindset needs to get their heads out of their asses and make C compilers with full bounds checking, etc, as the DEFAULT option; to simply say "C is cack" is blaming a tool for the lameness of the worker.

Casts to incorrect type? Can happen in any language. I've been bitten by this in VB when I forget that the language treats everything as being signed, hence you can't count to 40,000 with an int...

Use of freed memory? If you are using non-language elements, such as a sliding heap manager or OS-created buffers, it can be remarkably easy to forget to free blocks of memory and/or to use blocks after they have been freed. Or, if by mistake your atexit() is called twice, or a routine to free memory gets called multiple times, etc etc. This is a potential Gotcha in any language, not just C.

Granted, it seems C/C++ looks to make writing poor code easy, especially when constructs like *c.d[-&r]++; would probably generate valid code. But, look at my crazy example again. If you encounter code like that, it says a lot about the programmer (thinks they're oh-so-damn-clever) than it does about the language. You have to learn your tools, but moreso you have to write code to be logical, not to be l33t.

[Steen Hive]

Truism

Programmers that are allowed to be lax with memory management are usually equally cavalier with everything else.

Goes a long way to explaining why so much useless, non-functional, bloated shit, capable of bringing any infrastructure to a grinding halt is written in so-called "safe" languages and why so much stable, mission-critical stuff that keeps the world turning is written in the C family.

Then, of course we have ADA - safe as houses, but every line like having your fingernails pulled out in a Viet Cong prison.

[Robert Carnegie]

Is this just for Linux?

Firefox for Windows is on version 3.6.6 and I don't really know why. Something about letting unresponsive plugins have more time to become nonunresponsive before they are automatically disquonsivatized.