Contributed by tbert on from the oh SSLeeping hearts dept.
Patches for the so called heartbleed OpenSSL bug have been released by the OpenBSD project for OpenBSD 5.3-stable, OpenBSD 5.4-stable and OpenBSD 5.5
In the short statement contained in the commit message, Theo de Raadt (deraadt@) noted that OpenSSH is unaffected.
Module name: www Changes by: deraadt@cvs.openbsd.org 2014/04/07 20:21:17 Modified files: . : errata53.html errata54.html errata55.html Log message: release patches for 5.3, 5.4, and upcoming 5.5: Missing bounds checking in OpenSSL's implementation of the TLS/DTLS heartbeat extension (RFC6520) which can result in a leak of memory contents. To get ahead of a misconception... this does not affect SSH at all...
As noted on the Heartbleed Bug website, recovery involves revoking, regenerating, and redistributing SSL materiel.
(Comments are closed)
By Noryungi (noryungi) noryungi@yahoo.com on
Thank $DEITY that OpenSSH is *not* affected.
Especially given the number of machines I have to correct.
By Sebastian Rother (37.5.0.126) on
If you REISSUE Certificates take care that they are signed with sha2 (sha256).
And to everybody who does not yet "just" provide Perfect Forward Secrecy: Do so from now on... fuck backward compatibility if you can.
If an attacker recorded the traffic and used this Bug now to extract the keys/Users/Passwords (all was proofen by the Researchers) the attacker is now capable to decrypt the whole traffic wich was recorded if the Server did not used just PFS.
It's the Fukushima of the encryption-world...
Comments
By Sebastian Rother (37.5.0.126) on
>
>
> If you REISSUE Certificates take care that they are signed with sha2 (sha256).
>
> And to everybody who does not yet "just" provide Perfect Forward Secrecy: Do so from now on... fuck backward compatibility if you can.
>
> If an attacker recorded the traffic and used this Bug now to extract the keys/Users/Passwords (all was proofen by the Researchers) the attacker is now capable to decrypt the whole traffic wich was recorded if the Server did not used just PFS.
>
> It's the Fukushima of the encryption-world...
>
>
I missed that Theo already ruled out if OpenSSH might be affected.
By Anonymous Coward (86.36.35.12) on
Comments
By brynet (Brynet) on http://brynet.biz.tm/
There shouldn't be anything in the ports tree that statically links with OpenSSL, at least on amd64/i386.
The published errata indicates that for base, only ftp(1) is statically-linked with libssl.
By Sebastian Rothjer (80.153.96.240) on
if an remote attacker copied my whole ram and the box runs sshd I'd assume that the host keys are stored in the ram and thus they get copied too. if that's true it implies that if an attack was successfull an attacker could do MITM, or?
Also the password databases are loaded, passwords are in the RAm too if somebody logs into a box...
I fail to see why Theo claims sshd is not affected. Even a local login could be affected if an attacker is lucky to get the right chunk in time.
It would be kind if somebody could explain me more detailed if I might be wrong.
From my point of view you've to change kind of everything. Password resets, ssh-keys (all), SSL certificates. Because OpenBSD does not ship updated Versions wich do include Bugfixes (compared to Debian wich updates install media, no critic but a fact) you need to re-generate all keys wich are generated after the first start as well.
Comments
By Anonymous Coward (190.134.117.208) on
>
> if an remote attacker copied my whole ram and the box runs sshd I'd assume that the host keys are stored in the ram and thus they get copied too. if that's true it implies that if an attack was successfull an attacker could do MITM, or?
>
> Also the password databases are loaded, passwords are in the RAm too if somebody logs into a box...
>
>
> I fail to see why Theo claims sshd is not affected. Even a local login could be affected if an attacker is lucky to get the right chunk in time.
>
>
> It would be kind if somebody could explain me more detailed if I might be wrong.
>
>
> From my point of view you've to change kind of everything. Password resets, ssh-keys (all), SSL certificates. Because OpenBSD does not ship updated Versions wich do include Bugfixes (compared to Debian wich updates install media, no critic but a fact) you need to re-generate all keys wich are generated after the first start as well.
>
>
>
>
Only the programs that links against OpenSSL 1.1/1.2-beta and use TLS are affected. You can't leak the whole physical RAM, just the exploited address space.
Comments
By Anonymous Coward (80.153.96.240) on
> >
> > if an remote attacker copied my whole ram and the box runs sshd I'd assume that the host keys are stored in the ram and thus they get copied too. if that's true it implies that if an attack was successfull an attacker could do MITM, or?
> >
> > Also the password databases are loaded, passwords are in the RAm too if somebody logs into a box...
> >
> >
> > I fail to see why Theo claims sshd is not affected. Even a local login could be affected if an attacker is lucky to get the right chunk in time.
> >
> >
> > It would be kind if somebody could explain me more detailed if I might be wrong.
> >
> >
> > From my point of view you've to change kind of everything. Password resets, ssh-keys (all), SSL certificates. Because OpenBSD does not ship updated Versions wich do include Bugfixes (compared to Debian wich updates install media, no critic but a fact) you need to re-generate all keys wich are generated after the first start as well.
> >
> >
> >
> >
>
> Only the programs that links against OpenSSL 1.1/1.2-beta and use TLS are affected. You can't leak the whole physical RAM, just the exploited address space.
>
Thanks for the clarification!
I was realy worried about the rest of the other services.
By Magic carpet (bodie) bodzart@openbsd.cz on http://www.openbsd.org
By Anonymous Coward (86.41.33.148) on