Pre-install MiniUPnPd on OpenWrt by default

[Stijn Tintel]

On 29/01/2022 12:53, Sergey Ponomarev wrote:
> As a follow up I asked in a dev chat:
>
> <stokito> Hi, Is there any process of deciding what to include into
> OpenWrt builds by default? I sent a letter to devlist "Pre-install
> MiniUPnPd on OpenWrt by default" but it seems not interesting in the
> context of devlist which is used mostly for patches.
> <Grommish> stokito: UPNP of any kind as default is a huge security
> attack surface
> <stintel> stokito: miniupnpd is in the packages feed, and afaik we do
> not install things from the package feed by default
> <Grommish> stokito: even OEM's have learned to turn it off or not include it
> <stintel> it is also unmaintained,
> <stokito> yes but still miniupnpd is supported and all security issues
> was resolved years ago
> <neggles> stokito: UPnP, in and of itself, is a *massive* security issue
> <stintel> stokito: there is no such thing as "all security issues
> resolved years ago"
> <Grommish> UPNP itself *is* the security issue. The ability for any
> Application to open a port to the outside is ludicris
> <stokito> ok, what about having just a NAT-PMP server which is much
> simpler and easier to audit?
> <neggles> stokito: Any system which allows a device to request an
> external:internal port mapping without any end-user input is a
> HORRIBLE IDEA.
> <neggles> If you understand enough about networking etc. to use UPnP
> and/or NAT-PMP "safely" (insofar as that's possible), then you are
> also capable of building a custom image, or just installing it
> yourself.
> <neggles> it does not need to be, should not need to be, and probably
> will never be built in by default.
> <Grommish> stokito: But... You can use Imagebuilder if you don't want
> to build from source and include miniupnp in your builds
> <Grommish> stokito: You'll better understand what issues your network
> might face and can decide for yourself
> <stintel> stokito: it's unlikely to happen, due to miniupnpd being in
> the packages feed, unmaintained, considered a major security risk, we
> prefer security over convenience, etc
> <stintel> stokito: your best bet is to build a custom image with
> https://sysupgrade.openwrt.org/
> <stokito> I need it from a client point of view i.e. for my
> application that needs to open a port. The concerns about UPnP safety
> is a first thing that everybody have and I tried to answer on it here
> http://lists.openwrt.org/pipermail/openwrt-devel/2022-January/037721.html
> <stintel> neggles: can it still do that with iptables/nftables rules ?
> <stintel> stokito: like I said, it's unlikely to happen, build a
> custom image with https://sysupgrade.openwrt.org/
> <Grommish> stokito: Why not just Port forward then
> <neggles> or just install it yourself?
> <Grommish> Which is what UPnP does.
> <neggles> if you want UPnP, just... install miniupnpd? if you really
> badly need it baked into the image, as stintel and myself and at least
> one other have already said in here, use sysupgrade.openwrt.org or the
> image builder to make a custom image
> <neggles> if you are capable of installing and configuring OpenWrt,
> you are capable of installing and configuring a UPnP daemon
> <Grommish> Wait... What kind of Application are you making that you
> want to make UPnP a default in OpenWrt?
> <Grommish> Malware? Wormable Hello World? I mean... What?
> <stokito> Gromish: I am building a p2p program with VoIP capabilities
> intended for not so experienced users. And I would like it to make it
> simple to use. That's why I'm interested in having a wider support of
> NAT-PMP. I wondered that OpenWrt doesn't have it out of the box and in
> fact this makes my current VoIP programs work slower.
> <neggles> stokito: yeah, no, there's a reason why there are no p2p
> voip applications that anyone actually uses
> <neggles> UPnP will not solve your problem
> <neggles> you have forgotten about CG-NAT, for one
> <stokito> Ok, thank you for your answers. You refined more to me
> <neggles> stokito: VoIP is an absolute nightmare at the best of times;
> just having UPnP present on OpenWrt by default would not make a
> significant difference to this.
> <neggles> even if it was preinstalled, it would *never* be enabled out
> of the box
> <stintel> the other problem with have upnp by default is that at some
> point someone is going to hold us responsible for their network being
> hacked
> <stintel> and while the licence says "no warranty" ... having to deal
> with such people is very very very demotivating
> <stintel> so no, you're probably not going to convince many of us that
> including that by default is a good idea
>
> So even given that NAT-PMP would be safer than manual port forwarding
> and allows the use of safer and more reliable programs the OpenWrt is
> intended only for advanced users that at the same time don't want to
> use the Internet.

Strange conclusion you're drawing here.

The fact that you forgot to disable a static port forwarding is an error
on your end. Arguing that NAT-PMP is safer because of that, is a bit of
a stretch. You should have removed the port forwarding. Or you can rely
on NAT-PMP to do that by installing and enabling it yourself. The
advanced user you are talking about here, can make an educated decision
about doing so. Average Joe not so much, and it's exactly this group
that should *not* have something like this running by default.

I consider myself an advanced user, and as such I made the decision to
include miniupnpnd in my images, even started by default. But I
configured it to allow only a few internals IPs of devices in an
isolated VLAN. Like this, you have the convenience of the port mapping
being done automatically, without the risk of having whatever software
on whatever device in your network opening whatever port(s) it likes to
the outside world.

If we would ever consider adding miniupnpd to the default images (which
is currently not an option for reasons stated above, reasons you chose
to completely ignore), the only acceptable default configuration would
be to not allow any device to use it. The user will still have to change
the configuration before it will start doing anything on their network.
At this point, they'll still require assistance from an advanced user to
do it right, and your whole argument of skipping the additional step
becomes invalid anyway.

Kind regards,
Stijn