Heartbleed bug

[Brian Sherson]

First question: Is SAGE notebook susceptible to the Heartbleed bug when
run with secure=True?

Secondly, if so, would any connection that attempts to exploit that bug
necessarily show up in the console?

~Brian

[William Stein]

On Sun, Apr 13, 2014 at 12:22 PM, Brian Sherson <caret...@gmail.com> wrote:
> First question: Is SAGE notebook susceptible to the Heartbleed bug when run
> with secure=True?

It depends. Yes... unless you have a new version of the openssl
library. It depends a lot on how/where you built Sage and the sage
notebook. Did you install the optional openssl sage package?

> Secondly, if so, would any connection that attempts to exploit that bug
> necessarily show up in the console?

No -- that's a subtle bug - it makes it possible to steal random
content from the RAM of the server without anyone being the wiser.
What the exploit does with the stolen data (a private key, a password,
etc.) is up to them.

Heartbleed is unbelieviably stomache-churning terrifying...



William

>
> ~Brian
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-support...@googlegroups.com.
> To post to this group, send email to sage-s...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-support.
> For more options, visit https://groups.google.com/d/optout.



--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

[kcrisman]

On Sunday, April 13, 2014 3:46:57 PM UTC-4, William wrote:

On Sun, Apr 13, 2014 at 12:22 PM, Brian Sherson <caret...@gmail.com> wrote:
> First question: Is SAGE notebook susceptible to the Heartbleed bug when run
> with secure=True?

It depends.  Yes... unless you have a new version of the openssl
library.   It depends a lot on how/where you built Sage and the sage
notebook.  Did you install the optional openssl sage package?

Which is basically one of the affected versions - openssl-1.0.1c.p0.spkg - Maybe we can update that spkg?  Would that be pretty easy to do? 

[William Stein]

I think we should consider just deleting the openssl spkg. Let people
who want ssl support install their vendor's devel library, and I think
the Python in Sage will link against it when it is built.

Us providing openssl at all is a little unpleasant, just because of
the GPL-incompatible license (though it's legal since it's an optional
package). I'm surprised to have personally not seen anything in the
online discussions about heartbleed about how the openssl license is
GPL-incompatible, which causes a lot of headaches. I've always been
annoyed at their license choice. For a long time, we shipped GNUtls
with sage (an alternative to openssl).

That said, even if we plan to update it, for now I think we should
delete the openssl spkg asap anyways, since it contains the
vulnerability. In fact, I think that so much, I'm going to delete it
from

http://sagemath.org/packages/optional/

right now [...] OK, it is now gone.

Wiliam

-- William

[Jori Mantysalo]

On Mon, 14 Apr 2014, William Stein wrote:

> That said, even if we plan to update it, for now I think we should
> delete the openssl spkg asap anyways, since it contains the

> vulnerability. - - it is now gone.

So what should one do to existing installations? After removing several
*ssl* files and directories

./sage -f pyopenssl

seems to still ba able to find and compile local openssl, not system-wide.

--
Jori Mäntysalo

[leif]

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to
immediately
upgrade can alternatively recompile OpenSSL with
-DOPENSSL_NO_HEARTBEATS.

(See https://www.openssl.org/news/secadv_20140407.txt )


Hence you could do

env CFLAGS="... -DOPENSSL_NO_HEARTBEATS" ./sage -f openssl

and

./sage -f pyopenssl

or

env SAGE_UPGRADING=yes make build

afterwards.

But looking at the 1.0.1a spkg (all later ones apparently vanished), the
first step might not work out of the box, i.e., you'd have to slightly
modify its spkg-install file (bash script), changing

make # in 1.0.1c and later, this line is "$MAKE"

to

$MAKE CFLAGS="$CFLAGS"

or, while we're at it, directly and once for all

$MAKE CFLAGS="$CFLAGS -DOPENSSL_NO_HEARTBEATS"

since otherwise OpenSSL's Makefile will presumably override the settings
from your environment. (I'm not sure what changed in the 1.0.1f.p0 spkg
version; probably you wouldn't have to modify that.)


Or you could try -- no guarantees that this works at all (with the
current pyOpenSSL spkg, say) -- using

./sage -f http://sagemath.org/packages/archive/openssl-1.0.0.p0.spkg

(and reinstalling pyopenssl etc. as above); versions prior to and
including 1.0.0 didn't have the heartbeat TLS extension.


In any case, don't forget to restart any running services using that
OpenSSL library.


-leif

P.S.: I'll probably provide a modified and / or updated OpenSSL spkg
later; to use a system-wide OpenSSL library from your distro, say, after
having built and used Sage's before, you'd have to delete some libraries
in $SAGE_ROOT/local/lib/, and presumably have to afterwards
rebuild/reinstall the Python spkg (not sure about that), and reinstall
PyOpenSSL.

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail

[Jori Mantysalo]

On Tue, 15 Apr 2014, leif wrote:

> Hence you could do
>
> env CFLAGS="... -DOPENSSL_NO_HEARTBEATS" ./sage -f openssl
>
> and
>
> ./sage -f pyopenssl
>
> or
>
> env SAGE_UPGRADING=yes make build
>
> afterwards.
>
> But looking at the 1.0.1a spkg (all later ones apparently vanished), the
> first step might not work out of the box, i.e., you'd have to slightly modify

> its spkg-install file (bash script), changing - -
>
> $MAKE CFLAGS="$CFLAGS -DOPENSSL_NO_HEARTBEATS"

Didn't work, complained about missing e_os.h. "#include "e_os.h" should
have been "#include "../e_os.h", I guess.

However, I ended up compiling all from scratch. At least now it works
again.

(Btw, If you start notebook before python-ldap is installed it seems to
set "Use LDAP Authentication" option to off; atfer installing
python-ldap I had to re-check that option. Fortunately LDAP server
settings are not cleared in this.)

--
Jori Mäntysalo

[kcrisman]

On Tuesday, April 15, 2014 6:40:10 AM UTC-4, jori.ma...@uta.fi wrote:

On Mon, 14 Apr 2014, William Stein wrote:

> That said, even if we plan to update it, for now I think we should
> delete the openssl spkg asap anyways, since it contains the
> vulnerability. - - it is now gone.

At least as a template for making sure it had the right configuration ... having an spkg is good.  Hopefully Leif's will be a good replacement.