Re: [gentoo-user] 'Heartbleed' bug
What surprises me here is OpenSSH. It's not supposed to use OpenSSL but Debian update process suggests to restart it after updating OpenSSL to a fixed version. Is it an overkill on their part? It might confuse admins. adam@proxy ~ $ ldd /usr/sbin/sshd linux-vdso.so.1 (0x7fffb068e000) libwrap.so.0 = /lib64/libwrap.so.0 (0x7f68db1e6000) libpam.so.0 = /lib64/libpam.so.0 (0x7f68dafd8000) libcrypto.so.1.0.0 = /usr/lib64/libcrypto.so.1.0.0 (0x7f68dabf5000) libutil.so.1 = /lib64/libutil.so.1 (0x7f68da9f2000) libz.so.1 = /lib64/libz.so.1 (0x7f68da7db000) libcrypt.so.1 = /lib64/libcrypt.so.1 (0x7f68da5a4000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f68da387000) libc.so.6 = /lib64/libc.so.6 (0x7f68d9fd7000) libgcc_s.so.1 = /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1 (0x7f68d9dc) libdl.so.2 = /lib64/libdl.so.2 (0x7f68d9bbc000) /lib64/ld-linux-x86-64.so.2 (0x7f68db3f1000) adam@proxy ~ $ qfile /usr/lib64/libcrypto.so.1.0.0 dev-libs/openssl (/usr/lib64/libcrypto.so.1.0.0) adam@proxy ~ $ So OpenSSH clearly IS using OpenSSL, and you need to restart sshd after upgrading OpenSSL.
Re: [gentoo-user] 'Heartbleed' bug
On 04/10/2014 05:03 PM, Adam Carter wrote: What surprises me here is OpenSSH. It's not supposed to use OpenSSL but Debian update process suggests to restart it after updating OpenSSL to a fixed version. Is it an overkill on their part? It might confuse admins. adam@proxy ~ $ ldd /usr/sbin/sshd linux-vdso.so.1 (0x7fffb068e000) libwrap.so.0 = /lib64/libwrap.so.0 (0x7f68db1e6000) libpam.so.0 = /lib64/libpam.so.0 (0x7f68dafd8000) libcrypto.so.1.0.0 = /usr/lib64/libcrypto.so.1.0.0 (0x7f68dabf5000) libutil.so.1 = /lib64/libutil.so.1 (0x7f68da9f2000) libz.so.1 = /lib64/libz.so.1 (0x7f68da7db000) libcrypt.so.1 = /lib64/libcrypt.so.1 (0x7f68da5a4000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f68da387000) libc.so.6 = /lib64/libc.so.6 (0x7f68d9fd7000) libgcc_s.so.1 = /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1 (0x7f68d9dc) libdl.so.2 = /lib64/libdl.so.2 (0x7f68d9bbc000) /lib64/ld-linux-x86-64.so.2 (0x7f68db3f1000) adam@proxy ~ $ qfile /usr/lib64/libcrypto.so.1.0.0 dev-libs/openssl (/usr/lib64/libcrypto.so.1.0.0) adam@proxy ~ $ So OpenSSH clearly IS using OpenSSL, and you need to restart sshd after upgrading OpenSSL. As far as I know, it doesn't use it for the communication itself, just some key generations, so it shouldn't be affected by this bug. But I guess better safe than sorry...
Re: [gentoo-user] 'Heartbleed' bug
Am Wed, 9 Apr 2014 18:06:35 -0600 schrieb Joseph syscon...@gmail.com: Is gentoo effected by this new 'Heartbleed' bug? The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library http://heartbleed.com/ Just FYI: security issues such as this get announced on the gentoo-announce ML (heartbleed was announced on the 8th of April). -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup signature.asc Description: PGP signature
Re: [gentoo-user] 'Heartbleed' bug
On Thu, Apr 10, 2014 at 05:53:44PM +0800, J?n Zahornadsk? wrote: On 04/10/2014 05:03 PM, Adam Carter wrote: What surprises me here is OpenSSH. It's not supposed to use OpenSSL but Debian update process suggests to restart it after updating OpenSSL to a fixed version. Is it an overkill on their part? It might confuse admins. adam@proxy ~ $ ldd /usr/sbin/sshd linux-vdso.so.1 (0x7fffb068e000) libwrap.so.0 = /lib64/libwrap.so.0 (0x7f68db1e6000) libpam.so.0 = /lib64/libpam.so.0 (0x7f68dafd8000) libcrypto.so.1.0.0 = /usr/lib64/libcrypto.so.1.0.0 (0x7f68dabf5000) libutil.so.1 = /lib64/libutil.so.1 (0x7f68da9f2000) libz.so.1 = /lib64/libz.so.1 (0x7f68da7db000) libcrypt.so.1 = /lib64/libcrypt.so.1 (0x7f68da5a4000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f68da387000) libc.so.6 = /lib64/libc.so.6 (0x7f68d9fd7000) libgcc_s.so.1 = /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1 (0x7f68d9dc) libdl.so.2 = /lib64/libdl.so.2 (0x7f68d9bbc000) /lib64/ld-linux-x86-64.so.2 (0x7f68db3f1000) adam@proxy ~ $ qfile /usr/lib64/libcrypto.so.1.0.0 dev-libs/openssl (/usr/lib64/libcrypto.so.1.0.0) adam@proxy ~ $ So OpenSSH clearly IS using OpenSSL, and you need to restart sshd after upgrading OpenSSL. As far as I know, it doesn't use it for the communication itself, just some key generations, so it shouldn't be affected by this bug. But I guess better safe than sorry... Right. heartbleed does not directly affect openssh, but openssh uses openssl and it's good practice to keep the shared libraries on-disk and the shared libraries in-memory in sync.
Re: [gentoo-user] 'Heartbleed' bug
On Thu, Apr 10, 2014 at 4:22 PM, Matthew Finkel matthew.fin...@gmail.com wrote: On Thu, Apr 10, 2014 at 05:53:44PM +0800, J?n Zahornadsk? wrote: On 04/10/2014 05:03 PM, Adam Carter wrote: What surprises me here is OpenSSH. It's not supposed to use OpenSSL but Debian update process suggests to restart it after updating OpenSSL to a fixed version. Is it an overkill on their part? It might confuse admins. adam@proxy ~ $ ldd /usr/sbin/sshd linux-vdso.so.1 (0x7fffb068e000) libwrap.so.0 = /lib64/libwrap.so.0 (0x7f68db1e6000) libpam.so.0 = /lib64/libpam.so.0 (0x7f68dafd8000) libcrypto.so.1.0.0 = /usr/lib64/libcrypto.so.1.0.0 (0x7f68dabf5000) libutil.so.1 = /lib64/libutil.so.1 (0x7f68da9f2000) libz.so.1 = /lib64/libz.so.1 (0x7f68da7db000) libcrypt.so.1 = /lib64/libcrypt.so.1 (0x7f68da5a4000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f68da387000) libc.so.6 = /lib64/libc.so.6 (0x7f68d9fd7000) libgcc_s.so.1 = /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1 (0x7f68d9dc) libdl.so.2 = /lib64/libdl.so.2 (0x7f68d9bbc000) /lib64/ld-linux-x86-64.so.2 (0x7f68db3f1000) adam@proxy ~ $ qfile /usr/lib64/libcrypto.so.1.0.0 dev-libs/openssl (/usr/lib64/libcrypto.so.1.0.0) adam@proxy ~ $ So OpenSSH clearly IS using OpenSSL, and you need to restart sshd after upgrading OpenSSL. As far as I know, it doesn't use it for the communication itself, just some key generations, so it shouldn't be affected by this bug. But I guess better safe than sorry... Right. heartbleed does not directly affect openssh, but openssh uses openssl and it's good practice to keep the shared libraries on-disk and the shared libraries in-memory in sync. How is OpenSSH not affected?
Re: [gentoo-user] 'Heartbleed' bug
The Heartbleed bug is in the Heartbeat function of TSL (a second keep alive). OpenSSL does not use TLS for transport security, it uses its own Protokoll for security. 2014-04-10 12:51 GMT+02:00 Nilesh Govindrajan m...@nileshgr.com: On Thu, Apr 10, 2014 at 4:22 PM, Matthew Finkel matthew.fin...@gmail.com wrote: On Thu, Apr 10, 2014 at 05:53:44PM +0800, J?n Zahornadsk? wrote: On 04/10/2014 05:03 PM, Adam Carter wrote: What surprises me here is OpenSSH. It's not supposed to use OpenSSL but Debian update process suggests to restart it after updating OpenSSL to a fixed version. Is it an overkill on their part? It might confuse admins. adam@proxy ~ $ ldd /usr/sbin/sshd linux-vdso.so.1 (0x7fffb068e000) libwrap.so.0 = /lib64/libwrap.so.0 (0x7f68db1e6000) libpam.so.0 = /lib64/libpam.so.0 (0x7f68dafd8000) libcrypto.so.1.0.0 = /usr/lib64/libcrypto.so.1.0.0 (0x7f68dabf5000) libutil.so.1 = /lib64/libutil.so.1 (0x7f68da9f2000) libz.so.1 = /lib64/libz.so.1 (0x7f68da7db000) libcrypt.so.1 = /lib64/libcrypt.so.1 (0x7f68da5a4000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f68da387000) libc.so.6 = /lib64/libc.so.6 (0x7f68d9fd7000) libgcc_s.so.1 = /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1 (0x7f68d9dc) libdl.so.2 = /lib64/libdl.so.2 (0x7f68d9bbc000) /lib64/ld-linux-x86-64.so.2 (0x7f68db3f1000) adam@proxy ~ $ qfile /usr/lib64/libcrypto.so.1.0.0 dev-libs/openssl (/usr/lib64/libcrypto.so.1.0.0) adam@proxy ~ $ So OpenSSH clearly IS using OpenSSL, and you need to restart sshd after upgrading OpenSSL. As far as I know, it doesn't use it for the communication itself, just some key generations, so it shouldn't be affected by this bug. But I guess better safe than sorry... Right. heartbleed does not directly affect openssh, but openssh uses openssl and it's good practice to keep the shared libraries on-disk and the shared libraries in-memory in sync. How is OpenSSH not affected? -- Mit freundlichen Grüßen / Best regards Randolph Maaßen
Re: [gentoo-user] 'Heartbleed' bug
Exactly, OpenSSH depends on OpenSSL, but should never use the buggy code. Some details in the answer here: http://superuser.com/questions/739349/does-heartbleed-affect-ssh-keys On 04/10/2014 07:00 PM, Randolph Maaßen wrote: The Heartbleed bug is in the Heartbeat function of TSL (a second keep alive). OpenSSL does not use TLS for transport security, it uses its own Protokoll for security. 2014-04-10 12:51 GMT+02:00 Nilesh Govindrajan m...@nileshgr.com: On Thu, Apr 10, 2014 at 4:22 PM, Matthew Finkel matthew.fin...@gmail.com wrote: On Thu, Apr 10, 2014 at 05:53:44PM +0800, J?n Zahornadsk? wrote: On 04/10/2014 05:03 PM, Adam Carter wrote: What surprises me here is OpenSSH. It's not supposed to use OpenSSL but Debian update process suggests to restart it after updating OpenSSL to a fixed version. Is it an overkill on their part? It might confuse admins. adam@proxy ~ $ ldd /usr/sbin/sshd linux-vdso.so.1 (0x7fffb068e000) libwrap.so.0 = /lib64/libwrap.so.0 (0x7f68db1e6000) libpam.so.0 = /lib64/libpam.so.0 (0x7f68dafd8000) libcrypto.so.1.0.0 = /usr/lib64/libcrypto.so.1.0.0 (0x7f68dabf5000) libutil.so.1 = /lib64/libutil.so.1 (0x7f68da9f2000) libz.so.1 = /lib64/libz.so.1 (0x7f68da7db000) libcrypt.so.1 = /lib64/libcrypt.so.1 (0x7f68da5a4000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f68da387000) libc.so.6 = /lib64/libc.so.6 (0x7f68d9fd7000) libgcc_s.so.1 = /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1 (0x7f68d9dc) libdl.so.2 = /lib64/libdl.so.2 (0x7f68d9bbc000) /lib64/ld-linux-x86-64.so.2 (0x7f68db3f1000) adam@proxy ~ $ qfile /usr/lib64/libcrypto.so.1.0.0 dev-libs/openssl (/usr/lib64/libcrypto.so.1.0.0) adam@proxy ~ $ So OpenSSH clearly IS using OpenSSL, and you need to restart sshd after upgrading OpenSSL. As far as I know, it doesn't use it for the communication itself, just some key generations, so it shouldn't be affected by this bug. But I guess better safe than sorry... Right. heartbleed does not directly affect openssh, but openssh uses openssl and it's good practice to keep the shared libraries on-disk and the shared libraries in-memory in sync. How is OpenSSH not affected?
Re: [gentoo-user] 'Heartbleed' bug
On Thu, 10 Apr 2014 10:52:21 +, Matthew Finkel wrote: Right. heartbleed does not directly affect openssh, but openssh uses openssl and it's good practice to keep the shared libraries on-disk and the shared libraries in-memory in sync. The easiest way to do that is with app-admin/checkrestart. -- Neil Bothwick Invertebrates make no bones about it. signature.asc Description: PGP signature
Re: [gentoo-user] 'Heartbleed' bug
Hello Joseph, On 04/10/2014 02:06 AM, Joseph wrote: Is gentoo effected by this new 'Heartbleed' bug? yes it is, as all OpenSSL versions 0.9.8 were affected. And Gentoo supported those versions. So Gentoo also was affected but it supports the new heartbleed-bug-fixed version 1.0.1g. I *think* that you could also use an older version disabling the tls-heartbeat USE flag. Regards Ralf
Re: [gentoo-user] 'Heartbleed' bug
On 04/09/2014 08:06 PM, Joseph wrote: Is gentoo effected by this new 'Heartbleed' bug? The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library http://heartbleed.com/ Yes, upgrade your OpenSSL to the latest stable version, and if 1.0.1g isn't stable on your arch (it should be unless it's a weird one), unset USE=tls-heartbeat like Ralf said. But that's not your big problem. If you operate any servers, the private keys to any OpenSSL-backed service may have been compromised. So the old certificates all need to be revoked and new ones issued. That includes Apache, OpenVPN, Postfix, Dovecot -- all the big ones. Even if you don't run servers, other people do, and they were probably vulnerable. So any passwords you've used on the web in the past two years should be changed.
Re: [gentoo-user] 'Heartbleed' bug
On Thursday, 10 April 2014 04:32:34 MSK, Michael Orlitzky wrote: Yes, upgrade your OpenSSL to the latest stable version, and if 1.0.1g isn't stable on your arch (it should be unless it's a weird one), unset USE=tls-heartbeat like Ralf said. But that's not your big problem. If you operate any servers, the private keys to any OpenSSL-backed service may have been compromised. So the old certificates all need to be revoked and new ones issued. That includes Apache, OpenVPN, Postfix, Dovecot -- all the big ones. Even if you don't run servers, other people do, and they were probably vulnerable. So any passwords you've used on the web in the past two years should be changed. What surprises me here is OpenSSH. It's not supposed to use OpenSSL but Debian update process suggests to restart it after updating OpenSSL to a fixed version. Is it an overkill on their part? It might confuse admins.
