How to show that you don't care about security
Wednesday, May 30. 2007, 11:37
It's an often told story that the free software community cares more about security. That it's much better because everyone can look at the code. While this may sometimes be true and I know many free software projects really care about security issues, often enough it's the exact opposite.
On 26.04., some guy called Marsu released an advisory about the GIMP. Loading files in the sunras-format can lead to a buffer overflow. Now, while it was silently fixed in svn, for a month they didn't put an advisory on their page and they didn't provide an update. Even with the release of new versions (2.2.15, 2.3.17), they somehow »forgot« to mention that it was a security-update.
Now, after looking into the NEWS-file (which is their Changelog), for 2.2.15 there's this little line:
- guard against a possible stack overflow in the Sunras loader (bug #433902)
They didn't mention the word »security«, they didn't give credits to Marsu, they didn't provide a reference to the advisory or the CVE-ID. Now, even worse, for 2.3.17, they forgot to mention that bug at all (it's probably part of the mentioned »lots of bug fixes«).
Now one might say this isn't that critical, because who uses sunras (I also never heared of that format before)? But think about this: I could mail someone a crafted sunras-file, saying it's an old image I found on some backup HD, together with the note that gimp can open it. I think it's not unlikely that someone might open it, especially with some intelligent social engineering. Beside that, EVERY SINGLE security bug should be taken serious.
Now, don't take me wrong. I love the GIMP, it's a great application. I also think that free software is an important precondition for secure software. But it's not the only thing. And as long as many people in the free software community treat security bugs like this, it's no better than those in the proprietary world.
On 26.04., some guy called Marsu released an advisory about the GIMP. Loading files in the sunras-format can lead to a buffer overflow. Now, while it was silently fixed in svn, for a month they didn't put an advisory on their page and they didn't provide an update. Even with the release of new versions (2.2.15, 2.3.17), they somehow »forgot« to mention that it was a security-update.
Now, after looking into the NEWS-file (which is their Changelog), for 2.2.15 there's this little line:
- guard against a possible stack overflow in the Sunras loader (bug #433902)
They didn't mention the word »security«, they didn't give credits to Marsu, they didn't provide a reference to the advisory or the CVE-ID. Now, even worse, for 2.3.17, they forgot to mention that bug at all (it's probably part of the mentioned »lots of bug fixes«).
Now one might say this isn't that critical, because who uses sunras (I also never heared of that format before)? But think about this: I could mail someone a crafted sunras-file, saying it's an old image I found on some backup HD, together with the note that gimp can open it. I think it's not unlikely that someone might open it, especially with some intelligent social engineering. Beside that, EVERY SINGLE security bug should be taken serious.
Now, don't take me wrong. I love the GIMP, it's a great application. I also think that free software is an important precondition for secure software. But it's not the only thing. And as long as many people in the free software community treat security bugs like this, it's no better than those in the proprietary world.
Comments
Display comments as
(Linear | Threaded)
I'm having a similar issue with PulseAudio: Lennart didn't put in the ChangeLog that the new version fixed security issues, and only thanks to Florian Steinel I know about it.
Also, it's not easy to find the patches that needs to be applied to fix 0.9.5 (and 0.9.6 is almost a full year of work, so I don't want it to go stable right now), I'm now running the third test hoping that it works.
Also, it's not easy to find the patches that needs to be applied to fix 0.9.5 (and 0.9.6 is almost a full year of work, so I don't want it to go stable right now), I'm now running the third test hoping that it works.
At Neu.de we started sending presents to people who find security issues. So also companies can do it the right way.
It's a pity but Open Source doesn't automatically mean that everything is better. Just like big company an individual programmer might feel some kind of shame when security related problem appears. And politically it would make all those Windose lunatics laughing out loudly, because every bug in open source software means that this software isn't more secure than closed source.
Of course this nonsense. No developer can't be blamed if such an error occurs. Yes, it would be nice if it doesn't happen, but with the size and complexety of modern software this is highly unlikely.
But real open source politics should be to handle security related bugs as open as possible. Most projects do this, though. Let's hope that the amount of projects that deal with security issues in an unacceptable way remains rather small.
Of course this nonsense. No developer can't be blamed if such an error occurs. Yes, it would be nice if it doesn't happen, but with the size and complexety of modern software this is highly unlikely.
But real open source politics should be to handle security related bugs as open as possible. Most projects do this, though. Let's hope that the amount of projects that deal with security issues in an unacceptable way remains rather small.
Add Comment
Warning: Illegal string offset 'properties' in /home/hanno/websites/blog.hboeck.de/htdocs/include/plugin_api.inc.php on line 1634
I recently wrote that I'm sometimes a bit unhappy how security issues are handled in free software project. Now, to have some contrast, today I'll talk about an example how to do it right. Serendipity, the software I'm using to host this blog, had an S
Tracked: Jun 17, 23:58