Consider disabling UPNP by default

[metamul]

It might be controversial to say this, but I'd like to suggest that Asuswrt-Merlin disable UPNP by default. See, for example:

https://community.rapid7.com/commun...s-in-universal-plug-and-play-unplug-dont-play

http://www.kb.cert.org/vuls/id/922681

http://www.upnp-hacks.org/

It's just a suggestion; I have no dog in this fight.

 

[RMerlin]

Considering this router (and my firmware) target the average home user, uPNP is something that is expected to work out-of-the-box by users. Disabling it would lead to too many support requests about "why is xyz no longer working correctly?".

Also note that many of those disclosed vulnerabilities are about very specific uPNP implementations. Broadcom's own uPNP implementation for example is one often targetted by those discovered flaws. This, however, does not affect Asuswrt or Tomato, as both of these use a totally different uPNP stack - miniupnpd - which is actively developed and maintained. Asuswrt-Merlin and many Tomato builds both run the very latest version released only a few months ago. Asus's original FW runs an older version, but I know that at least the highly publicised uPNP flaws from a few months ago were NOT exploitable in that version either.

 

[metamul]

I understand the argument about home users. You could just as easily say, though, that UPnP is especially dangerous in the hands of an average home user who doesn't understand the potential risks or how to defend against them.

Here's a list of known MiniUPnPd vulnerabilities from January of this year:

http://www.cvedetails.com/vulnerabi...duct_id-24263/Miniupnp-Project-Miniupnpd.html

Here's a press release from UPnP Forum from February of this year:

http://www.marketwire.com/press-rel...ed-libupnp-miniupnp-security-flaw-1754771.htm

It contains this interesting snippet:

"Please note that other issues have been identified in the latest version of MiniUPnP, 1.4, but they won't be publicly disclosed until the library's developer releases a patch to address them, so we advise caution on any further usage of this stack until such time."

There's an interesting (and old) discussion about MiniUPnPd vulnerabilities here:

http://miniupnp.tuxfamily.org/forum/viewtopic.php?t=435

It discusses in part a particularly devious proof-of-concept attack using Flash. Basically: a user visits a web site, the web site contains a bit of Flash code, the Flash code runs inside the user's browser--and therefore inside the user's network. Because it's inside the user's network the code can configure the user's router via UPnP. I don't know if that particular hole is still open, but it gives you a sense of the potential risk. The key problem is the one my original links pointed out: UPnP has no authentication, so anyone with physical access can do anything they want. Well: anything UPnP allows.

Again, this is/was just a suggestion. I understand the conundrum. I'm just supplying a bit more background material.

 

[RMerlin]

I understand the argument about home users. You could just as easily say, though, that UPnP is especially dangerous in the hands of an average home user who doesn't understand the potential risks or how to defend against them.

Here's a list of known MiniUPnPd vulnerabilities from January of this year:

http://www.cvedetails.com/vulnerabi...duct_id-24263/Miniupnp-Project-Miniupnpd.html

Those are all about 1.0, or "before 1.4", so none of these affect Asuswrt or Tomato, so looks like CVE didn't disclose any vulnerabilities affecting 1.4 or newer, which is what we all use.

Here's a press release from UPnP Forum from February of this year:

http://www.marketwire.com/press-rel...ed-libupnp-miniupnp-security-flaw-1754771.htm

It contains this interesting snippet:

"Please note that other issues have been identified in the latest version of MiniUPnP, 1.4, but they won't be publicly disclosed until the library's developer releases a patch to address them, so we advise caution on any further usage of this stack until such time."

The latest MiniUPnPd is 1.8... 1.4 is at least 2, if not 3 years old. Whoever wrote that article is a bit behind

Again, this is/was just a suggestion. I understand the conundrum. I'm just supplying a bit more background material.

I understand. I'm not saying either that MiniUPNPd is totally safe. It is indeed an authentication-less protocol, something I wouldn't deploy in, say, a corporate environment. But so far, all the security issues reported about MiniUPNPd were related to versions older than what is used by Asus, myself or the Tomato devs, so IMHO it's "safe enough for home users". And let's face it: if you are ending up running code that can forge uPNP packets on your LAN, you have other security issues to worry about. Opening a port isn't a security issue in itself unless you also have a daemon listening to that port you just forwarded.

And Asus did one wise thing there: by default the router disallows forwarding privileged ports (i.e. ports 1-1023) through UPnP. So, only user ports > 1024 can be forwarded by UPnP. That means no chance of an exploit forwarding SMB ports, for example.

 

[KevTech]

I thought we already discussed this subject and concluded the Asus RT-Nxx routers were not exploitable.

http://forums.smallnetbuilder.com/showthread.php?t=9734

 

[RMerlin]

I thought we already discussed this subject and concluded the Asus RT-Nxx routers were not exploitable.

http://forums.smallnetbuilder.com/showthread.php?t=9734

He is referring to other issues (both specific and general), while our previous discussion where specifically about that issue that was disclosed a few months ago.

(EDIT: I see that one of the issues he referred was that one disclosed earlier this year - my bad.)

And BTW, don't take me wrong: I *really* appreciate this kind of discussion! No matter who's right or wrong, that kind of discussion can only be good in the end: either a good reason is brought forward to make a change/fix, or people can have an actual confirmation that it isn't a problem, with actual arguments or verifications being made.