No sooner do I read this evening that Fedora and others a re quickly working to get OpenSSL 1.0.1e out to fix the latest TLS bug that I log into my 516 to see what version it's running. Oh my, 1.0.1e. When did that happen? Are there magic upgrade faeries on the NAS? 😄
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.
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.
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.)
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:
* Non-maintainer upload by the Security Team. * Enable checking for services that may need to be restarted * Update list of services to possibly restart
* 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.
The bug fixes started rolling out yesterday (7 April 2014), so if you haven't updated OpenSSL manually you are not secure.
That is correct.
StephenB wrote:
I am also confused on how 1.0.1e-2+deb7u5 and 1.0.1e-2+deb7u6 relate to 1.0.1g.
OpenSSL is its own project; it released 1.0.1e a year ago. Shortly thereafter, the Debian project maintainers incorporated it into their Linux distro.
The OpenSSL project released 1.0.1g yesterday, and the Debian project will undoubtedly incorporate that version into the next release of Debian Linux. But it would be imprudent for them to update the earlier, already-released versions of Debian (like "Wheezy", the version used by the ReadyNAS OS6 devices) to 1.0.1g without significant testing, because over the last year many other changes were made between 1.0.1e and 1.0.1g. That testing would take a lot of time, but the bug is serious and should be fixed immediately.
Fortunately, the fix is very straightforward -- just a couple lines of code -- so the Debian Security team decided that it was safe to make just that one bugfix change to Wheezy's 1.0.1e (without adding any of the other changes made to Open SSL over the last year). They released the slightly-modified 1.0.1e as 1.0.1e-2+deb7u5 yesterday, then made some minor tweaks to it today and released that as 1.0.1e-2+deb7u6. Both those versions contain the crucial bugfix; the latter one also handles service-restarts better.
You can see the list of other major changes between 1.0.1e and 1.0.1g by looking at the OpenSSL release notes here: http://www.openssl.org/news/openssl-1.0.1-notes.html. I posted the Debian changelog for 1.0.1e-2+deb7u5 and 1.0.1e-2+deb7u6 in an earlier message.
Yes, though the guidance from heartbleed.com is to use 1.0.1g. I'm unclear as to what other changes might be missing from 1.0.1e-2+deb7u6.[/quote]
Debian are after all famously conservative 😄 Security fixes are always backported though. The version of OpenSSL I use on OS4 was too old to be affected... :roll:
For wheezy (which 6.1.6 falls into) it's fixed in 1.0.1e-2+deb7u5. I'm not sure which major release NV+ and 5.x systems run. Patching it may (for some older systems) come down to Netgear? Not sure.
Don't necessarily go by package version, though. Build is safer. But in general, check the CVE report from each distro to be absolutely sure.
I've applied the deb7u5 openssl to my 6.1.7 installation, as described earlier, and it seems to have worked OK. Strangely, "openssl version" still reports "11 Feb 2013" but the build is dated 07-APR-2014 20:32:27 UTC.
If my RN102 says "1.0.1e 11 Feb 2013" when I run "openssl version" .... -- how do I know if I'm running the patched version? -- if I update it as described earlier, how will I know if it's worked? -- how do I view the build number? -- did they REALLY update the package but not change the version number?
-- how do I view the build number? -- did they REALLY update the package but not change the version number?
openssl version -a will give you the build date.
It's not a new "version", per se. It's a patched old version. Debian is not bleeding edge. If you want bleeding edge, you will be ill served by "Debian stable", but there is the "Debian testing" release. Typically Debian users are looking for extreme stability and longevity.
If my RN102 says "1.0.1e 11 Feb 2013" when I run "openssl version" .... -- how do I know if I'm running the patched version? -- if I update it as described earlier, how will I know if it's worked? -- how do I view the build number? -- did they REALLY update the package but not change the version number?
