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

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