Bug 488633 - VUL-2: networkmanager silently accepts no encryption
Summary: VUL-2: networkmanager silently accepts no encryption
Status: CONFIRMED
Alias: None
Product: SUSE Security Incidents
Classification: Novell Products
Component: General (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Normal
Target Milestone: ---
Deadline: 2009-04-22
Assignee: Security Team bot
QA Contact: Security Team bot
URL:
Whiteboard: .
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-25 10:21 UTC by Ludwig Nussel
Modified: 2018-10-30 15:21 UTC (History)
2 users (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ludwig Nussel 2009-03-25 10:21:41 UTC
The issue is public.

The only logical consequence of a known AP dropping encryption is to terminate the connection IMO. There must be no reconnect whatsoever.

Date: Tue, 24 Mar 2009 19:17:44 +0100
From: Christoph Höger <choeger@cs.tu-berlin.de>
To: networkmanager-list@gnome.org
Subject: networkmanager should warn if ap changes encryption

Hi,

there seems to be an issue with some APs and their enryption value[1].
Somehow they 'forget' about the chosen encryption and continue
unencrypted. NM will happily accept that change and continue to use that
wireless network which leads to the owner not noting the change.

To make NM more secure I would argue that NM should notify the user if
an AP changes _any_ connection parameter since the last successfull
connection.

If this takes time to implement, I am willing to work on a patch for
that.

regards

christoph

[1] (in german)
http://www.heise.de/newsticker/WLAN-wirklich-verschluesselt--/meldung/135021
Comment 3 Helmut Schaa 2009-04-01 11:37:15 UTC
Tambet, I guess the following scenario describes the request too:

- User has a Novell SSID configured (with WPA-EAP)
- Eve creates a rogue AP also named Novell but without encryption

nm-applet will allow the user to connect to the rogue AP with only one click. If NM would first check if another connection (with better security) exists it might warn about that.

At least that's how I interpret this report, reassigning ;)
Comment 4 Tambet Ingo 2009-04-01 12:29:04 UTC
Ok, so in that case nm-applet creates a new NMConnection for it and successfully connects, so yes, I agree that there should be a warning. I did understand that report differently, I guess the same way as Ludwig did (that an AP would change it's configuration on it's own during an active session).
Comment 5 Helmut Schaa 2009-04-01 12:33:29 UTC
(In reply to comment #4)
> I did
> understand that report differently, I guess the same way as Ludwig did (that an
> AP would change it's configuration on it's own during an active session).

AFAIK, in that case the AP would have to disassociate all clients resulting in NM not reconnecting to it automatically. Everything else would be an AP bug.
Comment 6 Thomas Biege 2009-04-29 09:18:39 UTC
What is planned to handle this issue?
Comment 7 Tambet Ingo 2009-04-29 09:50:20 UTC
It is planned to show a warning/confirmation dialog when a request is made to activate a wifi connection without any security when there's existing configuration with the same SSID and security information.
Comment 8 Ludwig Nussel 2009-04-29 11:42:09 UTC
Since it's not really that urgent to require a immediate update we add this to the list of planned updates (ie for next sp latest).
Comment 14 Ludwig Nussel 2011-10-18 11:50:24 UTC
a warning dialog still does not exist even in NM 0.9. Not actually a vulnerability so leaving open as enhancement.