Vulnerability allows read/write/exec access on Ubuntu 16.04 Screenlock as lightdm user

Hi,

Thanks for reporting this issue.

What version of the unity-greeter package do you have installed, and could you also paste your /var/lib/polkit-1/localauthority/10-vendor.d/unity-greeter.pkla file?

Thanks.

Hi,

$ apt-cache policy unity-greeter
unity-greeter:
  Installé : 16.04.2-0ubuntu1
  Candidat : 16.04.2-0ubuntu1
 Table de version :
 *** 16.04.2-0ubuntu1 500
        500 http://fr.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
        100 /var/lib/dpkg/status

'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Content of /var/lib/polkit-1/localauthority/10-vendor.d/unity-greeter.pkla :

# DO NOT EDIT THIS FILE, it will be overwritten on update
# Place your local configurations under /etc/polkit-1/localauthority/

[Disable Controlling of Network Devices]
Identity=unix-user:lightdm
Action=org.freedesktop.NetworkManager.enable-disable-network;org.freedesktop.NetworkManager.enable-disable-wifi;org.freedesktop.NetworkManager.enable-disable-wwan;org.freedesktop.NetworkManager.enable-disable-wimax;
ResultActive=no
ResultInactive=no
ResultsAny=no

[Disable Sleep and Wake]
Identity=unix-user:lightdm
Action=org.freedesktop.NetworkManager.sleep-wake
ResultActive=no
ResultInactive=no
ResultsAny=no

[Disable WiFi Sharing]
Identity=unix-user:lightdm
Action=org.freedesktop.NetworkManager.wifi.share.protected;org.freedesktop.NetworkManager.wifi.share.open
ResultActive=no
ResultInactive=no
ResultsAny=no

[Disable Settings Modifications]
Identity=unix-user:lightdm
Action=org.freedesktop.NetworkManager.settings.modify.own;org.freedesktop.NetworkManager.settings.modify.system;org.freedesktop.NetworkManager.settings.modify.hostname
ResultActive=no
ResultInactive=no
ResultsAny=no

[Disable User Connections]
Identity=unix-user:lightdm
Action=org.freedesktop.NetworkManager.use-user-connections
ResultActive=no
ResultInactive=no
ResultsAny=no

[Enable Controlling of Network Connections]
Identity=unix-user:lightdm
Action=org.freedesktop.NetworkManager.network-control
ResultActive=yes
ResultInactive=no
ResultsAny=no

Thanks for reporting this issue. We've reproduced it and are working on a fix.

It looks like either the network manager applet or the network manager daemon isn't properly validating the org.freedesktop.NetworkManager.settings.modify.own and org.freedesktop.NetworkManager.settings.modify.system policies before displaying the certificate chooser dialog.

Yes, the only possibility I have to protect my laptop currently is to disable the wifi when I lock my screen :-)

Btw I tested on Ubuntu 14.04 but I was not able to open a nautilus on the lockscreen.

Aron is reaching out to the main upstream developer (in lieu of a security team there) to discuss the correct fix.

I tried to reach upstream maintainer on IRC (the GIMP one) but looks his offline at that moment, so I dropped him a line inviting him to this thread. We'll get back to you as soon as there's any update.

I don't think that the NetworkManager daemon is involved. Or PolicyKit permissions (like org.freedesktop.NetworkManager.settings.modify.own).

The login screen runs nm-applet as lightdm user.

nm-applet doesn't have a concept of running in a restricted mode. That is, it's running as a certain user and it doesn't try to prevent that user from accessing system resources (files) that the user can regularly access.
That is, when it shows the file-picker GUI to allow the user to choose a file, it doesn't try to prevent that user from seeing certain files (yes, it's made worse as the GTK filepicker allows to open the file).
The applet doesn't treat its user as a potential attacker.

How to fix that, is a good question...

Maybe applet could learn a new command line options ("--restricted"), which prevents the user from doing certain things that are considered unsafe.
  - maybe that means to show a less powerful filepicker that cannot open files,
  - maybe it also means to disallow the file-picker to mount filesystems (which makes the
    filepicker pretty useless),
  - in the end it probably means to prevent the user from creating any connection -- only to
    connect to previously configured networks.

Or maybe the login screen should choose to run a different applet instead (or none)...

Side note: On my Xenial machine I don't have access to nm-applet from the lock screen.

Ah, I can get to nm-applet if I go back to the greeter to switch users. i.e.

Create a second user called foo
Log in as myself
System Menu -> choose the foo user
Get a greeter
Open nm-applet

Am I right in thinking that we intended to deny switching networks from nm-applet in lightdm completely?

If I am, then I think the bug is probably that nm-applet is not doing that and is instead asking for creds (i.e. what Marc said in #4). That is - when you click on the network, it should say 'Insufficient privileges' instead of spawning the dialog. It seems to work correctly for me on Zesty, although I don't have one of those certificate networks to check with.

Maybe Quentin or Marc could check on Zesty too and confirm/deny?

More notes:

If I try to connect to an open wifi AP then I get an "Insufficient Privileges" error.
If I try to connect to a WPA protected AP, then I get an "Insufficient Privileges" error.
If I try to connect to a cert. protected AP (BT Wifi X for those in the UK), then I am able to exploit this problem.

Why would things be different for a cert. protected AP? Working this out seems to be a sensible step towards fixing the problem.

It's not really a nm-applet issue.

nm-applet is currently not designed to run in such a restricted mode which would make it safe to expose to unprivileged users.

It's a bug of the login screen to run an application that is not suitable for the security constraints of the login process.

It would be interesting to add a --restricted mode to nm-applet, but I wouldn't call that a bug. It's a missing feature. Until that feature is implemented, it's up to login screen not to use nm-applet.

Hm, I was pointed that was I said in #13 might be wrong... investigating.

Somewhat guessing: is it that in <https://git.gnome.org/browse/network-manager-applet/tree/src/applet-device-wifi.c?h=1.4.2#n591> nma_wifi_dialog_new() is called before doing any polkit checks?

In reply to comment #11 - this happens on Zesty as well. It is slightly different in that I get a black screen when I try to open file manager, but the I expect those with more determination would be able to work around that.

Re: #14.

NetworkManager does not trust its D-Bus clients and uses PolicyKit to check whether a certain user action is allowed or denied. NetworkManager's D-Bus API exposes these PolicyKit permissions to the client, and they are accessible via libnm (nm_client_get_permission_result()).

Maybe nm-applet could implement a restricted mode by autodetecting which parts are restricted using PolicyKit permissions. However, it doesn't. If you look at the code, the permission checks there are merely to see whether a certain GUI option should be enabled or not. The intend is to avoid exposing a UI option that is know to fail, not to protect the system from the user.

I think what I said in comment #13 is correct.

Not sure. We can explicitly check the permissions before showing the dialog. See the attached patch.

As noted, most other actions already do this - it's just that _do_new_auto_connection () decides on its own to create the dialog, even if the user doesn't have the right permissions.

Could someone test and review the patch? Turns out I do have one of those BTWifi-X things near me (whatever they are), so I was able to check that it seems OK for me. I can't cover all usecases though, for example I don't have one of those networks that I can connect to.

I guess it leaks `connection' at least?

at least for me, there is also an "Edit Connections" option, which spawns nm-connection-editor, which has the same problem.

Edit Connections doesn't seem to be exposed in Xenial or Zesty at the greeter.

On Fri, Mar 03, 2017 at 02:30:33PM -0000, Will Cooke wrote:
> Edit Connections doesn't seem to be exposed in Xenial or Zesty at the
> greeter.

That's because we have a distro patch (just learned that) to hide the
items if the user doesn't have modify.own, modify.system or
modify.hostname.

I'm happy for us to apply this patch as a distro patch too, if that's
preferred and Thomas doesn't want it upstream.

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

I think the patch is the right approach (maybe it's not yet perfect, but goes the right direction).

I think we definitely want such patches upstream.

I talked now with dcbw, he confirmed and applet is supposed to be suitable for a login-screen. If it isn't, it's a bug. (I was wrong there!!, sorry).

The lightdm user should not be able to access any useful certificate files from the system. Thus, choosing a certification from file seems to be only useful, if the user could mount an USB stick -- which the lightdm user shouldn't be able to do.
So, the non-logged-in user can realistically only create non-enterprise connections, which doesn't seem too useful either.
So, creating/modifying *any* connection from the loginscreen shouldn't be possible from the login-screen (and prevented by having no MODIFY_SYSTEM|MODIFY_OWN permissions).
Ergo: the user shall only be able to connect to existing connections that are already provisioned previously.

I think there is a additional issue, that if the connection has secrets that are agent-owned, NM will present a password-popup to the user (good). But then, the ligthdm user must not put those secrets into the keyring, otherwise, the next time a malicious user could see those previously entered passwords.
Either applet must not try to cache such passwords, or the keyring must not be accessible for the lightdm user.

I've build these packages with Laney's patch:

for xenial: this stacks on the nm-1.2.6 packages in -proposed
https://launchpad.net/~happyaron/+archive/ubuntu/ppa/+sourcepub/7529909/+listing-archive-extra

for zesty:
https://launchpad.net/~happyaron/+archive/ubuntu/ppa/+sourcepub/7529920/+listing-archive-extra

I've freed the connection before return to avoid the mem leak
mentioned by Laney, but there looks to be more stuff could be leaked
(i.e. s_con, s_wifi, s_wsec, s_8021x).

On Mon, Mar 06, 2017 at 08:01:16AM -0000, Aron Xu wrote:
> but there looks to be more stuff could be leaked (i.e. s_con, s_wifi,
> s_wsec, s_8021x).

No I don't think so, those are all passed to nm_connection_add_setting()
which causes the connection to take ownership of them.

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

Just tested on Xenial - the free is causing nm-applet to crash with an invalid pointer message.

Spoke to Aron who is going to upload a different version for testing.

Tested the new version, it works. I now get the insufficient privileges error when trying to connect to a cert. authenticated network.

Aron is going to rework the patch with a free in. This should be ready soon and we can upload the fix later on today.

Tested the new version from Aron's PPA with the free. Works as expected. Aron will attach patches here and then we're ready to roll it out.

@thaller-1 - let us know if you'd like these patches upstreaming, or if you're planning on doing something yourself.

Please email a link with the downstream patches to <email address hidden> . Thanks

Attached is a slightly modified version of Laney's patch, with help from him on avoiding memory leak. The patch should work for all the x, y and z series.

Since this has a security impact, the package needs to be built as a security update. Please let me know once the final version of the patch is attached, and I'll prepare builds as a security release.

Thanks!

On Mon, Mar 06, 2017 at 12:04:02PM -0000, Aron Xu wrote:
> Attached is a slightly modified version of Laney's patch, with help from
> him on avoiding memory leak. The patch should work for all the x, y and
> z series.

Looks like you used spaces instead of tabs for the g_clear_object()
line, but otherwise I think this is okay (can hopefully be fixed when
uploading) - Marc, is the patch alone enough for you to go on or do you
want debdiffs?

Cheers,

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

The patch is fine, I'm currently building packages to go through testing. I'll take it from here. Thanks!

We will probably be publishing updates for this issue on 2017-03-07.

Who do we credit for discovery of this vulnerability? (Our policy is to credit individuals, not organizations...names please...)

This bug was fixed in the package network-manager-applet - 0.9.8.8-0ubuntu4.5

---------------
network-manager-applet (0.9.8.8-0ubuntu4.5) trusty-security; urgency=medium

  * SECURITY UPDATE: file access from login screen (LP: #1668321)
    - debian/patches/applet-Check-the-user-has-permission-to-modify-befor.patch:
      check permissions before showing dialog in src/applet-device-wifi.c.
    - No CVE number

 -- Marc Deslauriers <email address hidden> Mon, 06 Mar 2017 07:30:10 -0500

This bug was fixed in the package network-manager-applet - 1.2.6-0ubuntu0.16.04.2

---------------
network-manager-applet (1.2.6-0ubuntu0.16.04.2) xenial-security; urgency=medium

  * SECURITY UPDATE: file access from login screen (LP: #1668321)
    - debian/patches/applet-Check-the-user-has-permission-to-modify-befor.patch:
      check permissions before showing dialog in src/applet-device-wifi.c.
    - No CVE number

 -- Marc Deslauriers <email address hidden> Mon, 06 Mar 2017 07:28:53 -0500

This bug was fixed in the package network-manager-applet - 0.9.4.1-0ubuntu2.6

---------------
network-manager-applet (0.9.4.1-0ubuntu2.6) precise-security; urgency=medium

  * SECURITY UPDATE: file access from login screen (LP: #1668321)
    - debian/patches/applet-Check-the-user-has-permission-to-modify-befor.patch:
      check permissions before showing dialog in src/applet-device-wifi.c.
    - No CVE number

 -- Marc Deslauriers <email address hidden> Mon, 06 Mar 2017 11:26:10 -0500

This bug was fixed in the package network-manager-applet - 1.2.6-0ubuntu1.1

---------------
network-manager-applet (1.2.6-0ubuntu1.1) yakkety-security; urgency=medium

  * SECURITY UPDATE: file access from login screen (LP: #1668321)
    - debian/patches/applet-Check-the-user-has-permission-to-modify-befor.patch:
      check permissions before showing dialog in src/applet-device-wifi.c.
    - No CVE number

 -- Marc Deslauriers <email address hidden> Mon, 06 Mar 2017 07:26:34 -0500

Nice find. There is another lock screen bypass that still exists if you hold right click option down before the screensaver activates. I don't believe that has even been fully and properly patched and has existed for years. And now the accessibility features seem like ripe targets for further review too. Makes you wonder just how many other local bypass issues still exist (or have been planted by espionage agencies).

> Marc Deslauriers (mdeslaur) wrote on 2017-03-06: #34
> We will probably be publishing updates for this issue on 2017-03-07.

> Who do we credit for discovery of this vulnerability? (Our policy is to credit individuals, not > > organizations...names please...)

We discovered Frederic Bardy (<email address hidden> and me (<email address hidden>).

Thanks, I've updated the online version of the USN to properly credit you:

https://www.ubuntu.com/usn/usn-3217-1/

This bug was fixed in the package network-manager-applet - 1.4.2-1ubuntu3

---------------
network-manager-applet (1.4.2-1ubuntu3) zesty; urgency=medium

  * SECURITY UPDATE: file access from login screen (LP: #1668321)
    - debian/patches/applet-Check-the-user-has-permission-to-modify-befor.patch:
      check permissions before showing dialog in src/applet-device-wifi.c.
    - No CVE number

 -- Marc Deslauriers <email address hidden> Wed, 08 Mar 2017 07:51:25 -0500

Is it a cve number delivered for this vuln ?

There is no CVE number. Please request one here:

https://cveform.mitre.org/