Bug 1697473

is there more information about this? This description is not enough (for me) to understand the issue.

From the provided information, this does not look like a NetworkManager bug.


As the attacker requires root permissions, the severity of this is not high to begin with.

Regardless of that, NetworkManager *MUST* not execute code from ifcfg-files and this is something that we very much would want to fix.


But I don't see how that could be happening. Please provide more information how to reproduce this.


Note that initscripts indeed do execute the ifcfg files as shell scripts (by sourcing them). That means any of

    - ifup eth1
    - systemctl restart network.service
    - boot with network.service enabled

lets initscripts execute ifcfg files as scripts. The bug very much apply to initscripts: initscripts execute the ifcfg as shell scripts. There is no surprise there and not a vulnerability (since only root can write these files).

The question is, whether NetworkManager does that too (it MUST not!).

So, when reproducing the issue, please make sure that initscripts are not enabled (or that it's really NetworkManager executing the code).

rschirone reproduced the issue.

If you craft malicious ifcfg files, then /etc/NetworkManager/dispatcher.d/11-dhclient will source them. Even with network.service disabled.

It's clear that network.service sources/executes ifcfg files are shell scripts. That is how initscripts work at their core.
I find it unfortunate, that "dhcp-client" package installs a dispatcher scripts that also does that -- even with "network.service" disabled.


Note when NetworkManager writes ifcfg files to disk, it aims to preserve preexisting content of the file (like comments and shell variables it doesn't understand). However, it takes special care that the resulting file only contains comments, empty lines, and assignment of shell variables. That is, it will comment out lines that would be executable code: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/plugins/ifcfg-rh/shvar.c?id=f917fabde40f36332ab1d15d89eaaaa49cd9482f#n1427

Just so that it's absolutely clear: This is *not* a security issue.

Writing arbitrary ifcfg files is a privileged action and only a super-user can do that. There's no privilege escalation.

That's how about all /etc/sysconfig/ files worked in pre-systemd times (they were sourced by the init scripts), and that users now find that unexpected is progress of a kind. For RHEL 8 we default to using an internal DHCP client instead of dhcp-client, getting rid of this antiquated behavior.

This should be closed with NOTABUG.

Making the bug public because it was already made public by the reporter at https://seclists.org/fulldisclosure/2019/Apr/24 .

As previously said, this is not a flaw, since files in /etc/sysconfig/network-script are correctly protected by being owned by root and writable by root only. I'm closing this bug report as NOTABUG for the reasons mentioned in comment 4, comment 5 and comment 6.