A flaw was found in NetworkManager. This local privilege escalation vulnerability exists in NetworkManager's dhclient backend when processing malformed Manufacturer Usage Description (MUD) URLs. A local user can exploit this flaw to escalate privileges by triggering a script via a crafted MUD URL, provided an administrator has explicitly configured NetworkManager to use dhclient. This issue does not affect default configurations of NetworkManager.

A flaw was found in NetworkManager. This local privilege escalation vulnerability exists in NetworkManager's dhclient backend when processing malformed Manufacturer Usage Description (MUD) URLs. A local user can exploit this flaw to escalate privileges by triggering a script via a crafted MUD URL, provided an administrator has explicitly configured NetworkManager to use dhclient. This issue does not affect default configurations of NetworkManager.

+++ 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

It was found that NetworkManager, a network devices and connections manager, did not properly enforce the PolicyKit 'authadmin' action element settings (did not require authentication by an administrative user), when the 'authadmin' element was specified in org.freedesktop.network-manager-settings.system.wifi.share.open (connection sharing via an open WiFi network) action. A local attacker could use this flaw to setup an unsecure (passwordless) Ad-Hoc wireless network.

A flaw was found in NetworkManager. When a system running NetworkManager with DEBUG logs enabled and an interface eth1 configured with LLDP enabled, a malicious user could inject a malformed LLDP packet. NetworkManager would crash, leading to a denial of service.

Given a system running NetworkManager with DEBUG logs enabled and an interface eth1 configured with LLDP enabled, someone could inject a malformed LLDP packet and NetworkManager would crash leading to a DoS.

A flaw was found in NetworkManager. NetworkManager package allows access files that may belong to other users. NetworkManager allows non-root users to configure the network on the system. The daemon runs as root and, as such, is able to access files that are owned by users different from the one who added the connection.