Debian e derivados| Falha no pacote OpenSSL torna números aleatórios previsíveis

[CR_]

in: http://it.slashdot.org/article.pl?sid=08/05/13/1533212

SecurityBob writes "Debian package maintainers tend to very often modify the source code of the package they are maintaining so that it better fits into the distribution itself. However, most of the time, their changes are not sent back to upstream for validation, which might cause some tension between upstream developers and Debian packagers. Today, a critical security advisory has been released: a Debian packager modified the source code of OpenSSL back in 2006 so as to remove the seeding of OpenSSL random number generator, which in turns makes cryptographic key material generated on a Debian system guessable. The solution? Upgrade OpenSSL and re-generate all your SSH and SSL keys. This problem not only affects Debian, but also all its derivatives, such as Ubuntu."

in: http://article.gmane.org/gmane.linux.debian.security.announce/1614

------------------------------------------------------------------------

Debian Security Advisory DSA-1571-1                  security <at> debian.org

http://www.debian.org/security/                          Florian Weimer

May 13, 2008                          http://www.debian.org/security/faq

------------------------------------------------------------------------

Package        : openssl

Vulnerability  : predictable random number generator

Problem type  : remote

Debian-specific: yes

CVE Id(s)      : CVE-2008-0166

Luciano Bello discovered that the random number generator in Debian's

openssl package is predictable.  This is caused by an incorrect

Debian-specific change to the openssl package (CVE-2008-0166).  As a

result, cryptographic key material may be guessable.

This is a Debian-specific vulnerability which does not affect other

operating systems which are not based on Debian.  However, other systems

can be indirectly affected if weak keys are imported into them.

It is strongly recommended that all cryptographic key material which has

been generated by OpenSSL versions starting with 0.9.8c-1 on Debian

systems is recreated from scratch.  Furthermore, all DSA keys ever used

on affected Debian systems for signing or authentication purposes should

be considered compromised; the Digital Signature Algorithm relies on a

secret random value used during signature generation.

The first vulnerable version, 0.9.8c-1, was uploaded to the unstable

distribution on 2006-09-17, and has since propagated to the testing and

current stable (etch) distributions.  The old stable distribution

(sarge) is not affected.

Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key

material for use in X.509 certificates and session keys used in SSL/TLS

connections.  Keys generated with GnuPG or GNUTLS are not affected,

though.

A detector for known weak key material will be published at:

  <http://security.debian.org/project/extra/dowkd/dowkd.pl.gz>

  <http://security.debian.org/project/extra/dowkd/dowkd.pl.gz.asc>

    (OpenPGP signature)

Instructions how to implement key rollover for various packages will be

published at:

  <http://www.debian.org/security/key-rollover/>

This web site will be continously updated to reflect new and updated

instructions on key rollovers for packages using SSL certificates.

Popular packages not affected will also be listed.

In addition to this critical change, two other vulnerabilities have been

fixed in the openssl package which were originally scheduled for release

with the next etch point release: OpenSSL's DTLS (Datagram TLS,

basically "SSL over UDP") implementation did not actually implement the

DTLS specification, but a potentially much weaker protocol, and

contained a vulnerability permitting arbitrary code execution

(CVE-2007-4995).  A side channel attack in the integer multiplication

routines is also addressed (CVE-2007-3108).

For the stable distribution (etch), these problems have been fixed in

version 0.9.8c-4etch3.

For the unstable distribution (sid) and the testing distribution

(lenny), these problems have been fixed in version 0.9.8g-9.

We recommend that you upgrade your openssl package and subsequently

regenerate any cryptographic material, as outlined above.

#aptitude update && aptitude upgrade  resolve o problema tal como é indicado no link acima...

[falco]

Porque é que achaste que isto era digno de nota?

Falhas de segurança há "todos os dias"...

[Triton]

Porque é que achaste que isto era digno de nota?

Falhas de segurança há "todos os dias"...

Então e a velha conversa de que isto é código aberto, e que todos os dias há muitos olhos a ver o código? Parece que desta vez só demoraram 2 anos para corrigir uma falha que provavelmente foi colocada no código de propósito - quem é que não sabe que em números random tem de se utilizar uma seed? até os meus colegas de faculdade que começaram há uns meses a programar já sabem isso... Nem quero imaginar as falhas que existem deste tipo! Ainda por cima numa distribuição como o Debian mais as suas grandes políticas de segurança. cof, cof...

<rant_mode_off/>

Flame war starting in 3... 2... 1... I love this!

[falco]

Então e a velha conversa de que isto é código aberto, e que todos os dias há muitos olhos a ver o código?

Ninguém diz que todos os dias há gente a olhar para todo o código. Mas podes ter a certeza que há muito mais gente a olhar para o código, do que se o código não estivesse disponível

Se o código fosse proprietário e fechado, nunca teria sido descoberto e isso é que seria ainda mais preocupante. AH e sim já aconteceu com código proprietário coisas semelhantes, e vê lá tu que o caso de que me lembro foi na m$...

Parece que desta vez só demoraram 2 anos

Não! A falha tem dois anos, mas foi descoberta à menos, por isso não demoraram dois anos a corrigir uma falha conhecida. O que importa é que sejam rápidos a corrigir a partir do momento que foi descoberta porque para perigo já basta o perigo durante o período em que não era conhecida.

[CR_]

Porque é que achaste que isto era digno de nota?

Falhas de segurança há "todos os dias"...

Acima de tudo por isto:

- "Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should

be considered compromised"

A falha tem dois anos mas pode ainda afectar mesmo quem já não use Debian ou baseado se tiver chaves feitas nestes sistemas na qual a falha ainda não tenha sido corrigida.

O problema foi que a falha era nas alterações feitas ao código do openssl antes de "empacotar" logo há muito menos gente a ver do que no código "origem" do openssl.

Como o falco disse o que demorou foi a descobrir a falha, não a corrigi-la.

EDIT: http://www.links.org/?p=327

[falco]

CR_ tens razão!

Mas já agora e sem querer minimizar o problema de qualquer forma, pois é um problema extremamente grave. Não é a primeira vez que há problemas com implementações de SSL. Lembro-me de uma em 2002, que teve repercursões semelhantes, com a agravante de ser numa implementação mais usada que a distribuição de OpenSSL da Debian (foi na implementação da m$).

Sim também é verdade que há muito mais gente a olhar para o código do upstream do que para o código que está nas distribuições. Mas sei que também há pessoal a olhar para o código das distribuições.

Por motivos profissionais, eu próprio já olhei para código de pacotes de Debian, de Ubuntu e de Red Hat Enterprise Linux (curiosamente ao mesmo tempo que estava a olhar para o código do upstream para comparar).

[slack_guy]

Esta é uma das desvantagens (e muito séria, por sinal) em usar distribuições cujos developers se presumem mais entendidos que os 'upstream'. Assim de cabeça, lembro-me de alguns bugs introduzidos no pacote Perl da RedHat; de patches ao kernel a torto e a direito que algumas distros fazem só para suportarem 'out of the box' mais um parafuso; lembro-me também da polémica da Debian (e dos disparates que fez) com o cdrecord. Reconheço, porém, que na maior parte dos casos (estatística minha) não existem problemas.

Optar por usar uma distro e não usar outra é isso mesmo: uma opção, com vantagens e com desvantagens. Desde que se saiba o que está em jogo, é uma opção consciente.

[CR_]

Mais dois links:

http://www.debian.org/security/key-rollover/

http://wiki.debian.org/SSLkeys

O texto do link acima ( http://www.links.org/?p=327 )

Vendors Are Bad For Security

I’ve ranted about this at length before, I’m sure - even in print, in O’Reily’s Open Sources 2. But now Debian have proved me right (again) beyond my wildest expectations. Two years ago, they “fixed” a “problem” in OpenSSL reported by valgrind[1] by removing any possibility of adding any entropy to OpenSSL’s pool of randomness[2].

The result of this is that for the last two years (from Debian’s “Etch” release until now), anyone doing pretty much any crypto on Debian (and hence Ubuntu) has been using easily guessable keys. This includes SSH keys, SSL keys and OpenVPN keys.

What can we learn from this? Firstly, vendors should not be fixing problems (or, really, anything) in open source packages by patching them locally - they should contribute their patches upstream to the package maintainers. Had Debian done this in this case, we (the OpenSSL Team) would have fallen about laughing, and once we had got our breath back, told them what a terrible idea this was. But no, it seems that every vendor wants to “add value” by getting in between the user of the software and its author.

Secondly, if you are going to fix bugs, then you should install this maxim of mine firmly in your head: never fix a bug you don’t understand. I’m not sure I’ve ever put that in writing before, but anyone who’s worked with me will have heard me say it multiple times.

Incidentally, while I am talking about vendors who are bad for security, it saddens me to have to report that FreeBSD, my favourite open source operating system, are also guilty. Not only do they have local patches in their ports system that should clearly be sent upstream, but they also install packages without running the self-tests. This has bitten me twice by installing broken crypto, most recently in the py-openssl package.

[1] Valgrind is a wonderful tool, I recommend it highly.

[2] Valgrind tracks the use of uninitialised memory. Usually it is bad to have any kind of dependency on uninitialised memory, but OpenSSL happens to include a rare case when its OK, or even a good idea: its randomness pool. Adding uninitialised memory to it can do no harm and might do some good, which is why we do it. It does cause irritating errors from some kinds of debugging tools, though, including valgrind and Purify. For that reason, we do have a flag (PURIFY) that removes the offending code. However, the Debian maintainers, instead of tracking down the source of the uninitialised memory instead chose to remove any possibility of adding memory to the pool at all. Clearly they had not understood the bug before fixing it.

[falco]

Este texto tem coisas sábias... Um conjunto de boas práticas que todos deviam seguir. Infelizmente nem sempre toda a gente em todos os projectos seguem essas boas práticas, ou é possível controlar todas as situações para certificar-se que as boas práticas são cumpridas.

No entanto há algumas situações em que não faz sentido enviar os patchs para upstream, por exemplo:

* também poderá haver situações que os upstream developers se recusam a resolver e nesse caso faz sentido os distribuidores tomarem o assunto em suas mãos;

* em casos em que se pretende adicionar funcionalidades que o upstream não quer incluir mas que os utilizadores daquela distribuição querem utilizar;

Nos casos que mencionei e eventualmente noutros igualmente válidos, é importante é haver um controlo de qualidade adicional.

De forma geral essas boas práticas são seguidas, no entanto acontecem excepções e por vezes essas excepções criam problemas.

[slack_guy]

falco:

* também poderá haver situações que os upstream developers se recusam a resolver e nesse caso faz sentido os distribuidores tomarem o assunto em suas mãos;

* em casos em que se pretende adicionar funcionalidades que o upstream não quer incluir mas que os utilizadores daquela distribuição querem utilizar;

fork

É preferível criar um novo produto a arruinarem um produto que não é deles. Existem N casos de 'forks' pelas razões que apontaste.

[djthyrax]

fork

É preferível criar um novo produto a arruinarem um produto que não é deles. Existem N casos de 'forks' pelas razões que apontaste.

Como o Iceweasel pelo Debian originalmente.

[CR_]

Como o Iceweasel pelo Debian originalmente.

É diferente. No caso do Iceweasel o problema era que estava-se a utilizar a marca Firefox e portanto modificações sob a marca Firefox tinham de passar pela Mozilla. Como se queria liberdade na construção dos pacotes simplesmente deu-se outro nome, ou seja o problema não era fazer modificações que os programadores da Mozilla não aceitassem, era se quisessem fazer alguma modificação tinham de passar pela Mozilla caso usassem a marca Firefox.

[djthyrax]

se quisessem fazer alguma modificação tinham de passar pela Mozilla caso usassem a marca Firefox.

Same here.

[falco]

É preferível criar um novo produto a arruinarem um produto que não é deles. Existem N casos de 'forks' pelas razões que apontaste.

Nem sempre é o que faz sentido. Nem sempre há recursos para isso e nem sempre as modificações são o suficiente para justificar isso.

Como o Iceweasel pelo Debian originalmente.

O iceweasel não é um fork, é um re-branding. E é um dos exemplos em que não faz sentido perante os objectivos fazer um fork.

[djthyrax]

O iceweasel não é um fork, é um re-branding. E é um dos exemplos em que não faz sentido perante os objectivos fazer um fork.

Se a memória não me falha, para além da treta das licenças dos logos e afins, também houve a questão dos patches terem de ser "aprovados" pela Mozilla, uma cena qualquer assim.

[CR_]

Se a memória não me falha, para além da treta das licenças dos logos e afins, também houve a questão dos patches terem de ser "aprovados" pela Mozilla, uma cena qualquer assim.

Claro, os patches tinham de ser aprovados por causa "da treta das licenças dos logos e afins". Como estavam a usar a marca Firefox não podiam distribuir alterações sem aprovação.