OpenBSD Journal

Patches for OpenSSL bounds checking bug

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)


Comments
  1. By Noryungi (noryungi) noryungi@yahoo.com on


    Thank $DEITY that OpenSSH is *not* affected.

    Especially given the number of machines I have to correct.

  2. By Sebastian Rother (37.5.0.126) on

    Are the SSH Keys affected too or is it realy just specific to the TLS protocol? I did not checked what is used in OpenSSH. Is the used mechanism maybe related to OpenSSLs?


    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
    1. By Sebastian Rother (37.5.0.126) on

      > Are the SSH Keys affected too or is it realy just specific to the TLS protocol? I did not checked what is used in OpenSSH. Is the used mechanism maybe related to OpenSSLs?
      >
      >
      > 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.

  3. By Anonymous Coward (86.36.35.12) on

    Is there an easy way to find the members of OpenBSD ports tree that are statically-linked to OpenSSL?

    Comments
    1. By brynet (Brynet) on http://brynet.biz.tm/

      > Is there an easy way to find the members of OpenBSD ports tree that are statically-linked to OpenSSL?

      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.

  4. By Sebastian Rothjer (80.153.96.240) on

    I fail to see how, if an attacker copied the whole ram in 64kb chunks, an sshd is NOT affected by this bug.

    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
    1. By Anonymous Coward (190.134.117.208) on

      > I fail to see how, if an attacker copied the whole ram in 64kb chunks, an sshd is NOT affected by this bug.
      >
      > 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
      1. By Anonymous Coward (80.153.96.240) on

        > > I fail to see how, if an attacker copied the whole ram in 64kb chunks, an sshd is NOT affected by this bug.
        > >
        > > 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.

  5. By Magic carpet (bodie) bodzart@openbsd.cz on http://www.openbsd.org

    http://thread.gmane.org/gmane.os.openbsd.misc/211952/focus=211963

  6. By Anonymous Coward (86.41.33.148) on

    Can someone confirm that djm's commit to libssl is already in snapshots:
    OpenBSD 5.5-current (GENERIC) #32: Tue Apr  8 16:53:39 MDT 2014
    OpenBSD 5.5-current (GENERIC.MP) #37: Tue Apr  8 16:58:46 MDT 2014
    OpenBSD 5.5-current (GENERIC) #57: Tue Apr  8 17:21:37 MDT 2014
    OpenBSD 5.5-current (GENERIC.MP) #61: Tue Apr  8 17:28:01 MDT 2014
    

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]