Netgear and the OpenSSL Heartbleed Vulnerability

[mediatrek]

I took the time and looked at the source code of a number of Netegar devices (see http://kb.netgear.com/app/answers/detail/a_id/2649/~/open-source-code-for-programmers-(gpl)). Anyone concerned about the OpenSSL Heartbleed Vulnerability, here are the versions of OpenSSL ran by select Netgear routers, storage devices and cable modems. The only devices vulnerable are those running the ReadyNAS OS version 6.1.6 or older. If users update to OS6.1.7 that was released Friday, April 11th, they will then be patched:


ROUTERS:
R7000 (v1.0.2.164): OpenSSL 0.9.8e
R6300v2 (v 1.0.2.86): OpenSSL 0.9.7f
R6300v1 (v1.0.2.70): OpenSSL 0.9.7f
R6250 (v.1.0.1.84): OpenSSL 0.9.8e
R6200v2 (v1.0.1.18): OpenSSL 0.9.2b
R6200v1 (v1.0.1.52): OpenSSL 0.9.7f
R6100 (v1.0.0.38): OpenSSL 0.9.8p
WNDR4700 (v1.0.0.52): OpenSSL 0.9.8p & CyaSSL 1.6.5
WNDR4500v2 (v1.0.0.42): OpenSSL 0.9.7f
WNDR4500v1 (v1.0.1.40): OpenSSL 0.9.7f
WNDR4300 (v1.0.1.60): CyaSSL 1.6.5
WNDR3800 (v1.0.0.48): OpenSSL 0.9.8e
WNDR3700v4 (v1.0.1.52): CyaSSL 1.4.1
WNDR3700v3: Unable to Determine
WNDR3700v2: Unable to Determine
WNDRMACv2 (v1.0.0.20): OpenSSL 0.9.8e
WNDRMACv1 (v1.0.0.22): OpenSSL 0.9.8e
WNDR3400v3 (v1.0.0.22): OpenSSL 0.9.7f
WNDR3400v2 (v1.0.0.44): OpenSSL 0.9.7f

STORAGE
Netgear Stora MS2000/MS2110 (v2.3.2): OpenSSL 0.9.8b
Netgear ReadyNAS OS v4.1.13: OpenSSL 0.9.8g
Netgear ReadyNAS OS v5.3.10: OpenSSL 0.9.8o
Netgear ReadyNAS OS6.1.6 or older: **VULNERABLE** Update to OS6.1.7 to patch

OTHERS
Netgear CMD31T Cable Modem: OpenSSL 0.9.8a
WNCE4004 (v1.0.0.32): OpenSSL 0.9.8k

 

[blogthis]

Thanks for such a great idea as this to get a definitive answer, especially while Netgear doesn't seem to be saying much on this topic just yet...

Regarding the Netgear R7000 Nighthawk and Heartbleed:

Did you mean FW 1.0.2.164 not 1.2.164, in your list?

Also, what about which OpenSSL/OpenVPN version is within the most current official Netgear OEM FW build 1.0.3.24 for the R7000, that almost everyone is now using??

It's available here:

http://downloadcenter.netgear.com/en/product/R7000

(I see that 1.0.3.24 version is in the source code link you provided, but I cannot read .tar)

Note: Many DDWRT / OpenRouter firmwares had this OpenSSL vulnerability, but DDWRT dated 4/10/14 and newer fixes this exploit by building with OpenSSL 1.0.1g.

p.s. I've always wondered, what is the difference between North America and WorldWide Netgear firmware for R7000? Is the NA version more encryption, if so, then why doesn't Netgear update the NA version with the latest bug fixes such as Beamforming added in 1.0.3.24?


Edit: Added DDWRT note and fix my typo's..

 

[mediatrek]

Blogthhis- Thank you for catching my typo on the firmware version. I edited my original posting correcting it.

You can extract the open source code using WinRAR (www.rarlabs.com) software. All I did was download the files from the link I provided in my original post, extract them using WinRAR (R7000 took about 14 minutes to extract), then examine it for the OpenSSL package used.

The difference in the US and WW (or other country specific) firmware releases are things like locking of channels allowed to work on. Here in the USA, on the 2.4Ghz band you can only transmit on channels 1 to 11. In Japan they can on 1 to 13, and only 802.11b can be on channel 14. Other parts of the world allow for channels 1 to 13. Basically the difference in firmware is to comply with country specific regulations.

I did download and extract the WW v1.0.3.24 open source package and it also uses OpenSSL 0.9.8e.

 

[blogthis]

Thanks for the fast reply and tips!

I'm unsure why the OpenSSL version I observe in this extracted firmware source code version 1.0.3.24, is different than the OpenSSL version you see?

Here are my own research notes, regarding Netgear R7000 Nighthawk and Heartbleed aka CVE-2014-0160: 7th April 2014 as within the official OEM Netgear R7000 World Wide (WW) Firmware Version 1.0.3.24 source code file, as published by Netgear (Latest 802.11ac WiFi Certified version as of 4/13/14), available here:

http://kb.netgear.com/app/answers/detail/a_id/2649/~/open-source-code-for-programmers-(gpl)


1.) The header of the following README file says, "OpenSSL 0.9.7f 22 March 2005"

R7000-V1.0.3.24_1.0.20_src.tar\R7000-V1.0.3.24_1.0.20_src\ap\gpl\openssl\README

(..not 0.9.8e..? is this the wrong file to determine version?)


2.) The code in the following version.m4 file says, "define([PRODUCT_VERSION], [2.3.1])"

R7000-V1.0.3.24_1.0.20_src.tar\R7000-V1.0.3.24_1.0.20_src\ap\gpl\openvpn-2.3.1\version.m4

(...is that right..?)


3.) According to openvpn.net's wiki, "Your OpenVPN is affected when your OpenVPN is linked against OpenSSL, versions 1.0.1 through 1.0.1f."

https://community.openvpn.net/openvpn/wiki/heartbleed


4.) According to openssl.org, these are effected versions:

http://www.openssl.org/news/vulnerabilities.html

"Bad" OpenSSL: 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1

(IMPORTANT: Apparently this vulnerability did NOT exist in earlier versions, and was Fixed in OpenSSL 1.0.1g...right?)


5.) According to openvpn.net, "All Windows users of OpenVPN 2.3-rc2-I001 through OpenVPN 2.3.2-I003 should upgrade their installations immediately.." [to version 2.3.3+]:

http://openvpn.net/index.php/download/58-open-source/downloads.html

(..does this mean the OpenVPN 2.3.1 in the R7000 1.0.3.24 is suspect..?)


6.) Bottom line RE: Official Netgear R7000 Nighthawk firmware version 1.0.3.24:

a.) R7000 OEM Firmware version 1.0.3.24, I found says it contains:
b.) OpenSSL version 0.9.7f
c.) OpenVPN version 2.3.1

If Netgear compiled above OpenVPN with above OpenSSL, then I guess (?) this particular firmware might maybe hopefully not be effected by said vulnerability? Unfortunately, maybe only Netgear can answer this definitively, and I'm currently unable to find an official statement from them yet... if you know of one, please link it.

As a related note.. Alternative DD-WRT firmware (aka Netgear official OpenRouter support) has confirmed YES they're effected by this particular vulnerablility for R7000 (and many other router models), so I read that DD-WRT users on Netgear R7000 Nighthawk should definitely upgrade to DDWRT builds compiled with OpenSSL 1.0.1g to address this particular issue immediately. Mostly those dd-wrt builds to fix this heartbleed-issue are dated April 10th 2014 or later, but it seemed to "depend" on particular build, so be sure to check their changelog to be sure!

So, what does all this mean? Should we upgrade to DD-WRT just so we know "for sure" what OpenSSL version is within the R7000? Our company is fairly concerned about this issue as is most of the internet, so much so all our VPN has been shut down since last Friday. I do appreciate and look forward to reading the next reply. I predict tomorrow will be a very long day..

Thank You again!

 

[mediatrek]

Personally for me from my previous testing using Netgear firmware, beyond pure performance metrics, the R7000 is a $200 paperweight and it went back to the retailer after my testing a few months ago. Issues like constant disconnects (or instant disconnects when connecting) of just about any device that used a Realtek chip, along with just about any device using a 1x1 802.11ac or 802.11n chip…. Even my Google Nexus 5 that uses a Broadcom AC chip. Using my ReadyNAS 312 and laptop with Intel’s 7260 AC 2x2 adapter, I got inconsistent throughput results on the 5GHz band. The graphs for how throughput jumped up and down looked like a rollercoaster.

As for the README file, it does state that, but I was told once to look at the CHANGES file in the same directory for the version #. As for OpenVPN, I already deleted the files from my drive and I don’t feel like waiting for it to extract again.
And, yes…. OpenSSL version versions 1.0.1 through 1.0.1f and 1.0.2-beta1 have the Heartbleed vulnerability.

 

[claykin]

Personally for me from my previous testing using Netgear firmware, beyond pure performance metrics, the R7000 is a $200 paperweight and it went back to the retailer after my testing a few months ago. Issues like constant disconnects (or instant disconnects when connecting) of just about any device that used a Realtek chip, along with just about any device using a 1x1 802.11ac or 802.11n chip…. Even my Google Nexus 5 that uses a Broadcom AC chip. Using my ReadyNAS 312 and laptop with Intel’s 7260 AC 2x2 adapter, I got inconsistent throughput results on the 5GHz band. The graphs for how throughput jumped up and down looked like a rollercoaster.

As for the README file, it does state that, but I was told once to look at the CHANGES file in the same directory for the version #. As for OpenVPN, I already deleted the files from my drive and I don’t feel like waiting for it to extract again.
And, yes…. OpenSSL version versions 1.0.1 through 1.0.1f and 1.0.2-beta1 have the Heartbleed vulnerability.

And the Asus 68u suffered from same with early firmware. Seems mostly thanks to Broadcom. The R7000 is quite good with current firmware

 

[blogthis]

Thanks again for the amazingly fast replies!

I see what you meant by the changelog within the source code, and it's not so comforting that maybe they didn't update the README... it makes me wonder WHAT version is really in there!

It seems like most if not all of the first-to-market 802.11ac routers with Broadcom chips (e.g. Asus, Netgear, LinkSys, etc), all had the same initial performance and reliability issues as R7000, due to the firmware's embedded Broadcom drivers as was confirmed by the good folks at the DD-WRT / OpenRouter project. This has since been fixed with updated Broadcom drivers built into the latest firmwares.

Don't get me wrong, I don't care about a particular vendor's brand per se, we just picked the R7000 due to superior hardware hoping any firmware issue would be ironed out which they were. Regardless, I feel performance and/or the occasional connection issues are not important compared to security issues - especially with VPN. Speaking of which, if anyone has more detail on the OpenSSL/OpenVPN issue specifically pertaining to Netgear's official R7000 OEM firmware, then I'd be very grateful (our company tends to avoid using vendor-unsupported projects, if possible).

Thank you all again.