Does not store WPA-Enterprise password in keyring

[Scott Dier]

It appears to store the password in plaintext in gconf at this time, unlike WPA-PSK or WEP.

[Scott Dier (sdier)]

I am out of the office from Monday, May 8th until Thursday May 11th.

Thanks,
--
cs.umn.edu auto-reply script for Scott M. Dier <email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

Found this patch from CVS that should fix this.

Will be uploaded in 0ubuntu6, if you could test that and let us know whether it works, that'd be great.

[Morten (morethan)]

Hi,

I believe i am experiencing the same problem.
I use many different wireless networks at work, at home and elsewhere.
On most networks, passwords are saved in the gnome keyring without trouble.
This is not the case on two networks, one which uses PEAP, and one which uses .1x.
On both networks i only enter "Identity" and "Passwords, no certificates etc.

On both mentioned networks i can connect normally, but my identity and passwd
is saved to ~/.gconf/system/networking/wireless/<network name>/%gconf.xml.
They are also visible from gconf-editor, in the same path as under .gconf/.

I am using version 0.6.4-6ubuntu-7 of NM and libpam-keyring 0.0.8-5 under
Ubuntu 7.04. Attached are the gconf files for the networks, stripped of PWs :-)

[Gregg (gclaeys)]

Confirm with the latest official package on ubuntu 7.04

WPA-entrepris EAP-TTLS
NetworkManager 0.6.4-6ubuntu7
gnome-keyring 0.8.1-0ubuntu1

The login name, password is not stored in gnome-keyring. I have to set it up every time I reboot.

The login and name is effectibly store in clear in gconf, unlike my WAP or normal WAP

[Andrew Jorgensen (ajorg)]

This bug exists in gutsy (network-manager 0.6.5-0ubuntu9).

[Andrew Jorgensen (ajorg)]

As this is a security problem and a regression this should probably have a much higher priority than it does now.

[Brian Murray (brian-murray)]

How did you go about determining that this bug still exists in Gutsy? Could you please provide a test case for us? Thanks in advance.

[Andrew Jorgensen (ajorg)]

There were a few duplicate new bugs, which I've marked. That should be sufficient to confirm that there's a problem. I don't know if some of those may have been bugs against feisty - I'll check for myself if the bug exists in feisty tomorrow if I can.

You'd have to have a WPA-Enterprise (802.1x) network to test against there. I don't know how difficult that would be to set up since presumably it involves having a radius server as well as a properly configured wireless router. So test case? Setup an 802.1x-authenticated wireless network and connect to it w/ network-manager. Then verify that the password is stored in gconf by going to the appropriate location in gconf-editor. That's the best I can do for you in that way. Other subscribers to this bug may be willing to test. Our network was presumably setup by corporate IT.

The relevant gconf keys are under /system/networking/wireless/networks/[SSID] and are called wpa_eap_identity (the user name) and wpa_eap_passwd (the password). The network-manager-gnome UI seems to know that it's a password as it uses password dots instead of characters and hides/un-hides when you select the "show passwords" box.

[John B. (jbuncher)]

I can confirm this bug in Feisty (WPA Enterprise, PEAP, TKIP, using username, password, and certificate). I have to re-enter my info every time, but I also have to unlock the keyring every time. It might be writing to both gconf and the keyring (I admit I don't really know how the keyring works).

The SSID on my WPA Enterprise network that I connect to on campus has the SSID hidden (do all WPA Enterprise ones hide the SSID?), so it seems that network-manager doesn't know that the network is "there", and doesn't try to automatically connect, like it does with all of the other WPA (Personal / PSK) networks I have used. I'm not sure if this behavior is related to this particular bug.

[Andrew Jorgensen (ajorg)]

Former upstream bug was marked fixed when the certificate passphrase was stored in the keyring. This bug regards the EAP password.

[Alexander Sack (asac)]

taking the bug.

Do you still see this issue in latest gutsy network-manager (0.6.5-0ubuntu14).

 - Alexander

[Tristan Schmelcher (tschmelcher)]

I can attest that this is fixed in the latest gutsy version (0.6.5-0ubuntu14). In the feisty version (0.6.4-6ubuntu7), I had the same experience as John. After upgrading, it's gone; NM correctly remembers the settings when connecting the next time, and there is no directory created for the network in ~/.gconf. I do however notice an odd error in nm-applet's stderr output:

** (nm-applet:xxxxx): WARNING **: <WARN> nmi_save_network_info(): Error saving secret for wireless network 'xxxxxxxx' in keyring: 5

(The x's are censored system details.)

The error seems to be harmless, though, because everything works as far as I can tell.

[Morten (morethan)]

Dist-upgraded to gutsy yesterday. Bug persists for me.

~$ rm -rf .gconf/system/networking/wireless/networks/eduroam

* xim logs out, restarts, and uses the nm-applet to connect to 'eduroam' again

~$ head .gconf/system/networking/wireless/networks/eduroam/%gconf.xml
<?xml version="1.0"?>
<gconf>
        <entry name="wpa_eap_passwd" mtime="1191405929" type="string">
                <stringvalue>YEAHRIGHT</stringvalue>
        </entry>
        <entry name="wpa_eap_identity" mtime="1191405929" type="string">
                <stringvalue>usename@domain</stringvalue>
        </entry>
        <entry name="wpa_eap_key_mgt" mtime="1191405929" type="int" value="1">
        </entry>

~$ aptitude show network-manager-gnome network-manager |egrep ^Vers
Version: 0.6.5-0ubuntu9
Version: 0.6.5-0ubuntu14

~$ tail .xsession-errors |grep nm-applet
** (nm-applet:6282): WARNING **: <WARN> nmi_save_network_info(): Error saving secret for wireless network 'eduroam' in keyring: 5

Need any more info? :)

[Andrew Jorgensen (ajorg)]

openSUSE has a patch for this. I'll try to dig it up today and post it.

[Andrew Jorgensen (ajorg)]

Ubuntu devs will have to give this patch a thorough review. It's adapted from a patch currently in openSUSE 10.3.

[Alexander Sack (asac)]

is this fixed or not? Maybe try to remove all gconf entries if it doesn't work in latest gutsy.

[Andrew Jorgensen (ajorg)]

@asac
xim did exactly as you asked back in comment 13 on Oct 3. There haven't been any updates since your check-in on Oct 2. So no, this bug isn't fixed but if I can get someone else to confirm that the patch I pulled from SuSE fixes it we'd be in business.

[Andrew Jorgensen (ajorg)]

I should also mention that the comments which say that the bug was fixed were misguided as I clarified in comment 10.

[Michael Bienia (geser)]

I've connected my notebook to a WPA2 EAP secured wlan network on Monday (2007-10-08) and checked now with gconf-editor if the password for that network is stored in the gconf database. The password is still stored in plaintext there.

[Luxor (ranju-mathew)]

I have network-manager 0.6.5-0ubuntu15, and can confirm that this does not work for LEAP.

[Luxor (ranju-mathew)]

Please ignore my comment above. I need to retry this after removing the %gconf.xml file

[Andrew Jorgensen (ajorg)]

I've built n-m-g with the openSUSE patch I attached if anyone wants to test it (gutsy only).

Either just grab it here:
http://ppa.launchpad.net/andrewjorgensen/ubuntu/pool/main/n/network-manager-applet/network-manager-gnome_0.6.5-0ubuntu11~andrewjorgensen0_i386.deb
or here (amd64):
http://ppa.launchpad.net/andrewjorgensen/ubuntu/pool/main/n/network-manager-applet/network-manager-gnome_0.6.5-0ubuntu11~andrewjorgensen0_amd64.deb

or add the following repository and upgrade:
deb http://ppa.launchpad.net/andrewjorgensen/ubuntu gutsy main

At the moment n-m-g is the only thing in there but I make no promises so don't add the repo unless you're very brave.

[Morten (morethan)]

One question: does the patch only fix the issue of not being able to save WPA-E passwords in keyring, or does it also ensure that passwords are *never* saved in plain text? ... I consider saving passwords in plain text without warning a user is much worse than not saving the password at all.

[Andrew Jorgensen (ajorg)]

xim wrote:
> One question: does the patch only fix the issue of not being able to
> save WPA-E passwords in keyring, or does it also ensure that passwords
> are *never* saved in plain text? ... I consider saving passwords in
> plain text without warning a user is much worse than not saving the
> password at all.

It only fixes the case of WPA-EAP (password and/or certificate
pass-phrase). I agree it would be ideal if passwords were never stored
clear but from what I've seen of the code I think it would be a fairly
intrusive re-write to prevent that generally.

Also this may be the last case where they weren't stored in the keyring,
in which case the motivation to write a new infrastructure to prevent it
goes away.

Please do test it, though, if you have a network it can be tested on. I
don't think Canonical has a WPA-EAP network so this will have to rely on
the users and on the eyes that look at the code.

[Morten (morethan)]

On Thu, Oct 11, 2007 at 11:21:41PM -0000, Andrew Jorgensen wrote:
[...]
> Also this may be the last case where they weren't stored in the keyring,
> in which case the motivation to write a new infrastructure to prevent it
> goes away.

Can't say I'm a fan of that line of thought. Maybe this should be
reported as a separate security-related bug? - If it isn't already? ...

> Please do test it, though, if you have a network it can be tested on. I
> don't think Canonical has a WPA-EAP network so this will have to rely on
> the users and on the eyes that look at the code.

If i find the time, i'll give it a try tomorrow =)

--
Kind regards,
Morten

[Spenser Gilliland (spenser-gilliland)]

I can confirm this bug in network-manager0.6.5-0ubuntu15 with an WPA2-Enterprise configuration and WPA-Enterprise config. (802.1x)

[Luxor (ranju-mathew)]

I retried after removing the %gonf.xml files, and the bug still exists. When the key is not provided, wpa_supplicant does not get called, but if I use the 'connect to other wireless network', then I can see wpa_supplicant in the process list. Unfortunately, some other bug down the line is causing me from having a consistent LEAP connection. I am going to try installing Andrew's fix, and will report back.

Morten, my passwords are not stored in the %gconf.xml file. My passwords seem to be located in the keyring manager. Could you be having something left over from the upgrade?

[Luxor (ranju-mathew)]

Applied Andrew's fix. The password is being held in the keyring... (was doing so even before this fix), but I don't think the information is being retrieved from the keyring to pass to wpa_supplicant by nm-applet. I don't see wpa in the process list until I use the 'connect to other wireless network'.

[Andrew Jorgensen (ajorg)]

Luxor wrote:
> Applied Andrew's fix. The password is being held in the keyring... (was
> doing so even before this fix), but I don't think the information is
> being retrieved from the keyring to pass to wpa_supplicant by nm-applet.
> I don't see wpa in the process list until I use the 'connect to other
> wireless network'.

Luxor, I suspect you may be trying to connect to a WPA-PSK (password,
pre-shared-key) network and experiencing some other bug. This bug is
specific to 802.1x authentication AKA WPA-EAP or WPA Enterprise.

[Luxor (ranju-mathew)]

I am using LEAP, which I believe is wpa-eap. Perhaps my problem is due
to the fact that I am unable to actually connect to the network, so the
fix doesn't even come into play yet?
On Fri, 2007-10-12 at 18:27 +0000, Andrew Jorgensen wrote:
> Luxor wrote:
> > Applied Andrew's fix. The password is being held in the keyring... (was
> > doing so even before this fix), but I don't think the information is
> > being retrieved from the keyring to pass to wpa_supplicant by nm-applet.
> > I don't see wpa in the process list until I use the 'connect to other
> > wireless network'.
>
> Luxor, I suspect you may be trying to connect to a WPA-PSK (password,
> pre-shared-key) network and experiencing some other bug. This bug is
> specific to 802.1x authentication AKA WPA-EAP or WPA Enterprise.
>
--
Ranju Mathew <email address hidden>

[asdf (asdf123123-deactivatedaccount-deactivatedaccount)]

I experienced the same problem, please fix it, it's really annoying.

[asdf (asdf123123-deactivatedaccount-deactivatedaccount)]

Wow I just saw that this bug is from Feisty! And it still exists in Gutsy, now it really doesn't surprise me anymore that Linux/Ubuntu has a market share of >1 on the desktop.

[tonfa (bboissin)]

On Tue, Oct 16, 2007 at 11:02:16AM -0000, Nils wrote:
> Wow I just saw that this bug is from Feisty! And it still exists in
> Gutsy, now it really doesn't surprise me anymore that Linux/Ubuntu has a
> market share of >1 on the desktop.

Did I miss your patch ?

--
:wq

[tonfa (bboissin)]

@andrew

I tested network-manager-gnome 0.6.5-0ubuntu11~andrewjorgensen0, it doesn't connect to the network (the "bubble" says "waiting for wireless key"), with the "vanilla" deb it works (but stores it in plaintext.

[Andrew Jorgensen (ajorg)]

@tonfa

Thanks for testing. I got about the same results but I was suspicious of the result because our IT folks can't seem to keep the wireless running.

@ubuntu devs

Perhaps someone who knows the code could take a look at the patch and see what's wrong with it. Likely an interaction with one of the other patches is causing this problem.

[DickeyWang (invariance)]

Just want to say I am having the same problem with WPA/TTLS/PAP and certificate. In my case it is even worse because I have an Intel 4965AGN card, and the iwl4965 module has the bug #124336, which causes the iwl4965 module to crash if it is kept disconnected from any wireless network for about 5 minutes. Everytime I start my laptop, nm-applet will automatically link to the 802.1x, but a few minutes later it will ask for the wpa settings, very often iwl4965 has already crashed by the time I type in all the wpa settings, and the only choice left is to restart the laptop.

I would really love to see the bug to be fixed. It takes me from 5minutes to 2 hours every day just rebooting the laptop. Whether the wireless is working or not completely depends on luck. :(

[Franziskus Domig (fdomig)]

I can confirm this behaviour too. My wireless WPA Enterprise connection data are stored in plaintext in the gconf-edior and every time I get disconnected, I have to insert my login data (username, password, no certificate) again.

I am using the Gutsy network-manager 0.6.5-ubuntu16. I also have the same problem as the DickeyWang reportet with the bug #124336 (with iw3945).

This bug exists since Festy and is in my opinion a security risk and very anoying! This should be fixed asap!

[Alberto (apedraza)]

Same problem: KeyRing does not store the certificates that I use to authenticate to the AP. I am connecting to a Cisco AP, WPA2 EAP TLS with Certificate Authentication.

As a workaround I installed KNetworkManager and KWallet.... KNetworkManager saves the information for the certificates and the passkey to the Kwallet. When I login, Kwallet asks me for my password and after that, KNetworkManager connects without any problems to my network.

I really wish that they would fix nm-applet.

[b4d (b4d)]

Problem here also, 7.10, you can pass that with adding:
ifdown wlan0
ifup wlan0
to /etc/rc.local

[Alberto (apedraza)]

All the information elements for the wpa enterprise connection are being stored in the gconf file under /system/networking/wireless. The only bit of information not stored there (as it should be) is the passkey to the private certificate.

The passkey is being stored on the default keyring but for some reason, this key is not being retrieved and passed on to networkmanager or to the wpa suupplicant. Without this key, the supplicant cannot open the private key store and the connection fails.

I also have to say that for networks that use WPA PSK, this is not the case and those networks work very well with nm-applet In WPA PSK networks, the PSK is stored in the keyring and it is encrypted. When connecting to those networks, nm-applet is able to retrieve the key and pass it to the supplicant without any problems.

Thank you.

[Mika Fischer (zoop)]

I also recently found out that NM stores the password for the WLAN at my university in clear text in the gconf database.

In my optinion this is a huge security issue! At my university students get ONE password for their shell acounts, email, logins to administrative websites, etc pp. And of course for access to the campus WLAN. And this one password is stored in clear-text on my computer. So I only need to leave my laptop unattended for a minute and this would be enough for an attacker (who probably knows what can be done with the password because he's a student too) to steal my password! Needless to say, a lot of bad stuff can happen after that...

I really cannot believe that this bug has been open for almost TWO years now with priority medium...

For me, storing the password in clear-text is vastly worse than not storing it at all!

I'll try to have a look at the network-manager code to see if I can do anyhting, but don't hold your breath...

If anyone can get the attention of the security people to this, that would be great!

[tonfa (bboissin)]

On Mon, Mar 03, 2008 at 08:20:47PM -0000, Mika Fischer wrote:
>
> I'll try to have a look at the network-manager code to see if I can do
> anyhting, but don't hold your breath...

it is already fixed for 0.6.x in the upstream SVN (see
http://bugzilla.gnome.org/show_bug.cgi?id=359541).
alternatively 0.7.x solves this too.

--
:wq

[Launchpad Janitor (janitor)]

This bug was fixed in the package network-manager - 0.6.6~rc2-0ubuntu1

---------------
network-manager (0.6.6~rc2-0ubuntu1) hardy; urgency=low

  * new upstream release 0.6.6 RC (LP: #197538); fixes various bugs:
    - LP: #40232, #41134, #75554, #82113, #107598, #118439, #132473
  * drop patches applied upstream
    - drop debian/patches/04-if_fix.patch
    - drop debian/patches/11-man_page_sh_name.patch
    - drop debian/patches/24pp_svn2578-gnome354565-fix-ethernet-link-detection-races.patch
    - drop debian/patches/24pp_svn2579-sleep-1-second-to-stabilize-if.patch
    - drop debian/patches/24pp_svn2591_Ensure-the-device-is-up-stage3.patch
    - drop debian/patches/24pp_svn2604_Add-HAL-based-rfkill-support.patch
    - drop debian/patches/24pp_svn2605-gnome354565-dont-up-notwired-interfaces.patch
    - drop debian/patches/24pp_svn2618_set-hardware-RF-to-enabled-if-no-killswitches.patch
    - drop debian/patches/24pp_svn2754-lp101857-endianess.patch
    - drop debian/patches/41c_ubuntu-fixup--get_mode_always_fails_typo_fix.patch
    - drop debian/patches/41e_fix_vpn_ftbfs_dont_disable_gnome_deprecated.patch
    - drop debian/patches/41m_unref_dbus_connection_on_shutdown.patch
    - update debian/patches/series
  * refresh patch because of renamed NetworkManagerDispatcher manpage
    - update debian/patches/06-dispatch_more_events.patch
  * drop driver specific tweaks assuming that wext should be fine for most
    drivers nowadays
    - drop debian/patches/13-rml-wpa-workarounds.patch
    - drop debian/patches/14-j-hostap-supplicant-driver.patch
    - drop debian/patches/43b_lp181232_save_kernel_driver_check.patch
    - update debian/patches/series
  * simply unbittrotted patches
    - update debian/patches/41k_20_sec_wireless_link_timeout.patch
    - update debian/patches/41t_nm_device_wireless_index_ctrl_sockets_by_run_count.patch
    - update debian/patches/41u_custom_timeout_for_some_wpa_ctrl_operations.patch
  * don't use run count for global ctrl socket anymore
    - update debian/patches/41t_nm_device_wireless_index_ctrl_sockets_by_run_count.patch
  * try to drop hidden AP tweaks (lets hope that scan_capa patch in 2.6.24
    fixes this)
    - drop debian/patches/42a_lp50214_gnome464215_fix_hidden.patch
    - update debian/patches/series
  * fix manpage path for NetworkManager and NetworkManagerDispatcher
    - update debian/network-manager.manpages

 -- Alexander Sack <email address hidden> Wed, 05 Mar 2008 19:06:19 +0100

[tonfa (bboissin)]

Since 0.6.6 is freshly released, do you think it is possible to provide a release a backport for gutsy ?

thanks

[Alexander Sack (asac)]

not me. if someone prepares a backport i am happy to provide a helping hand though.

[Felix Eckhofer (eckhofer)]

Is this bug still present in 12.04/Precise? I just discovered that in /etc/NetworkManager/system-connections there is a file which holds the password for a WPA-EAP/TTLS connection in plaintext even though that connection is not marked as "available for all users" in the wifi settings. This has huge security implications as per comment #41 and most users would expect it to be stored at least inside $HOME, possible protected by ecryptfs.

[Lukas (lukas-ribisch)]

It's still unfixed in 12.04. Aall my EAP passwords are plainly visible in /etc/NetworkManager/system-connections, whereas the VPN passwords are correctly stored in my personal keychain.

This is a major security problem for me too, as my EAP password is not only used for Wifi authentication.

[Marc Deslauriers (mdeslaur)]

Please open a new bug for 12.04, as this bug is closed. Thanks.