GNOME NetworkManager version 1.10.2 and earlier contains a Information Exposure (CWE-200) vulnerability in DNS resolver that can result in Private DNS queries leaked to local network's DNS servers, while on VPN. This vulnerability appears to have been fixed in Some Ubuntu 16.04 packages were fixed, but later updates removed the fix. cf. https://bugs.launchpad.net/ubuntu/+bug/1754671 an upstream fix does not appear to be available at this time.

A race condition that could disclose connection secrets to authenticated local users when changing ifcfg and keyfile connections was found.

External Reference:

https://mail.gnome.org/archives/networkmanager-list/2016-April/msg00000.html

GNOME NetworkManager allows remote attackers to cause a denial of service (IPv6 traffic disruption) via a crafted MTU value in an IPv6 Router Advertisement (RA) message, a different vulnerability than CVE-2015-8215.

Description of problem: Between F14 and F15, NetworkManager was changed so that unprivileged console users can store both personal and system connections via the ifcfg-rh plugin. As a result, bug 682290 now constitutes a vulnerability allowing such users to escalate to root. To avoid calling attention to this, I am filing a separate bug rather than updating bug 682290.

Version-Release number of selected component (if applicable): NetworkManager-0.9.0-1.fc15

How reproducible: Always

Steps to Reproduce (as an unprivileged console user): 1. Create a wired connection named test'. 2. Change the name to test\nUSERCTL=true\n/bin/bash', where \n' stands for a newline entered via Ctrl-Shift-U, A. 3. usernetctl test up

Actual results: Root shell.

Expected results: Format integrity of /etc/sysconfig/network-scripts/ifcfg-test is maintained.

GNOME NetworkManager before 0.8.6 does not properly enforce the authadmin element in PolicyKit, which allows local users to bypass intended wireless network sharing restrictions via unspecified vectors.

+++ This bug was initially created as a clone of Bug #546793 +++

See also:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560067

If the user had set up a WPA Enterprise or 802.1x connection that used a CA certificate to verify the identity of the network to which the user was connecting, and the user deleted or moved that CA certificate file at a later point, NetworkManager will still connect to that network but without using the CA certificate. This could result in connections to a rogue network that is spoofing the original network as the identity of the network is not verified with the CA certificate after the certificate has been deleted.

Obviously requires direct interaction by the user that configured the connection in the first place to remove the CA certificate file.

--- Additional comment from dcbw on 2009-12-11 18:50:57 EDT ---

Upstream fix is:

http://git.gnome.org/cgit/network-manager-applet/commit/?h=NETWORKMANAGERAPPLET07&id=4020594dfbf566f1852f0acb36ad631a9e73a82b

+++ This bug was initially created as a clone of Bug #546115 +++

nm-connection-editor may inadvertently publish network configuration settings over D-Bus when a user changes those settings using the connection editor. D-Bus gives all clients a bus name (usually 1:XXX where XXX is an ever-increasing number) whenever the client connects to the bus. Even though this client is not exporting a /named/ service, it is still on the bus and if the client exports an object (even inadvertently, without registering a well-known bus name) signals emitted by that object will also be proxied onto the bus.

nm-connection-editor inadvertently exported connection objects on the bus, and when a user changes those connections though the connection editor GUI, the editor may emit a summary of those changes onto the bus, leading to the information disclosure.

1) start 'dbus-monitor --system' in a terminal 2) run nm-connection-editor 3) edit a connection that has secrets, like a protected wifi network 4) Upon clicking the "Apply" button, check the dbus-monitor terminal window; the wifi network password may have been emitted as part of the "Updated" signal for that connection

This is only a problem for NM 0.7.x present in Fedora <= 11 and RHEL5. The problem has been long corrected in NM 0.8 (F12+). Upstream commit to 0.7.x fixing this problem is here:

http://git.gnome.org/cgit/network-manager-applet/commit/?h=NETWORKMANAGERAPPLET07&id=8627880e07c8345f69ed639325280c7f62a8f894