ROS 6, OpenSSL, and package updates?

OpenSSL 1.0.1e is over a year old. It does not fix the latest TLS bug reported today (CVE-2014-0160, aka "Heartbleed"). All versions of OpenSSL 1.0.1 before 1.0.1g are vulnerable, as are the 1.0.2 betas up to and including 1.0.2-beta1.

The 1.0.0 and 0.9.8 branches are NOT affected, although of course they have other vulnerabilities and non-security bugs that have been fixed in the later versions.

ReadyNAS devices running OS4 are unaffected by the new bug; they're running 0.9.8o at best. I don't know what version of OpenSSL is running on the OS5 devices.

Yeah, I was reading more about the patch and realized it's 1.0.1g that has the fix. So ROS 6.1.6 is definitely vulnerable.

My RN102 is running OpenSSL 1.0.1e as part of OS6.1.6,
Can we upgrade it by hand or do we have to wait for an update from Netgear?

I wouldn't wait for an update. With Netgear's average speed of updating, you'll be waiting for months.

Download either the AMD64 or i386 package depending on the architecture of your NAS. To find out which one you need, log in to SSH on your device and type "uname -m". If that returns "x86" take the i386, if it returns "x86_64" use the AMD64 version.

AMD64: http://security.debian.org/debian-secur ... _amd64.deb
i386: http://security.debian.org/debian-secur ... 5_i386.deb

While in SSH, enter the following commands:
AMD64:

wget http://security.debian.org/debian-security/pool/updates/main/o/openssl/openssl_1.0.1e-2+deb7u5_amd64.deb
dpkg -i openssl_1.0.1e-2+deb7u5_amd64.deb
service apache2 restart
service ssh restart

i386:

wget http://security.debian.org/debian-security/pool/updates/main/o/openssl/openssl_1.0.1e-2+deb7u5_i386.deb
dpkg -i openssl_1.0.1e-2+deb7u5_i386.deb
service apache2 restart
service ssh restart

You're good to go.

Don't those two options both re-install the current (insecure) version - 1.0.1e?
I believe the fixed version is 1.0.1g, which I don't see anywhere.

Yeah according to http://heartbleed.com/, "Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4" is considered unsafe. It wouldn't appear the package version in the links is any different.

I'm on RN102 (ReadyNas Duo v2?) where # uname -a gives (<masked>):
Linux <HOSTNAME> 3.0.101.RN_ARM.1 #1 <INSTALLDATE> armv7l GNU/Linux

Looking at the Debian ports there are "armel" and "armhf" variants, and from https://wiki.debian.org/ArmHardFloatPort#Name_of_the_port I think it is armhf I would need.

But as alanwsg already pointed out it seems we still need to wait for a 1.0.1g package. Or is it feasible to compile from source? Searching for arm compilation I mostly found cross-compling howtos. Is it as simple as extracting the source of openssl in a directory, and running make? Will that screw up future web-GUI ReadyNAS upgrades?

Reading https://www.debian.org/security/2014/dsa-2896 and https://security-tracker.debian.org/tracker/CVE-2014-0160
I have to guess Debian backported the fix to the above linked versions, so although their names contain "1.0.1e" the suffix "+deb7u5" seems to mark a version patched with the fix yesterday. The +deb7u6 released today presumably still contains the fix but I didn't see any clear statement about it. Thus alanwsg, btaroli and I were probably wrong in our last comments.

The steps I now took to upgrade my ReadyNas RN102 were (as root):
Edit /etc/apt/sources.list to append "deb http://security.debian.org/debian-security wheezy/updates main" on a new line. (Since I have a plain install I had to use the vi editor, http://www.cs.fsu.edu/general/vimanual.html)
# apt-get update
# apt-get install openssl/wheezy
(An apt-get upgrade did not select openssl, presumably due to the pinning -- http://jaqque.sbih.org/kplug/apt-pinning.html)
# apt-get install libssl1.0.0/wheezy
(I did not install libssl-dev, libssl-doc or libcrypto++9 since they first two were not previously installed and the latter under a lower version number, maybe before the bug was introduced.)

hma9 wrote:
I have to guess Debian backported the fix to the above linked versions, so although their names contain "1.0.1e" the suffix "+deb7u5" seems to mark a version patched with the fix yesterday. The +deb7u6 released today presumably still contains the fix but I didn't see any clear statement about it. Thus alanwsg, btaroli and I were probably wrong in our last comments.

Yes, versions 1.0.1e-2+deb7u5 and 1.0.1e-2+deb7u6 contain the fix. From the changelog:

openssl (1.0.1e-2+deb7u6) wheezy-security; urgency=high

  * Non-maintainer upload by the Security Team.
  * Enable checking for services that may need to be restarted
  * Update list of services to possibly restart

 -- Salvatore Bonaccorso <carnil@debian.org>  Tue, 08 Apr 2014 10:44:53 +0200

openssl (1.0.1e-2+deb7u5) wheezy-security; urgency=high

  * Non-maintainer upload by the Security Team.
  * Add CVE-2014-0160.patch patch.
    CVE-2014-0160: Fix TLS/DTLS hearbeat information disclosure.
    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.

 -- Salvatore Bonaccorso <carnil@debian.org>  Mon, 07 Apr 2014 22:26:55 +0200

I need to update an NV+ (v1). It would seem I need to do this:

wget http://security.debian.org/debian-security/pool/updates/main/o/openssl/openssl_1.0.1e-2+deb7u5_ sparc.deb
dpkg -i openssl_1.0.1e-2+deb7u5_sparc.deb
/etc/init.d/apache2 restart
/etc/init.d/ssh restart

But before I mess things up, I'm hoping someone can let me know if this will work.

Thanks.