wireless treats driver failure as network security refusal

Bug #1487620 reported by Teunis Peters
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
New
Undecided
Unassigned

Bug Description

I've a Lenovo 585 with Broadcom Corporation BCM4313 802.11bgn Wireless Network Adapter - this combination leads to frequent driver failures (sudden component shutdowns) with sound and network hardware being the most likely to temporarily abort.
(this isn't the first laptop I've seen this problem on either)

Every time the hardware crashes and resets, network-manager treats this as a security abort and asks (erroneously) for network credentials.

a: this disrupts all running program and puts up a modal dialogue
b: this is unnecessary, because above.
c: this is a security risk because it will try (under normal circumstances) to hop networks until it finds an open one, and this can put the unit into a secure vulnerable state.

I'm happy to help provide more info - this bug hits me anywhere up to several times an hour.

recommend : this is a security risk / serious / blocking (fix asap) bug.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: network-manager 0.9.10.0-4ubuntu15.1
ProcVersionSignature: Ubuntu 3.19.0-26.28-generic 3.19.8-ckt4
Uname: Linux 3.19.0-26-generic x86_64
NonfreeKernelModules: fglrx wl
ApportVersion: 2.17.2-0ubuntu1.3
Architecture: amd64
CurrentDesktop: KDE
Date: Fri Aug 21 14:20:55 2015
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2013-09-28 (692 days ago)
InstallationMedia: Linux Mint 15 "Olivia" - Release amd64 (20130520)
IpRoute:
 default via 10.253.0.1 dev wlan0 proto static metric 1024
 1.1.1.1 via 10.253.0.1 dev wlan0 proto dhcp metric 10
 10.253.0.0/16 dev wlan0 proto kernel scope link src 10.253.0.20
 169.254.0.0/16 dev wlan0 scope link metric 1000
 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
SourcePackage: network-manager
UpgradeStatus: No upgrade log present (probably fresh install)
nmcli-dev:
 DEVICE TYPE STATE DBUS-PATH CONNECTION CON-UUID CON-PATH
 wlan0 wifi connected /org/freedesktop/NetworkManager/Devices/2 IUGO_STAFF 25f36dd0-8cfa-4336-91a4-2ac49e7c3b4d /org/freedesktop/NetworkManager/ActiveConnection/7
 eth0 ethernet unavailable /org/freedesktop/NetworkManager/Devices/1 -- -- --
 lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/0 -- -- --
 virbr0-nic tap unmanaged /org/freedesktop/NetworkManager/Devices/3 -- -- --
nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'.

Revision history for this message
Teunis Peters (teunis) wrote :
Revision history for this message
Tyler Hicks (tyhicks) wrote : Bug is not a security issue

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

information type: Private Security → Public
tags: added: vivid
Revision history for this message
Teunis Peters (teunis) wrote :

The "being pushed onto the nearest open network" is the security risk part of the bug.

Revision history for this message
Teunis Peters (teunis) wrote :

Open networks are a direct security risk, at least in some locations. And that does include the neighbours of my office. It's not "immediately obvious" one has been put into a security risk situation if one is busy working.

There's also no obvious way to mark a network (even if it's visibly a honey pot for harvesting passwords) as unhealthy/bad, because the above bug will mean the system automatically connects.

Revision history for this message
Teunis Peters (teunis) wrote :

However, it blacklisting the active and VALID network because of a driver fault - that's not a security risk, that's just an ongoing nightmare. After it goes through the entire group of valid networks, that's when it starts hopping onto honeypots, and I can usually catch it before then.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.