31 replies to this topic

[realmic]

Hello OpenPLi-Developers,


the current OpenPLi 4 image used OpenSSL 1.0.1e per default and now OpenWebIf (https), OpenSSH ,Dropbear(?), OpenVPN, every software uses these ssl libraries are in great danger!

 

I know, that a Linux receiver isn't a high secure server, but I think most users have remote access enabled and we should update OpenSSL to version 1.0.1g asap!

tux@vuduo2:~# openssl version
OpenSSL 1.0.1e 11 Feb 2013


tux@vuduo2:~# opkg list-installed
libssl0.9.8 - 0.9.8x-r15.0
libssl1.0.0 - 1.0.1e-r15.0
openssl - 1.0.1e-r15.0
openssl-conf - 1.0.1e-r15.0
python-pyopenssl - 0.13-r1

 

 

I have collected all important infos plus test tools here:

 

The Heartbleed Bug
http://heartbleed.com

 

OpenSSL Security Advisory [07 Apr 2014]
========================================

TLS heartbeat read overrun (CVE-2014-0160)
==========================================

A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server.

Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.

Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for
preparing the fix.

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

1.0.2 will be fixed in 1.0.2-beta2.

SOURCE: https://www.openssl....dv_20140407.txt
https://cve.mitre.or...e=CVE-2014-0160


[Test-Tools]

 

Web: heartbleed test
http://possible.lv/tools/hb/

 

Python-Script: OpenSSL heartbeat PoC with STARTTLS support
https://gist.github....eshixx/10107280

hb-test.py

 

------------------------------------------------------------------------------------

[OpenPLi 4 - OpenWebIf]
tux@vuduo2:~# opkg list-installed
enigma2-plugin-extensions-openwebif - 0.1+git613+19efb31-r7.72

 

 

OpenWebIf and HTTPS is active:

https://vuduo2.local

hb-test.py vuduo2.local

Connecting...
Sending Client Hello...
Waiting for Server Hello...
 ... received message: type = 22, ver = 0302, length = 58
 ... received message: type = 22, ver = 0302, length = 483
 ... received message: type = 22, ver = 0302, length = 4
Sending heartbeat request...
 ... received message: type = 24, ver = 0302, length = 16384
Received heartbeat response:
  0000: 02 40 00 D8 03 02 53 43 5B 90 9D 9B 72 0B BC 0C  .@....SC[...r...
..
  3ff0: 0F 03 00 00 10 60 86 02 2E 00 00 00 00 00 00 00  .....`..........

WARNING: server returned more data than it should - server is vulnerable!


[OpenPLi 4 - OpenSSH]
tux@vuduo2:~# ssh -V
OpenSSH_6.4p1, OpenSSL 1.0.1e 11 Feb 2013


[OpenPLi 4 - OpenVPN]
tux@vuduo2:~# opkg list-installed
openvpn - 2.3.2-r0

Info: OpenVPN 2.3.3 Update is available!
https://community.op...ngesInOpenvpn23



Best regards
Michael
 

[realmic]

Hi, update for OpenSSH..

 

Is SSH affected?

No. Although OpenSSH uses the OpenSSL library for the use of cryptographic algorithms, but the heartbeat extension is a pure TLS matter. Programs, that use OpenSSL cryptography code, but implement other protocols such as SSH for example, are not affected.

 

SOURCE: golem.de

[Marc-UK]

OpenPLI developers,

 

Any update on this?

 

Can we expect a fix? Any time soon?

 

Thank you

[littlesat]

Is SSH affected?

No. Although OpenSSH uses the OpenSSL library for the use of cryptographic algorithms, but the heartbeat extension is a pure TLS matter. Programs, that use OpenSSL cryptography code, but implement other protocols such as SSH for example, are not affected.

[Sjaaky]

Is the webinterface affected?

Yes. So we should update.

Edited by Sjaaky, 10 April 2014 - 17:31.

[littlesat]

So do not share the webinterface directly from the WWW for now!

[WanWizard]

@Sjaaky,

 

Yes, it is.

 

And not only do we need to update OpenSSL, we should also assume that the device running the vulnerable library is indeed compromised, and public/private keypairs are obtained. Since the box comes by default with such a keypair, it has always been insecure (since the private key is publically available in every image it could always be obtained), and we should also implement (or document) a way to generate a unique keypair, and a new self-signed certificate.

 

As littlesat states, it has always been OpenPLi's policy never to expose the webif to the internet because of it's insecurities, but a lot of people seem to ignore that, and assume that when they see https://, everything is safe. This just proves that it isn't.

[littlesat]

You can also tunnel the webinterface via SSH... 

[WanWizard]

You can... You should...

[SpaceRat]

OpenVPN suffers from the same vulnerability ...

So what's your point?

[littlesat]

openVPN does.... SSH not...

[SpaceRat]

BTW:
I tried to change the bitbake recipe for OpenSSL to version 1.0.1g, of course the patches fail (Wonder what they all are good for ...) but OpenSSL 1.0.1g compiles fine else.
So yes, it can be fixed, rather than trying to discuss the vulnerability away ...

However, it won't be enirely painless: As about EVERYTHING links against OpenSSL - and if it doesn't, it links against anything which does - almost everything gets rebuilt ...
But the fact that changing the OpenSSL version results in almost the whole image and feed to be rebuild just proves there might be more holes you didn't even think about yet ...

[SpaceRat]

openVPN does.... SSH not...

Well, OpenVPN is one of those oftenly proposed as "o so secure" alternative to opening the web interface.

Please do not discuss, push an update.
It's not like you had to code it yourself, it's just a version bump on OpenSSL.

[WanWizard]

You can't deduct one from the other.

 

The vulnerability is specific to TLS, which is only used in HTTPS transport, and in some authentication protocols, such as EAP-TLS (in a 802.1x scenario). OpenSSL has a lot more functionality, on which for example SSH relies, but that doesn't mean SSH is vulnerable.

[SpaceRat]

I didn't deduct anything, I just pointed out that OpenVPN is vulnerable too.

I'm just pointing out the absurdity of the oftenly proposed "secure" alternatives to opening the https Web Interface.
The https Web Interface - when configured properly - is secure ... as secure as the underlying code or libraries, just as for OpenVPN.

For now, OpenSSH isn't affected ... but sooner or later also the https Web Interface and OpenSSH will share a security vulnerability.

There never was, is or will be absolute security in code written by failable humans. Security can only be gained by pulling the plug.

[WanWizard]

I was responding to the post before that, about compilation and dependencies.

 

openVPN does.... SSH not...

Well, OpenVPN is one of those oftenly proposed as "o so secure" alternative to opening the web interface.

 
Yes. And I my case it is, my OpenVPN is built against 1.0.0-fips, which doesn't have this vulnerability. So it's still "o so secure"... So it's not as black and white as you say.

 

Please do not discuss, push an update.
It's not like you had to code it yourself, it's just a version bump on OpenSSL.

Neither Littlesat nor I are core dev's, so you're barking up the wrong tree.

 

But don't worry, it's being looked at. Don't forget this is a hobby, we have to work too. And in my case, this issue has kept me from sleeping the last two days due to communication with the prime minister, CERT, the public and the press, and a 20-man team running around checking, patching and replacing certificates. So don't tell me I'm not aware of the seriousness of the situation.

Since you're so loud about it, you have your webif exposed on the internet? Did you replace the private/public keypair, and did you replace the certificate? Because if not, you were exposed from day 1, even without this vulnerability, and you should do so immediately.

[SpaceRat]

webif exposed on the internet? Did you replace the private/public keypair, and did you replace the certificate? Because if not, you were exposed from day 1, even without this vulnerability, and you should do so immediately.

Of course.
I became my own root CA authority, installed that root cert on all machines accessing any other machine and created seperate key pairs for all my machines.

So yes, I get a green https when accessing the boxes .... and a red one even if I just access the wrong one¹ ...

Happy?

¹like 99.9% of all private customers, I got only 1 IPv4 for my whole network, so the different hostnames for my boxes point to different IPv6s but the same IPv4. When a program fails to resolve to an AAAA record, access might end up on the other box and my browser barks at me for accessing a web site which might be counterfeit, as it has the WRONG cert for the hostname I tried to open.

[WanWizard]

Cool! Wish more people were so security aware.

 

I've spend most of my day trying to explain to people what all the fuzz is about. And that includes a lot of ICT people...

[realmic]

Hi, here is a "Workaround" for OpenVPN 2.3.2!

 

Please, activate "tls-auth" on server and client:

 

#/etc/openvpn/server.conf

..
tls-auth ta.key 0 # This file is secret
auth SHA256
..

cipher AES-256-CBC   # AES
keysize 256


#/etc/openvpn/client.conf

..
tls-auth ta.key 1 # This file is secret
auth SHA256
..

cipher AES-256-CBC   # AES
keysize 256

 

 

 

But this is only a temp. solution!

[realmic]

#I) Easy-RSA OpenVPN-Server - Generate a secret Hash-based Message Authentication Code (HMAC) by running:
openvpn --genkey --secret ta.key