-- did they REALLY update the package but not change the version number?
The remediation options (see notes at http://heartbleed.com/ ... Reading IS fun!) were to upgrade to 1.0.1g or rebuild on existing version with an option to disable the problematic TLS heartbeat function. This is the latter. It also makes it a bit confusing since you'll see new revisions of what appears to be the same OpenSSL package. I hesitate to call it a patch when it's just a new alternate build, but it's certainly fixed. 😉
But this is why you need to verify the build date, since just looking at the package version may not be enough.
And if you are (wisely) planning to change passwords, don't do it until you (or any affected website) have applied a fixed build AND have applied new site keys -- since /private/ keys may have been leaked and there's no way to be sure they weren't.
Don't forget that all services that use SSL have to be restarted. This includes software packages that set up their own secure https connections. If you're unsure, just reboot your nas after applying the patch.
Here is what I did for my OS 6.1.6 on a legacy atom (amd64). Thanks especially goes to MueR, fastfwd & super-poussin. A disclaimer : if you are unsure of anything ask the gourous here on the forum, or have a look on : http://www.siteground.com/tutorials/ssh ... leting.htm note: Please tell if you find any mistake or if something wasn't clear.
STEP 0: checking what you have and if you really need to do anything at all :
root@NAS:~# dpkg -l | grep openssl ii openssl 1.0.1e-2+deb7u3 amd64 Secure Socket Layer (SSL) binary and related cryptographic tools root@NAS:~# openssl version -b built on: Mon Jan 6 19:32:28 UTC 2014
STEP 1: 'upgrading' openssl to deb7u11 (note that it would be different for other hardware or other readynas OS version), and maybe restarting apache & ssh.
root@NAS:~# dpkg -l | grep openssl ii openssl 1.0.1e-2+deb7u11 amd64 Secure Socket Layer (SSL) binary and related cryptographic tools root@NAS:~# openssl version -b built on: Mon Jan 6 19:32:28 UTC 2014
STEP 2: do the same for libssl (eventually check with dpkg -l | grep libssl), and restart apache2 & ssl :
wget http://security.debian.org/debian-security/pool/updates/main/o/openssl/libssl1.0.0_1.0.1e-2+deb7u11_amd64.deb dpkg -i libssl1.0.0_1.0.1e-2+deb7u11_amd64.deb service apache2 restart service ssh restart
STEP 3: via web interface go to System>Settings>Services, click on HTTPS & change the name in order to regenerate the certificates. Then delete the keys in /etc/ssh/ (ssh_host_xxxx files), & delete also files in /root/.ssh . Optional : after deleting with the rm command, check with the ls command (just to be sure).
then CHANGE your root password only after you finished the whole process (there is no way to tell if the keys were not leaked). Final check on a test tool http://filippo.io/Heartbleed/
updated 20th June 2014 : openssl_1.0.1e-2+deb7u5_amd64.deb changed for "deb7u11" (dated 4 June 2014) and libssl1.0.0_1.0.1e-2+deb7u6_amd64.deb for "deb7u11". cf : https://security-tracker.debian.org/tra ... -2014-0224
I installed the patch and rebooted my ReadyNAS 312. Although I show this:
# dpkg -l openssl Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-======================-================-================-================================================== ii openssl 1.0.1e-2+deb7u6 amd64 Secure Socket Layer (SSL) binary and related crypt # openssl version -b built on: Mon Jan 6 19:32:28 UTC 2014
a Heartbleed test program says that it is still vulnerable.
I have the same problem as yours : the test page http://filippo.io/Heartbleed/ give me 1 third of green ok and 2/3 of red still vulnerable. After reading the FAQ, I think I am still vulnerable 😕
I have the same problem as yours : the test page http://filippo.io/Heartbleed/ give me 1 third of green ok and 2/3 of red still vulnerable. After reading the FAQ, I think I am still vulnerable 😕
Right. The directions that you posted earlier are incomplete: Both the openssl package and the libssl1.0.0 package must be updated.
I'd like to temperate a bit. Yes you NAS are vulnerable unless fully patched (in security, the overall security level is the one of the weakest link). That said I don't see anyone wanting to put some effort hacking a single NAS in an unknown network. If you use them in enterprise, they don't have access to internet, so danger comes only from insiders (yep I know most of critical attacks on an information system come from inside). On top of that I read this : http://www.theverge.com/2014/4/11/56043 ... -after-all
So if you want to patch, do it, that's always a good idea to be fully patched. Otherwise I think you'll need to wait a month at least to get official patch unless it's been silently released under 6.1.7 security fix section. (6.1.7 has gone final today, so no RC6 to fix it and I don't think 6.2.0 will be released in april, I may be wrong though).
I'd like to temperate a bit. Yes you NAS are vulnerable unless fully patched (in security, the overall security level is the one of the weakest link). That said I don't see anyone wanting to put some effort hacking a single NAS in an unknown network. If you use them in enterprise, they don't have access to internet, so danger comes only from insiders (yep I know most of critical attacks on an information system come from inside). On top of that I read this : http://www.theverge.com/2014/4/11/56043 ... -after-all
So if you want to patch, do it, that's always a good idea to be fully patched. Otherwise I think you'll need to wait a month at least to get official patch unless it's been silently released under 6.1.7 security fix section. (6.1.7 has gone final today, so no RC6 to fix it and I don't think 6.2.0 will be released in april, I may be wrong though).
Did the 6.1.7 update before and I think its patched (I did not upgrade the packages myself so must have been the firmware).
root@e1:~# dpkg -l | grep ssl ii libssl1.0.0:armel 1.0.1e-2+deb7u6 armel SSL shared libraries ii openssl 1.0.1e-2+deb7u6 armel Secure Socket Layer (SSL) binary and related cryptographic tools
root@e1:~# openssl version -b built on: Tue Apr 8 10:12:55 UTC 2014
Checked one minute ago (I always check backups before upgrading firmware), same result here, aptitude doesn't have any updated version either. So yes may be fixed (silently like suggested in my post). I can't take heart bleed test since my NAS isn't internet accessible so the tester will have a firewall drop packet and will say I'm good to go no matter the openssl version I have 😉
Even my NAS is not exposed to the internet so I'd to use a python script to check the status of vulnerability. There are tons of scripts that can help you check the status, and I used this one - https://gist.github.com/anantshri/10238615
But as alanwsg has suggested, 6.1.7 seem to fix the vulnerability. Check the screenshot, redacted some sensitive information 'universe' is hostname of my NAS if anyone is wondering.
Then I'm following the steps by arnomc - http://www.readynas.com/forum/viewtopic.php?f=65&t=75947&start=15#p423049 from STEP 3
Sounds like they must have quickly added this fix and hurried 6.1.7 out (they may have even held back 6.1.7 if it was otherwise ready for release earlier to include this fix) to address this serious security issue ASAP.
Well, knowing the OS6 is also for pro hardware, they should have received many calls concerning this. Adding a packet already made isn't something hard when you build a firmware... That's always better to say once "it's been fixed in the last update" than to say 5 times per consumer "it will be fixed in the last update". That said, I would have liked Netgear to find a way to validate debian packages to get real time updates (or delayed by up to three days for quick testing). I don't have any way to do this without manual testing though (so one man dedicated for the task) so this may not be economically possible.
Since this kept coming up as a question, I thought I'd share the content of an email I received from Netgear this evening.
Basically 4.x and 5.x users have nothing at all to worry about.
NETGEAR has taken steps to prevent compromise of ReadyNAS devices by the Heartbleed bug with the release of new firmware. Please upgrade your ReadyNAS to the latest firmware (6.1.7 or higher), which is available from your ReadyNAS management interface or can be downloaded from the NETGEAR support site (http://kb.netgear.com/app/answers/detail/a_id/20684). Earlier ReadyNAS models (pre-OS 6) use a version of OpenSSL that is not affected by Heartbleed.
We recommend the 6.1.7 Firmware Upgrade for the following models:
RN102/RN104 Series RN312/RN314/RN316 Series RN516 Series RN716 Series RN2120 RN3220 RN4220
