Sunday, May 18, 2008

Security is our common problem

When I found out about DSA-1571, I immediately upgraded my openssl package and regenerated ssh keys.

In a few days I received notification from code.haskell.org admins, which informed me that my code.haskell.org account is blocked due to the compromised ssh key (they checked all keys against ssh blacklist, provided by Debian). I installed that blacklist too, and my key really appeared to be weak. I tried to regenerate keys several times, and all of them were in blacklist.

Finally I figured out the problem: I upgraded openssl, but didn't touch libssl and openssh packages. From the one point, it was my fault -- I didn't upgraded all vulnerable packages. From the other, this problem could be avoided by bumping dependency versions, so that leaving vulnerable versions would be unacceptable by package manager. In any case, today you cannot just rely on software writers and maintainers and feel secure.

4 comments:

Oleg Golberg said...

today you cannot just rely on software writers and maintainers and feel secure

could you ever? :)

Roman Cheplyaka said...

I mean, we can't yet. But I believe we'll be able at some point. Most people involved in opensource are smart enough to learn from the mistakes.

Oleg Golberg said...

I actually think that people working on proprietary software are just as smart — both can create excellent products. And very often the problems are caused by "the middle man." The marketing guys can effectively push deadlines for a proprietary product and cause features to be dropped, QA to be quick and poor, and new people to be brought in, impeding the in-team communication. Ultimately, an exciting piece of software gets crippled (think MS). Much of the open source software passes through a package maintainer before reaching the user. The maintainer is not necessarily as competent as the software author, and the QA process for the package might be less rigorous than that for the original code. And so, a major distribution can introduce a critical bug in an ubiquitous library that stays unnoticed for years. Last but not least, large projects and distributions have strict release cycles that cause beta-quality software to be shipped to the user (think Ubuntu Hardy and GVFS in Gnome 2.22). And this makes me far less optimistic — I don't think the situation will change much.

Roman Cheplyaka said...

The maintainer is not necessarily as competent as the software author, and the QA process for the package might be less rigorous than that for the original code.
That's true. And I hope this accident has teached maintainers to introduce as little changes as possible and submit their patches to upstream.

In opensource "middle men" are generally more competent and interested in the quality of the product, than in industry. There are real chances for development/maintenance procces to be improved.