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

Bug #1668321 reported by BIGUENET Quentin on 2017-02-27
272
This bug affects 1 person
Affects Status Importance Assigned to Milestone
network-manager-applet (Ubuntu)
Status tracked in Zesty
Precise
High
Marc Deslauriers
Trusty
High
Marc Deslauriers
Xenial
High
Marc Deslauriers
Yakkety
High
Marc Deslauriers
Zesty
High
Aron Xu

Bug Description

Hi,

We just found a vulnerability in lightdm who could lead us to read files with lightdm permissions, an also write in some directories.
We were able to download a reverse_shell payload and execute it in order to gain a reverse shell as lightdm on a remote system.

The exploitation require a physical access to the locked computeur and the Wi-fi must be turned on. A access point who let you use a certificate to log-in is required as well but it's easy to create one.

Then, it's possible to open a nautilus window and browse directories. We also can open some application such as Firefox which is useful to download malicious binaries :-)

See this video for the PoC :
https://www.youtube.com/watch?v=Fp2lwRVg0l0

---------
Some info about the Ubuntu version I used on the video above :

$ lsb_release -rd
Description: Ubuntu 16.04.2 LTS
Release: 16.04

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

I let you time for correction before publishing the discovery.

If you have any question please let me know!

Regards,

Quentin Biguenet

--
Orange Cyber-Defense
<email address hidden>

CVE References

affects: unity (Ubuntu) → lightdm (Ubuntu)
Marc Deslauriers (mdeslaur) wrote :

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.

BIGUENET Quentin (qbiguenet) wrote :

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

Marc Deslauriers (mdeslaur) wrote :

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

Changed in lightdm (Ubuntu):
status: New → Confirmed
affects: lightdm (Ubuntu) → network-manager-applet (Ubuntu)
summary: - Vulnerability in lightdm allow read/write/exec access on Ubuntu 16.04
- Screenlock as lightdm user
+ Vulnerability allows read/write/exec access on Ubuntu 16.04 Screenlock
+ as lightdm user
Will Cooke (willcooke) on 2017-03-01
Changed in network-manager-applet (Ubuntu):
assignee: nobody → Aron Xu (happyaron)
Marc Deslauriers (mdeslaur) wrote :

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.

BIGUENET Quentin (qbiguenet) wrote :

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.

Will Cooke (willcooke) wrote :

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

Will Cooke (willcooke) on 2017-03-02
Changed in network-manager-applet (Ubuntu):
importance: Undecided → High
Aron Xu (happyaron) wrote :

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.

Thomas Haller (thaller-1) wrote :

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)...

Will Cooke (willcooke) wrote :

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

Will Cooke (willcooke) wrote :

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

Iain Lane (laney) wrote :

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?

Will Cooke (willcooke) wrote :

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.

Thomas Haller (thaller-1) wrote :

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.

Thomas Haller (thaller-1) wrote :

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

Iain Lane (laney) wrote :

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?

Will Cooke (willcooke) wrote :

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.

Thomas Haller (thaller-1) wrote :

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.

Iain Lane (laney) wrote :

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.

Iain Lane (laney) wrote :

I guess it leaks `connection' at least?

Thomas Haller (thaller-1) wrote :

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

Will Cooke (willcooke) wrote :

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> ]

Thomas Haller (thaller-1) wrote :

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.

Aron Xu (happyaron) wrote :

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).

Iain Lane (laney) wrote :

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> ]

Will Cooke (willcooke) wrote :

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.

Will Cooke (willcooke) wrote :

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.

Will Cooke (willcooke) wrote :

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.

Thomas Haller (thaller-1) wrote :

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

Aron Xu (happyaron) 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.

Marc Deslauriers (mdeslaur) wrote :

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!

Iain Lane (laney) wrote :

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> ]

Marc Deslauriers (mdeslaur) wrote :

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

Changed in network-manager-applet (Ubuntu Precise):
status: New → Confirmed
Changed in network-manager-applet (Ubuntu Trusty):
status: New → Confirmed
Changed in network-manager-applet (Ubuntu Xenial):
status: New → Confirmed
Changed in network-manager-applet (Ubuntu Yakkety):
status: New → Confirmed
Changed in network-manager-applet (Ubuntu Precise):
assignee: nobody → Marc Deslauriers (mdeslaur)
Changed in network-manager-applet (Ubuntu Trusty):
assignee: nobody → Marc Deslauriers (mdeslaur)
Changed in network-manager-applet (Ubuntu Xenial):
assignee: nobody → Marc Deslauriers (mdeslaur)
Changed in network-manager-applet (Ubuntu Yakkety):
assignee: nobody → Marc Deslauriers (mdeslaur)
Changed in network-manager-applet (Ubuntu Precise):
importance: Undecided → High
Changed in network-manager-applet (Ubuntu Trusty):
importance: Undecided → High
Changed in network-manager-applet (Ubuntu Xenial):
importance: Undecided → High
Changed in network-manager-applet (Ubuntu Yakkety):
importance: Undecided → High
Marc Deslauriers (mdeslaur) wrote :

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...)

Launchpad Janitor (janitor) wrote :

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

Changed in network-manager-applet (Ubuntu Trusty):
status: Confirmed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in network-manager-applet (Ubuntu Xenial):
status: Confirmed → Fix Released
information type: Private Security → Public Security
Launchpad Janitor (janitor) wrote :

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

Changed in network-manager-applet (Ubuntu Precise):
status: Confirmed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in network-manager-applet (Ubuntu Yakkety):
status: Confirmed → Fix Released
tags: added: patch

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).

BIGUENET Quentin (qbiguenet) wrote :

> 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>).

Marc Deslauriers (mdeslaur) wrote :

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

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

Launchpad Janitor (janitor) wrote :

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

Changed in network-manager-applet (Ubuntu Zesty):
status: Confirmed → Fix Released
BIGUENET Quentin (qbiguenet) wrote :

Is it a cve number delivered for this vuln ?

Marc Deslauriers (mdeslaur) wrote :

There is no CVE number. Please request one here:

https://cveform.mitre.org/

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

Other bug subscribers

Bug attachments