VU#184540 Incorrect implementation of NAT-PMP in multiple devices
-
Hi guys, I found recently these possible bugged miniupnpd in many routers and NAT-PMP implementation in many OSS distros using miniupnpd. How pfsense feel about these kind of thing?
http://www.kb.cert.org/vuls/id/184540 fresh vulnerabilityes
https://github.com/miniupnp/miniupnp/commit/16389fda3c5313bffc83fb6594f5bb5872e37e5e recent changes on git hub
https://github.com/miniupnp/miniupnp/commit/82604ec5d0a12e87cb5326ac2a34acda9f83e837 recent changes on git hub
https://github.com/miniupnp/miniupnp/blob/master/miniupnpd/miniupnpd.conf updated conf file
metasploit modules for testing:
-
Bad manufacturers who do not understand security. As long as it "works", as it does not stop the end user from trying to do what they want, then all is well, even if insecurely setup.
PFSense asks you what interfaces you want to use.
-
::)i understand this behaviour, by default UPNP is not enabled so is not an issue, but i actively use it on my home pfsense box, so I am just wondering will be some workaround these problem? If not i prefer to disable UPNP at all for security reasons ::)
-
It's not so much a vulnerability as extremely insecure settings the affected vendors have used. Some vendors have again screwed things up here. Again, not us. Really no diff than: https://blog.pfsense.org/?p=688
The changes within miniupnpd are to prevent people from using insecure config settings, not to fix a vulnerability that exists where it's sanely configured.
For pfSense, don't select any Internet connection interfaces in the Interfaces box in your uPnP/NAT-PMP settings and you'll be fine. Even if you did pick a WAN there, you'd also have to add a firewall rule on WAN to permit the traffic in.
The affected vendors apparently configured it in such a way that it listened everywhere, and was automatically allowed through without firewall rules. Neither of those have ever been true here.