Subject: wicd-daemon: silently keeps and uses obsolete, possibly insecure
config in /etc/wicd/wireless-settings.conf
Date: Tue, 26 Jun 2018 08:52:57 -0400
Package: wicd-daemon
Version: 1.7.4+tb2-6
Severity: grave
Tags: security
Justification: user security hole
I'm using eduroam, and instead of keeping only one config associated
with it (e.g. [essid:eduroam]), wicd creates many of them in
/etc/wicd/wireless-settings.conf (based on the bssid instead of the
essid, even though wicd seems to ignore the bssid when searching for
a matching config), and when one updates the eduroam config, some
old configs are not updated, and wicd can randomly use them later.
I noticed that after a password update: I got a connection failure
due to an old config with an old password. But there's the same issue
with the certificate (ca_cert field). In my case, some old configs
that became insecure after a security hole was found in the protocol
were still used by wicd, which could yield a leak of my password.
Note: The UI just presents the essid, so that the user will generally
not know what's going on.
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages wicd-daemon depends on:
ii adduser 3.117
ii dbus 1.12.8-3
ii debconf 1.5.67
ii iputils-ping 3:20161105-1
ii isc-dhcp-client 4.3.5-4
ii lsb-base 9.20170808
ii psmisc 23.1-1+b1
ii python 2.7.15-3
ii python-dbus 1.2.8-2
ii python-gobject-2 2.28.6-13+b1
ii python-wicd 1.7.4+tb2-6
ii wireless-tools 30~pre9-12+b1
ii wpasupplicant 2:2.6-17
Versions of packages wicd-daemon recommends:
ii rfkill 2.32-0.1
ii wicd-curses [wicd-client] 1.7.4+tb2-6
ii wicd-gtk [wicd-client] 1.7.4+tb2-6
Versions of packages wicd-daemon suggests:
pn pm-utils <none>
Versions of packages wicd depends on:
ii wicd-curses [wicd-client] 1.7.4+tb2-6
ii wicd-gtk [wicd-client] 1.7.4+tb2-6
Versions of packages wicd-gtk depends on:
ii python 2.7.15-3
ii python-glade2 2.24.0-5.1+b1
ii python-gtk2 2.24.0-5.1+b1
Versions of packages wicd-gtk recommends:
ii menu 2.1.47+b1
ii policykit-1 0.105-20
ii python-notify 0.1.1-4
Versions of packages wicd-curses depends on:
ii python 2.7.15-3
ii python-urwid 2.0.1-2
Versions of packages wicd-curses recommends:
ii sudo 1.8.23-1
Versions of packages python-wicd depends on:
ii net-tools 1.60+git20161116.90da8a0-2
ii python 2.7.15-3
Versions of packages python-wicd suggests:
ii ethtool 1:4.16-1
ii iproute2 4.16.0-4
-- Configuration Files:
/etc/wicd/encryption/templates/active changed [not included]
-- debconf information:
* wicd/users:
Acknowledgement sent
to Axel Beckert <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian WICD Packaging Team <[email protected]>.
(Tue, 26 Jun 2018 14:42:06 GMT) (full text, mbox, link).
Subject: Re: Bug#902421: wicd-daemon: silently keeps and uses obsolete,
possibly insecure config in /etc/wicd/wireless-settings.conf
Date: Tue, 26 Jun 2018 16:38:05 +0200
Control: severity -1 normal
Control: tag -1 + moreinfo
Hi Vincent,
Vincent Lefevre wrote:
> Severity: grave
> Tags: security
> Justification: user security hole
>
> I'm using eduroam, and instead of keeping only one config associated
> with it (e.g. [essid:eduroam]), wicd creates many of them in
> /etc/wicd/wireless-settings.conf (based on the bssid instead of the
> essid,
Yes, this is by design.
Are you aware that you need to explicitly configure if a configuration
needs to be solely based on the ESSID? It's called "use these settings
for all wifis with this ESSID" or similar.
And IMNSHO it's a security feature and not a bug that wicd does use
only the BSSID by default. That way credentials can't be leaked to to
rogue access points which share the same ESSID (which is easy to do).
> even though wicd seems to ignore the bssid when searching for
> a matching config),
If you set that flag, of course it does.
> and when one updates the eduroam config, some old configs are not
> updated, and wicd can randomly use them later.
In which case did this happen? With an ESSID where you had the "use
these settings for all wifis with this ESSID" flag set or not? In the
latter case it should update all of them (or only keep one and remove
the remaining ones with the same ESSID), in the former it shouldn't.
(→ moreinfo)
Downgrading to the default severity at least until the specific
settings under which this happened, are clarified.
> I noticed that after a password update: I got a connection failure
> due to an old config with an old password. But there's the same issue
> with the certificate (ca_cert field). In my case, some old configs
> that became insecure after a security hole was found in the protocol
> were still used by wicd, which could yield a leak of my password.
Am I right that you say that it's not an outdated password which might
be leaked, but the current password which is sent in an insecure way,
like WEP instead of WPA? (But then I wonder: Why is the WPA password
sent via WEP? IIRC WICD stores them per encryption method. And I don't
think that sending no more valid passwords is a security threat that
validates RC severity.)
Once again: This depends a lot on your settings (see above) and
depending on your settings. It should not happen with the setting "use
these settings for all wifis with this ESSID", but it is expected to
happen (and a security feature) if that flag is not set.
> Note: The UI just presents the essid, so that the user will generally
> not know what's going on.
Which UI? WICD has several UIs (Gtk, Curses, CLI) and you filed that
bug report against wicd-daemon. (→ moreinfo, too)
Regards, Axel
--
,''`. | Axel Beckert <[email protected]>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian WICD Packaging Team <[email protected]>.
(Tue, 26 Jun 2018 15:21:05 GMT) (full text, mbox, link).
Subject: Re: Bug#902421: wicd-daemon: silently keeps and uses obsolete,
possibly insecure config in /etc/wicd/wireless-settings.conf
Date: Tue, 26 Jun 2018 11:17:52 -0400
On 2018-06-26 16:38:05 +0200, Axel Beckert wrote:
> Are you aware that you need to explicitly configure if a configuration
> needs to be solely based on the ESSID? It's called "use these settings
> for all wifis with this ESSID" or similar.
I have "Use these settings for all networks sharing this essid"
ticked for eduroam, but it is apparently not honored.
> And IMNSHO it's a security feature and not a bug that wicd does use
> only the BSSID by default. That way credentials can't be leaked to to
> rogue access points which share the same ESSID (which is easy to do).
... unless a certificate is used, which is my case.
Another issue is that here, it was a *new* BSSID (well, I assume
because it is a place where I had never came before).
> > and when one updates the eduroam config, some old configs are not
> > updated, and wicd can randomly use them later.
>
> In which case did this happen? With an ESSID where you had the "use
> these settings for all wifis with this ESSID" flag set or not?
See above. But I'm not aware if there is a global setting (in any
case the local setting should have the precedence).
> Am I right that you say that it's not an outdated password which might
> be leaked, but the current password which is sent in an insecure way,
> like WEP instead of WPA?
There were some old settings with the new password and no certificate.
This could have leaked. I never use WEP, always WPA2.
> > Note: The UI just presents the essid, so that the user will generally
> > not know what's going on.
>
> Which UI? WICD has several UIs (Gtk, Curses, CLI) and you filed that
> bug report against wicd-daemon. (→ moreinfo, too)
Gtk.
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Acknowledgement sent
to Axel Beckert <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian WICD Packaging Team <[email protected]>.
(Tue, 26 Jun 2018 21:27:05 GMT) (full text, mbox, link).
Subject: Re: Bug#902421: wicd-daemon: silently keeps and uses obsolete,
possibly insecure config in /etc/wicd/wireless-settings.conf
Date: Tue, 26 Jun 2018 23:23:16 +0200
Control: tag -1 - moreinfo
Comtrol: severity -1 important
Hi Vincent,
Vincent Lefevre wrote:
> On 2018-06-26 16:38:05 +0200, Axel Beckert wrote:
> > Are you aware that you need to explicitly configure if a configuration
> > needs to be solely based on the ESSID? It's called "use these settings
> > for all wifis with this ESSID" or similar.
>
> I have "Use these settings for all networks sharing this essid"
> ticked for eduroam, but it is apparently not honored.
Ok, thanks for that detail.
> > And IMNSHO it's a security feature and not a bug that wicd does use
> > only the BSSID by default. That way credentials can't be leaked to to
> > rogue access points which share the same ESSID (which is easy to do).
>
> ... unless a certificate is used, which is my case.
Granted.
> Another issue is that here, it was a *new* BSSID (well, I assume
> because it is a place where I had never came before).
That sounds strange. I wonder if that could be triggered, if e.g. two
different eduroam APs/BSSIDs are ticked with "use these settings
for all wifis with this ESSID" but have different settings and it is
e.g. luck which one is used (unless the BSSID fits).
Will eventually test for that corner case.
> > > and when one updates the eduroam config, some old configs are not
> > > updated, and wicd can randomly use them later.
> >
> > In which case did this happen? With an ESSID where you had the "use
> > these settings for all wifis with this ESSID" flag set or not?
>
> See above. But I'm not aware if there is a global setting (in any
> case the local setting should have the precedence).
From what I gather, it's just a per-ESSID setting, but I haven't yet
looked at the code how it is implemented. Will do.
> > Am I right that you say that it's not an outdated password which might
> > be leaked, but the current password which is sent in an insecure way,
> > like WEP instead of WPA?
>
> There were some old settings with the new password and no
> certificate.
I see.
> This could have leaked. I never use WEP, always WPA2.
As far as I remember from some discussions about potential rogue
access points in general, at least WPA2 Enterprise (like with eduroam)
uses some challenge/response methods for authentication, so a leaking
of passwords should not be possible.
OTOH I know there are tons of ways how a WPA Enterprise setup can be
done (and especially that you might need to modify your eduroam ESSID
settings when moving from one university to another) and I'm
definitely not sure if all of them use challenge/response methods.
Will try to figure out if there's really a chance to leak credentials.
(I still have my doubts, but at least not honouring that "use these
settings for all wifis with this ESSID" flag is at least a not so nice
usability bug, so setting to severity to "important" for now.)
> > Which UI? WICD has several UIs (Gtk, Curses, CLI) and you filed that
> > bug report against wicd-daemon. (→ moreinfo, too)
>
> Gtk.
Ok. I use mostly wicd-curses which IIRC shows the BSSID. Will have a
look at the Gtk interface with a focus on the BSSID.
Thanks for the additional details!
Regards, Axel
--
,''`. | Axel Beckert <[email protected]>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian WICD Packaging Team <[email protected]>.
(Wed, 27 Jun 2018 03:03:02 GMT) (full text, mbox, link).
Subject: Re: Bug#902421: wicd-daemon: silently keeps and uses obsolete,
possibly insecure config in /etc/wicd/wireless-settings.conf
Date: Tue, 26 Jun 2018 22:58:30 -0400
On 2018-06-26 23:23:16 +0200, Axel Beckert wrote:
> > Another issue is that here, it was a *new* BSSID (well, I assume
> > because it is a place where I had never came before).
Actually, I think that the issue occurs only in that case.
Once a config with the BSSID has been created, the behavior
is reproducible with the same BSSID.
FYI, in the wicd logs:
[...]
2018/06/25 09:21:53 :: Putting interface up...
2018/06/25 09:21:53 :: ifconfig wlp61s0 up
2018/06/25 09:21:55 :: enctype is peap-eduroam
2018/06/25 09:21:55 :: Attempting to authenticate...
2018/06/25 09:21:55 :: ['wpa_supplicant', '-B', '-i', 'wlp61s0', '-c', '/var/lib/wicd/configurations/04bd882b5811', '-Dwext']
2018/06/25 09:21:55 :: ['iwconfig', 'wlp61s0', 'essid', '--', 'eduroam']
2018/06/25 09:21:55 :: iwconfig wlp61s0 channel 36
2018/06/25 09:21:55 :: iwconfig wlp61s0 ap 04:BD:88:2B:58:11
2018/06/25 09:21:55 :: WPA_CLI RESULT IS DISCONNECTED
2018/06/25 09:21:56 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:21:57 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:21:58 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:21:59 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:00 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:01 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:02 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:03 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:04 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:05 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:06 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:07 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:08 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:09 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:10 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:11 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:12 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:13 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:14 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:15 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:16 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:17 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:18 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:20 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:21 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:22 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:23 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:24 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:25 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:26 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:27 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:28 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:29 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:30 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:31 :: wpa_supplicant authentication may have failed.
2018/06/25 09:22:31 :: connect result is failed
2018/06/25 09:22:31 :: exiting connection thread
2018/06/25 09:22:31 :: Sending connection attempt result bad_pass
[...]
(This was the first time 04:BD:88:2B:58:11 was seen.)
[...]
2018/06/25 09:22:38 :: enctype is peap-eduroam
2018/06/25 09:22:38 :: Attempting to authenticate...
2018/06/25 09:22:38 :: ['wpa_supplicant', '-B', '-i', 'wlp61s0', '-c', '/var/lib/wicd/configurations/04bd882b5811', '-Dwext']
2018/06/25 09:22:38 :: ['iwconfig', 'wlp61s0', 'essid', '--', 'eduroam']
2018/06/25 09:22:38 :: iwconfig wlp61s0 channel 36
2018/06/25 09:22:38 :: iwconfig wlp61s0 ap 04:BD:88:2B:58:11
2018/06/25 09:22:38 :: WPA_CLI RESULT IS DISCONNECTED
2018/06/25 09:22:39 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:40 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:41 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:42 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:43 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:44 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:45 :: WPA_CLI RESULT IS ASSOCIATED
2018/06/25 09:22:46 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:47 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:48 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:49 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:50 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:51 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:52 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:53 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:54 :: WPA_CLI RESULT IS SCANNING
2018/06/25 09:22:55 :: WPA_CLI RESULT IS SCANNING
2018/06/25 10:20:03 :: wpa_supplicant authentication may have failed.
2018/06/25 10:20:03 :: connect result is failed
2018/06/25 10:20:03 :: exiting connection thread
2018/06/25 10:20:03 :: Sending connection attempt result bad_pass
[...]
and so on with this BSSID. After I had removed all the old settings
from /etc/wicd/wireless-settings.conf, everything was OK.
> That sounds strange. I wonder if that could be triggered, if e.g. two
> different eduroam APs/BSSIDs are ticked with "use these settings
> for all wifis with this ESSID" but have different settings and it is
> e.g. luck which one is used (unless the BSSID fits).
That's possible. That would be the best explanation.
> As far as I remember from some discussions about potential rogue
> access points in general, at least WPA2 Enterprise (like with eduroam)
> uses some challenge/response methods for authentication, so a leaking
> of passwords should not be possible.
This is not what I've heard. A few weeks ago, our lab sent us a
warning that a recent flaw has been discovered. An excerpt from
the e-mail message:
------------------------------------------------------------------------
You **must** set the "CA certificate" field in your Eduroam
configuration, an all your devices (phone, laptop, ...). If you don't do
so, it is quite easy for an attacker to steal your ENS (or Inria) login
and password.
------------------------------------------------------------------------
So, IMHO, this is a critical bug.
I've found the following, which might be related:
https://wiki.geant.org/display/H2eduroam/EAP+Server+Certificate+considerations
And also:
https://community.jisc.ac.uk/library/janet-services-documentation/faqs-eduroam-users
"You should *ALWAYS* validate the server certificate - the option in
the supplicant (be it Windows native, SecureW2, OpenSEA et al) should
always be enabled. Certification is one of the main securing blocks of
EAP, which underpins the eduroam service.
If you don't verify that the RADIUS server (which is handling your
sensitive authentication credentials) is legitimate and not being
spoofed by an unscrupulous person, you are leaving yourself open to
having your credentials stolen. Maintaining the security of your
credentials is one of the requirements of the eduroam usage policy
that you subscribe to as part of using the service - ie. it is
mandatory."
I had always thought that the RADIUS server could be authenticated
automatically (a bit like servers with https) and that in any case
the password was never passed to the server, but apparently this is
not how the protocol works!
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian WICD Packaging Team <[email protected]>.
(Wed, 27 Jun 2018 03:12:02 GMT) (full text, mbox, link).
Subject: Bug#968033: Removed package(s) from unstable
Date: Sat, 22 Aug 2020 15:20:20 +0000
Version: 1.7.4+tb2-6+rm
Dear submitter,
as the package wicd has just been removed from the Debian archive
unstable we hereby close the associated bug reports. We are sorry
that we couldn't deal with your issue properly.
For details on the removal, please see https://bugs.debian.org/968033
The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.
Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.
This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
[email protected].
Debian distribution maintenance software
pp.
Sean Whitton (the ftpmaster behind the curtain)
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.