Developers plug critical PNG graphic bug
Potential problem nipped in the bud
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 Network Graphics (PNG) format library contained a buffer overflow-style flaw.
The bug was discovered by developers at Mozilla. It's unclear which browsers supported the vulnerable library files.
Previous problems involving the rendering of PNG files have spawned drive-by download attacks, so the resolution of the latest problem at an early stage is to be welcomed.
In related news, developers also fixed a similar flaw in the libtiff library. Version 3.9.4 of the libtiff library plugs a buffer overflow bug that might be abused by specially crafted SubjectDistance tags, H Security reports. ®
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.
How Can You Use C/C++ these Days ?
Oh wait, it's the "industry standard".
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.