#297 port binding ignores `network_interface` directive

[ssdfdsfw2e2ef23]

network_interface=eth0 in minidlna.conf, but minidlnad still binds to 0.0.0.0 and accepts HTTP requests over other interfaces. This is a security issue.

tcp 0 0 0.0.0.0:8200 0.0.0.0:* LISTEN 31498/minidlnad

[bitfox]

I found still the same Problem, while choosing

network_interface=eno1.104

on a system with some virtual interfaces for security reasons.

Port 1900 AND and the web-interface on port 8200 is listening to all virtual interfaces, too....
when you set the Presentation-URL for the www-interface to an other network than eno1.104, it's still visible to all other vlans. ...

In the end i was tying to read and fix the code -
but can't do it myself. :-(

Greetings

Oliver

[Astara]

Hi, this isn't a fix for the source code, but an idea for a workaround (I'd have to research & test to put in the actual commands -- if I get the time...).

Put the server in it's own network space with no network connections with a
copied network namespace using 'nsenter'. It will copy the net-namespace of another
process. Then start a shell in that namespace and shut down all interfaces that are external.

Now your namespace should only have your internal nets -- start the server "as normal".

It should only be able to see the interface(s) you left up.

Certainly, a source that matches it's documentation requirement would be a better alternative, however, looks like the projects owner left, given the Creator name.

An alternative, if you started from an empty namespace, would be to use a bridge between
some type of net-interface in the 'namespace' and your local nets.

[Uwe Schindler]

I can confirm, on the Debian Package this problem still exists. This is a serious security issue unless you configure the firewall to block the requests on (possibly WAN interfaces). minidlna is intended to be installed on NAS/Router hardware and therefore also have WAN interfaces, where MINIDLNA should for sure not listen on. In my case the setting "network_interface=iflan" has no effect, it still listens on 0.0.0.0.

[Captain_Commando]

running 1.1.6 on kernel 4.10.11 distro fedora 25 using cinnamon desktop environment on AMD FX-6300 with 16GB ram, and I can affirm, that the network_interface does not work, at all. If you do not wish to have to do systemctl restart minidlna after each system boot, I would ask that someone find and fix the bug.

[Shrimpkin]

Sounds like minidlna is starting before your interfaces are up? Seems unrelated to OP. Post a new post in support request with additional info.

[Shrimpkin]

More of a feature request than a bug as the network_interface option is for ssdp. It does work as long as clients don't cache the old interface. Try setting it to 'lo'.

Much of the upnp related code is from the miniupnp project and has not been updated within minidlna. Newer versions have added additional code to control http access. I made this patch based on miniupnp's current code for http support. Seems to work but I don't have the time to test further.

[CyberShadow]

If you just need one interface, here's a simpler patch that changes the listen address to that of the first configured interface (as opposed to still listening on all interfaces and rejecting incoming connections as in Shrimpkin's patch):

[Shrimpkin]

As previously mentioned, that is how miniupnp "library" works. See http://miniupnp.free.fr

Anyone who is concerned with security should be using a firewall. No patches are needed.

[CyberShadow]

As previously mentioned, that is how miniupnp "library" works. See http://miniupnp.free.fr

No reason to propagate mistakes.

Anyone who is concerned with security should be using a firewall. No patches are needed.

Sorry, but that doesn't follow. That's not how you do security.

Regardless of security aspects, the listen address is a standard setting in pretty much all network daemons by now. There's no justification for not providing it as an option.

[Shrimpkin]

Sorry, but that doesn't follow. That's not how you do security.

OK, don't use a firewall. : D

There's no justification for not providing it as an option.

The only obligation the project owner owes you is the source code. Get it here:
https://sourceforge.net/p/minidlna/git/ci/master/tree/

[CyberShadow]

Well, there is the implied assumption for all open-source projects that maintainers generally aim to improve the software they are in charge of maintaining. Hopefully, the maintainers are rational people, and agree with universally accepted truths, like software providing reasonable options that are expected to exist, or that informational security comes in layers and is everyone's responsibility, and passing the buck does not lead to better software.

Of course, then there are cases when the maintainers are not reasonable people. In such cases, there's not much left to do other than fork or just patch things downstream (e.g. in the distribution).

I'm not sure what your relation is with the project, but if you are saying with authority that this patch has been unequivocally rejected, then I'll probably just submit it to my distribution's bugtracker.

[Shrimpkin]

there's not much left to do other than fork

There are many, many minidlna forks. Last git update was: Justin Maggard 2018-05-04.

I'm not sure what your relation is with the project

I'm not owner or maintainer. I just occassionally help out the fellow minidlna SF'er. I posted firewall workaround that requires zero patches.

I'll probably just submit it to my distribution's bugtracker.

IMO, your patch needs to support more interfaces before getting accepted by a major distro. Have fun.

[bitfox]

.....be sorry, but it's crap to say "use a firewall" -

the problem has nothing to do with a firewall.

if you have a service it should listen to the configured network-interface, and not to "any".
it's state of the art to start services many times on many interfaces. for example: a apache httpd.
noone whould say "just use a firewall, the httpd just listens to any interfaces if you use it" - never!

it's normal to use many instances of a service with different machine-accounts on different network-interfaces on different ports for security purposes.... and that a service doesn't block a port on any network-interfaces if you don't want it.

[Uwe Schindler]

I fully agree with you. The stupidest service around there supports binding to interfaces. This is especially important if you have many interfaces (partly virtual ones). It can't be that this is not fixed!

[Shrimpkin]

Why not post a patch of how it *should* work?

[bitfox]

Why not accept this is a bugtracker and this IS a bug?
The behavior differs from the default as given in the manual.
Why else do you introduce a parameter for the network-interface in the config file ....?

When i look around here i only can see much trouble - all the time the users are the Problem...
Just have a look to #306 https://sourceforge.net/p/minidlna/bugs/306/ or others.
I think that does not make sense here ...

I have the feeling that here in the project, the user's hints are considered more of a burden than to accept them as a positive suggestion.

[Shrimpkin]

Why else do you introduce a parameter for the network-interface in the config file ....?

If you really want to know where the network_interface option comes from, compare minidlna and miniupnp code.

the user's hints are considered more of a burden than to accept them as a positive suggestion.

Most suggestions are just 'thinly veiled' demands. My suggestion, implement it yourself and apply downstream. Project owner may or may not address this issue. I am not a maintainer. I apply my patches locally. I have the same access to this project as you do!

[bitfox]

The "suggestion" to change the code itself, you can read above something exactly as the interface option in the code ... Unlike others, I know where the limits of my Ressources and Ability.
That's the difference about a one-man-show and Teamplayers...
You want your own special Solution with your signing -
and when it's not the right one, the People should do it theirself...
I want a Solution for all - and all people and minds are welcome.
Just because you do not have a proper solution to the problem, or do not like what others want to see as a solution, are not the other guilt, nor are they stupid, nor would you look for the blame, still others here a personal opinion impose.
Think about.

[Shrimpkin]

My previous patch was based on some experimental code I was working on. Importing miniupnp's code would of brought in updated code and features like ipv6. I gave up on it since it would result in more forked code than I was willing to maintain.

OP issue does not affect me. My guess it doesn't affect ReadyNAS devices either.

Here's some code, improving cybershadow's hack.

diff --git a/minidlna.c b/minidlna.c
index 5efcd27..5d5df9d 100644
--- a/minidlna.c
+++ b/minidlna.c
@@ -131,7 +131,21 @@ OpenAndConfHTTPSocket(unsigned short port)
        memset(&listenname, 0, sizeof(struct sockaddr_in));
        listenname.sin_family = AF_INET;
        listenname.sin_port = htons(port);

-       listenname.sin_addr.s_addr = htonl(INADDR_ANY);
+
+       /* TODO: network_interfaces supports 8 interfaces. */
+
+       /* bind to one network_interface, otherwise fallback to INADDR_ANY */
+       if (runtime_vars.ifaces[0] && !runtime_vars.ifaces[1]) {
+               reload_ifaces(0);
+               DPRINTF(E_INFO, L_GENERAL, "Using interface %s and address %s\n", runtime_vars.ifaces[0], lan_addr[0].str);
+               if (!lan_addr[0].str[0])
+                       return -1;
+               listenname.sin_addr = lan_addr[0].addr;
+       }
+       else {
+               DPRINTF(E_WARN, L_GENERAL, "Using INADDR_ANY\n");
+               listenname.sin_addr.s_addr = htonl(INADDR_ANY);
+       }

        if (bind(s, (struct sockaddr *)&listenname, sizeof(struct sockaddr_in)) < 0)
        {

Waiting on 'team' to finish code. Have fun.