Site menu:

Sponsored by

Bitcube Ltd.  Expert Linux Consultancy

Currently...

Categories

Meta

Site search

 

May 2008
M T W T F S S
« Apr   Jun »
 1234
567891011
12131415161718
19202122232425
262728293031  

Archives

Links:

dsa-1571

Or “Oh bugger”.

In short, Debian made a slight change to openssl which means that all keys (SSH user and host keys, X509 keys and certs, OpenVPN passwords) have not been sufficiently random for the last few years.

This is a _lot_ of effort to correct:

  • remove all bad ssh keys and regenerate them (the former being potentially harder than the latter)
    • fortunately in some environments we keep them all in LDAP which makes it really easy :)
  • remove all bad openvpn passwords (not a problem, we don’t use those anywhere)
  • replace all X.509 (used in SSL)
    • this is the biggie - it affects secure website, and anything else SSL secured
    • such as LDAP for us
    • and even worse, we’ll have to regenerate the “root of trust” CA key which is a royal pain
      • realistically we’ll turn off SSL validation, push all the changes out, then turn validation back on

I _would_ also like to back Kurt. It was a mistake - not malicious (far from it). Just looking at some of the comments at http://www.links.org/?p=327, you can see that some just lay blame with _no_ validation. However, let’s look at this a bit more (salt required as I’ve _not_ verified all of this and so I might be back later to update/correct):

  • it was trying to remove use of uninitialised memory (which is normally a bug)
    • why is it treating uninitialised memory as a good random source anyway?
    • there was apparently no comment explaining the use of the uninitialised memory
    • unfortunately the patch actually removed _all_ random sources
      • Update: or rather commented out a similar line which was rather important
  • Kurt actually _asked_ on the openssl mailing list if this was sane
    • and was told “yes” by what appear to be well know openssl people
  • I don’t know if his patch was pushed back upstream for inclusion

One person (hi Jonathan!) started to blame it on Debian’s policy of “backports” (as opposed to using the latest upstream). Backports are generally a _far_ safer way to fix security problems. That’s why they do it! On the _rare_ occasions that a backport isn’t feasible (or difficult to do as so _many_ changes need to be made), a new upstream release _is_ used. I believe firefox often falls into this category.

Debian gets a lot of flak without just cause:

  • for highlighting the KDE Qt/GPL issue
    • it was _illegal_ - it wasn’t idealism
    • Qt eventually went GPL
  • for renaming firefox “iceweasel”
    • they were not _allowed_ to ship any patches (e.g. security fixes) and still call it firefox
    • eventually firefox dropped this stupid policy
  • apache2 config is split up (Hi Jonathan again!)
    • I’m sorry, but really, McCools 2000 line config is _far_ harder to tweak
    • particularly by automated scripts when compared to /etc/apache2/mods-enabled
    • oh, and don’t you _dare_ suggest redhat is saner:
  • exactly what goes in /etc/http/conf/ directory compared to /etc/http/conf.d/ ?

Comments

Comment from jonathan
Time: Monday 9 June, 2008, 08:29

Which Jonathan? The backports comment was definitely Growler, not me ;-)
Oh and I never said I liked the monster httpd.conf (”retrograde” is the word I’ve read used). I just don’t feel that I need that many files to configure a webserver or two ;-)

Comment from adrian
Time: Monday 9 June, 2008, 17:40

Growler Jonathan :-) Ah, okay, fair enough, I suppose you just have to ignore all “*-available” directories and then it’s not too bad.

Write a comment