31 replies to this topic

[SpaceRat]

As it seems, nobody cares ...

enigma2-plugin-systemplugins-hdmicec, enigma2-plugin-systemplugins-osdpositionsetup, enigma2-plugin-systemplugins-skinselector and other "important" parts were in more desperate need for an update ...

[littlesat]

Do you have a ready patch then???

[SpaceRat]

Do you have a ready patch then???

In theory, yes.

The only problem being the patches applied to OpenSSL 1.0.1e before building about which I do not know what they are good for or in other words: If they are still required/useful with OpenSSL 1.0.1g.

--- openssl_1.0.1e.bb   2014-03-16 00:43:53.589299400 +0100
+++ openssl_1.0.1g.bb   2014-04-10 10:59:05.144922300 +0200
@@ -37,8 +37,8 @@
             file://find.pl \
            "

-SRC_URI[md5sum] = "66bf6f10f060d561929de96f9dfe5b8c"
-SRC_URI[sha256sum] = "f74f15e8c8ff11aa3d5bb5f276d202ec18d7246e95f961db76054199c69c1ae3"
+SRC_URI[md5sum] = "de62b43dfcd858e66a74bee1c834e959"
+SRC_URI[sha256sum] = "53cb818c3b90e507a8348f4f5eaedb05d8bfe5358aabb508b7263cc670c3e028"

 PACKAGES =+ " \
        ${PN}-engines \

The problems are just the patches in ./openssl-1.0.1e that, when just being copied as ./openssl-1.0.1g, of course fail.

After getting OpenSSL 1.0.1g to compile properly, you can bumb OpenVPN to 2.3.3:

--- openvpn_2.3.2.bb    2014-04-10 10:21:33.952676200 +0200
+++ openvpn_2.3.3.bb    2014-04-10 11:18:24.468938800 +0200
@@ -10,8 +10,8 @@
 SRC_URI = "http://swupdate.openvpn.org/community/releases/openvpn-${PV}.tar.gz \
            file://openvpn"

-SRC_URI[md5sum] = "06e5f93dbf13f2c19647ca15ffc23ac1"
-SRC_URI[sha256sum] = "20bda3f9debb9a52db262aecddfa4e814050a9404a9106136b7e3b6f7ef36ffc"
+SRC_URI[md5sum] = "5c66ea3143ac884a3075521bd74ede06"
+SRC_URI[sha256sum] = "f025d14631105a66e501ca897830cd4d26a1438530cd9174dc6169536ae4b113"

 CFLAGS += "-fno-inline"
 

[SpaceRat]

And there is an even easier alternative:

"One of the possible mitigation steps is to recompile OpenSSL with the -DOPENSSL_NO_HEARTBEATS option to disable the vulnerable extension."

OpenSSL - Compile Flags vs Configuration Options - TLS Heartbeat

That's what Google did for Android, except version 4.1.1:

[SpaceRat]

Added option -DOPENSSL_NO_HEARTBEATS to OpenSSL 1.0.1e, recompiled, deployed
12.04.2014 18:17 137.778 libssl1.0.0_1.0.1e-r15.0_mips32el.ipk
12.04.2014 18:17 4.760 openssl-conf_1.0.1e-r15.0_mips32el.ipk
12.04.2014 18:17 181.182 openssl_1.0.1e-r16.0_mips32el.ipk

Check:
openssl s_client -connect ultimo:443 -tlsextdebug > heartbeat

Before:

CONNECTED(000001A0)
TLS server extension "renegotiation info" (id=65281), len=1
0001 - <SPACES/NULS>
TLS server extension "session ticket" (id=35), len=0
TLS server extension "heartbeat" (id=15), len=1
0000 - 01                                                .
---
Certificate chain
...

After:

CONNECTED(000001A0)
TLS server extension "renegotiation info" (id=65281), len=1
0001 - <SPACES/NULS>
TLS server extension "session ticket" (id=35), len=0
---
Certificate chain

So yes, a simple switch fixes the vulnerability.

--- openpli-oe-core/openembedded-core/meta/recipes-connectivity/openssl/openssl_1.0.1e.old	2014-04-12 17:34:17.169024482 +0200
+++ openpli-oe-core/openembedded-core/meta/recipes-connectivity/openssl/openssl_1.0.1e.bb	2014-04-12 17:33:49.565024089 +0200
@@ -4,7 +4,7 @@
 # if they are available.
 DEPENDS += "ocf-linux"
 
-CFLAG += "-DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS"
+CFLAG += "-DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DOPENSSL_NO_HEARTBEATS"
 
 PR = "${INC_PR}.0"
 

[realmic]

Thanks for updating!

 

tux@vuduo2:~# openssl version -a
OpenSSL 1.0.1e 11 Feb 2013
built on: Sun Apr 13 18:56:01 CEST 2014
platform: debian-mipsel
options:  bn(64,32) rc4(idx,int) des(idx,risc2,16,long) idea(int) blowfish(idx)
compiler: mipsel-oe-linux-gcc  -mel -mabi=32 -mhard-float -march=mips32 --sysroot=/dreambox/oe.openpli-4/build/tmp/sysroots/vuultimo -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN     -DTERMIO  -Os -pipe -g -feliminate-unused-debug-types -Wall -Wa,--noexecstack -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS
OPENSSLDIR: "/usr/lib/ssl"

./hb-test.py vuduo2
Connecting...
Sending Client Hello...
Waiting for Server Hello...
 ... received message: type = 22, ver = 0302, length = 58
 ... received message: type = 22, ver = 0302, length = 482
 ... received message: type = 22, ver = 0302, length = 4
Sending heartbeat request...
Unexpected EOF receiving record header - server closed connection
No heartbeat response received, server likely not vulnerable

[Robinson]

If I run an online update of OpenPLi tonight, will there be some security measures included or not?

Thanks.

[MiLo]

You will get the CVE-2014-0160 patch after an online upgrade.

Note that your system remains just as vulnerable to other, much simpler, attacks.

[Blusat]

You will get the CVE-2014-0160 patch after an online upgrade.Note that your system remains just as vulnerable to other, much simpler, attacks.

Is there a simple tutorial for newbies you would recommend in order to have a good level of protection ?

Thanks.

[SpaceRat]

Is there a simple tutorial for newbies you would recommend in order to have a good level of protection ?

Nope.

But it's rather easy to describe:

The most secure way is:

• Configure ssh for key auth (rather than login/pass)
• Install the OpenSSH-sftp-Server component
• Open only the port for ssh to the outside
• Use ssh directly for console access, sftp (ftp over ssh) for file access and tunnel everything else as needed through ssh (There are enough existing tutorials that explain ssh-tunneling, no need to repeat those here)
• This is as of now the most secure way to acess the box, but also the most inconvenient when it comes to the web interface and so on due to the ssh tunnel setup (Rather easy to set up on a PC, but ugly on a Smartphone, Tablet, whatever, where you more likely need remote access).
  
  Comparably secure is a VPN:
  • Establish a VPN, either between your external point of access and your home network, e.g. using your router's VPN functionality (if present) or directly between the external point of access and the E2 box itself, e.g. using OpenVPN.
  • Once the VPN is up and running, you should be able to use anything on the box like you would in your home LAN.
  Third option and MiLo will disagree:
  • Become your own CA root (Certificate root authority) using OpenSSL
  • Create server keys and certs signed by this CA root for OpenWebif, oscam, vsftpd ... (Tutorials can be found on the net too)
  • Add your personal "CA root" certificate to the repo of trusted root authorities on all your client device(s)
  • Feed your newly created, personal server cert(s) to OpenWebif (/etc/enigma2/key.pem and /etc/enigma2/cert.pem) and oscam /etc/tuxbox/config/oscam/oscam.pem (joined key.pem+cert.pem) and add /etc/tuxbox/config/oscam/oscam.pem to your oscam.conf, enable SSL in oscam
  • Get used to not ignoring SSL warning: Your server(s) have to show a green (in Chrome) or grey (in Firefox) "https" at the beginning of the URL, indicating that the browser trusts the server, which is due to the fact that it trusts your freshly installed CA root ... if the https becomes red or crossed out, it's not your server you are talking to, so do not send credentials
  • vsftpd in OpenPLi has been crippled not to allow secure connections, so do not use it across the net, use sftp (from ssh) instead
  • Log in to your box and create an additional user like this:
    adduser user -H -h /nowhere -s /bin/false
    or for example
    adduser Blusat -H -h /nowhere -s /bin/false
    setting a password different from that of root.
    Then in the future use this user to login to the Webif. As this user doesn't have shell access (/bin/false), nobody can log in to the shell even he ever manages to intercept or spy on the credentials for this user.
  • Never ever open these services to the outside world: telnet, ftp, http

[MiLo]

The third option is just as vulnerable as opening your 'plain' HTTP server, because it does not require you to provide any credentials before sending requests at the server.

SpaceRat also knows how to make it secure: Require a client certificate login. So I'm wondering why he didn't mention it.

The rest of his posting is indeed all true. You don't need to install openssh-ftp-server, you can use plain scp on Linux systems and the quite simple freeware tool WinSCP on windows systems for remotely copying files. You only need it for sshfs or sftp.

Edited by MiLo, 28 April 2014 - 19:05.

[SpaceRat]

You don't need to install openssh-ftp-server, you can use plain scp on Linux systems and the quite simple freeware tool WinSCP on windows systems for remotely copying files. You only need it for sshfs or sftp.

I recommended installing the sftp-server because it is much more widely supported, e.g. in FileZilla.


PS: Using client cert auth works, but it is not actually usable at the moment for a huge amount of users.
As long as neither Chrome on Android nor DreamDroid can handle it, it's not really an option.

I wish it was.