Falha de segurança grave no OpenSSL (Heartbleed Bug)

Aparicio

/dev/mod
Staff
The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.

http://heartbleed.com/
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160

Não é norma meter aqui falhas de segurança mas esta pareceu-me demasiado grave para não mencionar aqui.
Basicamente software como servidores web com HTTPS (Apache, Nginx...) que usem o OpenSSL versão 1.0.1 a 1.0.1f inclusive está vulnerável, e já foi demonstrado que é possível roubar as chaves privadas dos certificados e outras informações como dados de autenticação de utilizadores arbitrários.

É aconselhado actualizar o OpenSSL ou recompilar sem o TLS Heartbeat, e renovar os certificados (revogando os anteriores).
 
Hoje foi o assunto no dia onde trabalho, dado o potencial risco do negocio para esta falha. Felizmente não fomos afectados pela falha.

No servidor que tenho, fui afectado pela falha, já actualizei o OpenSSL e renovei os certificados (Self-signed). Mas estou com um problema, no php ele continua a detecta o 1.0.1f e na propria versão do OpenSSL aparece-me isto:

OpenSSL 1.0.1g 7 Apr 2014 (Library: OpenSSL 1.0.1f 6 Jan 2014)

Fazem ideal de qual será o problema ? Static library ?
 
Sim, já reiniciei todos os serviços e o servidor inclusive. Vou procurar melhor.

EDIT: Faltava-me fazer update a isto: aptitude install libssl-dev libssl1.0.0
 
Última edição:
The "Heartbleed" flaw that has turned internet security upside down was added to the open-source OpenSSL protocol on New Year's Eve 2011, experts now believe. It was entered by one man — German software developer Robin Seggelmann — and a subsequent review failed to pick up on the catastrophic coding error Seggelmann had made. "In one of the new features, unfortunately, I missed validating a variable containing a length," he told the Sydney Morning Herald. By now you're likely well familiar with the damage that's resulted from what he described as a "trivial" error.

Some have accused Seggelmann of intentionally adding the major security hole to OpenSSL, charges that he vigorously denies. After all, the reason he was working on OpenSSL that night was to contribute bug fixes and improvements to the project. "It was a simple programming error in a new feature, which unfortunately occurred in a security relevant area," he said. But Seggelmann acknowledges that the mistake has led to "severe" consequences.

As The New York Times points out, the entire debacle is a stark reminder of web security's fragile state. The protections around a critical protocol can be undone by a simple mistake, and that slip-up can go unnoticed for years — just as it did here. "It’s unfortunate that it’s used by millions of people, but only very few actually contribute to it," Seggelmann said. "The benefit of open source software is that anyone can review the code in the first place."
http://www.theverge.com/2014/4/10/5600744/heartbleed-crisis-highlights-fragility-of-web-security
 
Um boche com schnaps a mais no bucho por causa da passagem de ano e a segurança mundial de milhões de servidores e aparelhos fica em risco durante dois anos...
 
This morning, content distribution network Cloudflare gave some hope to those affected by the Heartbleed security flaw with an announcement that the bug might not be as bad as feared. In two weeks of testing, Cloudflare said, its researchers failed to exploit the bug to steal a website's private SSL keys, which secures the data sent to users. It issued a challenge to white-hat hackers to successfully retrieve the private security keys — and unfortunately for the web, one of them succeeded.

(...)
http://www.theverge.com/us-world/20...-heartbleed-to-retrieve-private-security-keys
 
Qualquer web admin deve no mínimo actualizar todos os seus sistemas para a nova versão do OpenSSL, revogar os antigos certificados e gerar novas. Há demasiadas incertezas sobre o que é que possa ou não ter sido leaked.
 
Qualquer web admin deve no mínimo actualizar todos os seus sistemas para a nova versão do OpenSSL, revogar os antigos certificados e gerar novas. Há demasiadas incertezas sobre o que é que possa ou não ter sido leaked.

Se usarem openssl ou algo que dependa dele. Se não estou em erro, se não se usar por exemplo https, não há risco.

Apesar de conseguirem ter tirado as private keys, se os sistemas tiverem sido patchados a tempo, penso que o risco é baixo.

Mas sim, este bug foi mau.
 
Sim claro. Para quem não use HTTPS, ou SSL em geral, que dependa do OpenSSL não há problema. Existem outras implementações do protocolo que não sofreram deste bug.
 
Um pormenor que está mais relacionado com servidores. Em Debian, quando se faz os updates, ele pergunta se pode fazer restart aos serviços que linkam com o openssl. Em Centos, o update é feito sem reiniciar qualquer serviço. É preciso reiniciar à mão os serviços. Provavelmente também se aplica a Fedora.
 
No RedHat sugerem métodos (e.g. lsof) para ver que serviços que estão a correr dependem do openssl, mas também dizem que o mais simples e seguro é reiniciar o servidor.
 
Recebi spam de [email protected] a fazer publicidade não solicitada ao serviço de e-mails na "Cloud PT" (whatever that's supposed to mean) fazendo referência ao bug heartbleed :-D

Não deixa de ser curioso que esta empresa de "telecomunicações" que se diz na vanguarda não tem um único e-mail para contacto com os clientes.
 
OpenBSD has started a massive strip-down and cleanup of OpenSSL

The denizens of lobste.rs (and no doubt you, eagle-eyed reader!) have made note of the ongoing rototilling of the OpenSSL code in OpenBSD, and Joshua Stein (jcs@) has chimed in with a quick breakdown of the action thus far:

Changes so far to OpenSSL 1.0.1g since the 11th include:

  • Splitting up libcrypto and libssl build directories
  • Fixing a use-after-free bug
  • Removal of ancient MacOS, Netware, OS/2, VMS and Windows build junk
  • Removal of “bugs” directory, benchmarks, INSTALL files, and shared library goo for lame platforms
  • Removal of most (all?) backend engines, some of which didn’t even have appropriate licensing
  • Ripping out some windows-specific cruft
  • Removal of various wrappers for things like sockets, snprintf, opendir, etc. to actually expose real return values
  • KNF of most C files
  • Removal of weak entropy additions
  • Removal of all heartbeat functionality which resulted in Heartbleed

To clarify, not all of the cryptographic engines were removed; the padlock and aesni engines are still in place. As always, it's heartening to see a concentrated effort on such a critical software component.
http://undeadly.org/
 
A meu ver o problema nem está no código. Um projecto antigo como o openssl vai ter código que é pouco ou nunca usado.

A meu ver, a comunidade open source devia olhar para dentro e ver por exemplo como um projecto tão fundamental como o openssl está estruturado.
Pelo que li, são 4 ou 5 pessoas voluntárias, nos seus tempos livres que tratam das coisas. A nível de financiamento têm por volta de 2000$ por ano. A nível de testes era poucos e só de integração. Ora, por muito boas que sejam as pessoas a programar neste projecto, ele não tem bases físicas sólidas.

Neste tempo todo onde estiveram as empresas open source de sucesso? Não se pode usar por base algo e não ter pelo menos alguma simpatia por essa base.

A meu ver, no nosso mundo open source, existem verdadeiros diamantes que são tratadas como peças garantidas, que sempre existiram e que sempre funcionaram bem e esquecemos-nos que por trás estão pessoas e estruturas que têm que ser mantidas.
 
Back
Topo