Heartbleed attack on Openssl

[Sam Gleske]

On Wed, Apr 9, 2014 at 6:45 PM, Pete Stephenson <pete at heypete.com> wrote:

> On Apr 10, 2014 12:22 AM, "Felipe Vieira" <fmv1992 at gmail.com> wrote:
> >
> > So going back to the original question as I can see there is no
> disagreement on its importance:
> > 1) What are the consequences to the ordinary user?
> > All the news are lacking information on that. Can you point relevant
> examples?
>
> In short: the consequences could be dire but there is no way of knowing
> for certain what, if any, things have been compromised. Its probably best
> to assume the worst.
>

^ That.  Assume the worst because the vulnerability was there for two
years.  Not sure who you're having a hard time convincing but send them to
heartbleed.com.  The first three paragraphs are for high flying executives
whose "business critical documents" are at risk.

> > For example: Gmail and Dropbox and Hotmail seem to be imune to this. I
> also found out that Mozilla/Firefox browser were also imune. If I would
> persuade someone of this bug's importance, which other examples could I
> give?
>
What type of person are you trying to persuade?  If you download any of the
vulnerability test scripts in the wild you'll notice that the 64k output is
truncated and the script simply states "you're vulnerable".  Edit that
script so that it dumps the full 64k.  While you're at it put that script
in an infinite while loop and dump the output to a file on disk.  Then use
Firefox or chrome or whatever browser you want and log in to the service.
When you're done search the file for your credentials.  It doesn't matter
what browser you're using.

> > 2) (specific question) Does Firefox use openssl to connect to some
> servers while browsing?
>
> No. Firefox is immune because it uses the NSS Crypto library.
>
I have verified this claim.  (Firefox Version: 28.0+build2-0ubuntu0.12.04.1)

$ dpkg -L firefox | while read x;do [ -f "${x}" ] && (if ldd "${x}"
2>/dev/null | grep libssl &>/dev/null;then echo "${x}";fi);done | while
read x;do echo "${x}";ldd "${x}" 2>/dev/null | grep libssl;done
/usr/lib/firefox/components/libmozgnome.so
        libssl3.so => /usr/lib/x86_64-linux-gnu/libssl3.so
(0x00007ffd9d836000)
/usr/lib/firefox/components/libdbusservice.so
        libssl3.so => /usr/lib/x86_64-linux-gnu/libssl3.so
(0x00007f778ceda000)
/usr/lib/firefox/libxul.so
        libssl3.so => /usr/lib/x86_64-linux-gnu/libssl3.so
(0x00007f326e660000)
/usr/lib/firefox/browser/components/libbrowsercomps.so
        libssl3.so => /usr/lib/x86_64-linux-gnu/libssl3.so
(0x00007fa4537f3000)
/usr/lib/firefox/plugin-container
        libssl3.so => /usr/lib/x86_64-linux-gnu/libssl3.so
(0x00007f0807de7000)

$ dpkg -S /usr/lib/x86_64-linux-gnu/libssl3.so
libnss3: /usr/lib/x86_64-linux-gnu/libssl3.so

If it was openssl then it would be linked to
/lib/x86_64-linux-gnu/libssl.so.1.0.0 which is a part of the libssl1.0.0
package which is a dependency of the openssl package.

> The issue typically exists on and affects servers. A server using an
> affected version of OpenSSL is vulnerable regardless of what browser
> clients use.
>
While it's true Firefox does not link openssl in binaries the vulnerability
allows an attacker to easily hijack sessions, steal usernames and
passwords, and steal the server private key during the SSL negotiation
phase.  See my comments above for how you can verify that.

> > 3) How about Ubuntu and other OSs? Do they use openssl to update
> themselves? (as in "apt-get update && apt-get upgrade").
>
> Ubuntu and Debian use GnuPG to sign packages but updates typically take
> place over unencrypted connections. The update mechanism is not affected by
> this bug.
>
True.  $ grep -rH 'http:' /etc/apt/sources.list*

I'm not sure who you're trying to convince, Felipe, but HOPEFULLY you have
already handled this bug by patching and added rules to your intrusion
detection system for packets trying to attack SSL using this method (the
attack packets look very different from normal SSL communication).

Pete, forgive me breaking down your reply but I found it a good exercise in
attempting to verify your claims.

Environment
KUbuntu 12.04.4 LTS
Linux 3.8.0-37-generic x86_64

SAM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140409/f7ec4391/attachment.html>