fprintd allows unauthorized root access

[Christopher Barrington-Leigh]

For some reason, fprintd-enroll does not require any special authorization to run.

This means that anyone coming across or stealing a machine with it installed and which is currently logged in and for which fingerprints are enabled for sudo authentication can elevate their access to superuser by simply running fprintd-enroll and scanning their own fingers. A subsequent sudo command will then give the new user access.

Even if sudo access is not granted through fingerprints, a thief could get continued access to someone's account (for subsequent logging in) if they can enroll new fingerprints without re-authenticating as the original user.

This seems a security threat.

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: fprintd 0.6.0-1
ProcVersionSignature: Ubuntu 4.2.0-23.28-generic 4.2.6
Uname: Linux 4.2.0-23-generic x86_64
ApportVersion: 2.19.1-0ubuntu5
Architecture: amd64
CurrentDesktop: Unity
Date: Fri Jan 8 11:35:02 2016
EcryptfsInUse: Yes
InstallationDate: Installed on 2015-12-18 (21 days ago)
InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
SourcePackage: fprintd
UpgradeStatus: No upgrade log present (probably fresh install)

[Seth Arnold (seth-arnold)]

I don't see any PAM modules in the fprintd package when I installed it into a test VM. This issue may be in whatever PAM module package uses fprintd rather than the fprintd package itself. Which PAM module did you install to get this behaviour?

Thanks

[Christopher Barrington-Leigh (cpbl)]

Hi Seth,
 Sorry. Can you tell me anything about what I might do to find the answer to this question?

Or, in case this helps, here is what I have in my install notes:

# Fingerprint reader
sudo apt-get update
sudo apt-get install libpam-fprintd libfprint0 fprint-demo fprintd
#Then run this command to configure pam:. I don't really understand this, and I just left them all on / as default.
sudo pam-auth-update
#Finally enroll your finger with: (for x230, just use thumb instead of finger)
fprintd-enroll

[Seth Arnold (seth-arnold)]

Interesting, the pam/pam_fprintd.c file has the following function that would be used for the pam_chauthtok(3) function:

PAM_EXTERN int pam_sm_chauthtok(pam_handle_t *pamh, int flags, int argc,
                                const char **argv)
{
        return PAM_SUCCESS;
}

If I've read this correctly, this is more than a misconfiguration of a PAM configuration file -- the module was apparently never intended to enforce authentication before updating authentication tokens.

I filed a bug report upstream: https://github.com/dsd/pam_fprint/issues/2

Thanks

[Biber (c-woltmann)]

Hello!

Just came across the bug myself. Some googling and voila, here I am. Thanks for already making the point clear and posting the description!

Until a proper solution is published, I think one can limit the danger by disallowing ordinary users from enrolling (and other stuff):

sudo chmod o-x /usr/bin/fprintd*

If you wish to re-enroll/change ordinary user's fingerprints, use sudo and the [username] option (see fprintd-enroll manpage):

sudo fprintd-enroll [username]

I hope that helps for now, cheers,

Bb

[Christopher Barrington-Leigh (cpbl)]

This seems to me to have been changed ("fixed") now: I need to use sudo to initiate fprintd-enroll.
However, with that change came a change in the behaviour of enroll. It only asks for one fingerprint scan, rather than five.
 The result seems to be that the finger print reader has terrible performance: I usually need to try several times to get a successful reading, whereas when the enroll process took multiple scans, it would get it right every time.

(Should this be a new issue?)

[Rob Havasy (motld)]

I'm using 16.04 and installed from the default repos with a simple "sudo apt install libpam-fprintd", and I'm seeing the same (original) behaviour, as in fprintd-enroll doesn't require root to change the enrolled fingerprints (and asks for 5 swipes to confirm enrollment).

The chmod o-x suggestion worked in that executing fprintd-enroll now requires root, but I suspect whatever files it writes to are still vulnerable to someone accessing my (rarely) unlocked and unattended machine, but at least now they'd have to come prepared with their own fingerprint enrollment files instead of just running it from a terminal and swiping a few times. This also seems like it would be an easy fix in the repo package, at least until a proper upstream fix is done. Is anyone even working on fprintd upstream anymore, though?

[Rob Havasy (motld)]

Upon further reflection, instead of chmod o-x, use chmod 700. Otherwise, the fprintd-enroll executable can be copied to the home directory and executed from there, successfully changing the enrolled prints without requiring root.

[Seth Arnold (seth-arnold)]

Protecting the executable is a lost cause -- afterall, we host thousands of copies of it on our archive mirror network, and there are tens of millions more on Ubuntu machines around the world.

Protecting the enrollment files may be more useful.

Thanks

[Rob Havasy (motld)]

My thoughts exactly. It seems the enrollment files are stored in /var/lib/fprintd, which is already restricted to root access with read access for others, and the directories and files under it are root only without even read permissions for others, yet fprintd-enroll seems able to change them even when not run as root. What am I missing here?

[Marco Trevisan (Treviño) (3v1n0)]

Mh, ok... I didn't think much about this as that was something possible using gnome-control-center UI or just dbus-calls.

In fact gnome-contrl-center doesn't require any unlocking operation for setting the fingerprints, by default.

However pfrintd already supports policykit correctly, so IMHO we can be safe in shipping also that binary, the only important needed action for us is to patch the file 'net.reactivated.fprint.device.policy' so that the allow_active is set to auth_self_keep instead of yes (auth_self would be more restrictive, but prompting the password again during the enroll process isn't nice).

By doing that both fprintd-enroll and fprintd-delete will just require an user authentication, such as gnome-control-center.

[Marco Trevisan (Treviño) (3v1n0)]

Ah, on a side note, in ubuntu we want to enable the fingerprint unlocking, not at login stage.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "policykit-enroll-auth-self.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Marco Trevisan (Treviño) (3v1n0)]

I've submitted the bug upstream too, so you can replace the patch in the debdiff with one attached here.

[Iain Lane (laney)]

Bastien says this is buggy after the auth times out?

[Simon Quigley (tsimonq2)]

Bump.

I'm unsubscribing the Security Sponsors Team for now because Iain's comment suggests concerns with the patches that should be addressed before uploading.

Please resubscribe us once there is an adequate patch.

Thank you.

[Steve Sether (stevesether)]

Is there something I can do to expedite this? I submitted a bug that wound up being a duplicate of this one, and even created and tested a patch to the config. The config change is pretty trivial, and worked perfectly in my testing. I'm not sure why this wouldn't be considered a permanent fix rather than a workaround.

The fix is pretty trivia, and involves changing a default in the file

/usr/share/polkit-1/actions/net.reactivated.fprint.device.policy

to:

  <action id="net.reactivated.fprint.device.enroll">
    <description>Enroll new fingerprints</description>
.
.
.
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>auth_self_keep</allow_active>
    </defaults>

The previous default was:
       <allow_active>yes</allow_active>

Duplicate bug I created: https://bugs.launchpad.net/bugs/1901132

[Marco Trevisan (Treviño) (3v1n0)]

As you can see reading this old bug, the polkit rule fix is known, and I've been working upstream to address this.

However as you can see [1] that simple change was not enough.
In fact as you can read in this documentation [2] the polkit method that we call to check if an user is allowed to run a command, is run synchronously and this may lead fprintd to hang and stop doing other operations (that can be both in the driver or for other requests coming by other users).

So, while the workaround can be acceptable in a single-user and single-request scenario, it could end up having problems in case the OS tries to do other requests to the fingerprint daemon while it's blocked.

A situation could be that if you start the enrollment process and for some reason you don't complete within the auto-screen-lock time, then you may end up in freezing your system.

Or in any other case... Fprintd is meant to be called by multiple applications other than the OS (even if right now very few use it), but ideally a Browser or an application may request you to use your fingerprint, and that could happen while the daemon is hanging, causing an unexpected behavior.

Said that, as you can see the fix is merged and released in latest fprintd version that I'm currently packaging and soon backporting to 20.04, so even if with some delay we're handling this. Properly, finally.

[1] https://gitlab.freedesktop.org/libfprint/fprintd/-/merge_requests/74
[2] https://www.freedesktop.org/software/polkit/docs/latest/PolkitAuthority.html#polkit-authority-check-authorization-sync

[Steve Sether (stevesether)]

Thanks for explaining the larger problem here. It's a bit frustrating that this bug has existed for more than 9 years, (it seems the original fix was put in in 2011), but it's taken this long to finally swat it.

Sounds like we're finally on the right path to getting this fixed. Thanks again.

[Marco Trevisan (Treviño) (3v1n0)]

Yeah, I agree on that... I also had a fix ready for more than a year now, but the fprintd upstream state in the past years wasn't always active (mostly due to the fact that hw producers didn't support sensors, so there was only some community involvement), so it took a bit longer before it could hit an upstream release (and given the size of the change, wasn't something we could handle in Ubuntu as distro-patch).

It's also true that Ubuntu fully supports fprintd (as a "main" package) for few releases, and the first LTS was 20.04.

[Launchpad Janitor (janitor)]

This bug was fixed in the package fprintd - 1.90.7-1

---------------
fprintd (1.90.7-1) unstable; urgency=medium

  * New upstream release
    - Fix fprintd DBus configuration (Closes: #976990)
    - Change details of what requires authorization
    - Fix various race conditions in pam_fprintd
    - Permit interactive authorization from fprintd utilities
    - Do not allow deletion while another operation is ongoing
    - pam: Guard strdup calls against NULL pointers
  * debian/patches:
    - Refresh
    - Ignore NameOwnerChanged until fprintd is running

 -- Marco Trevisan (Treviño) <email address hidden> Fri, 11 Dec 2020 00:03:27 +0100

[Chris Halse Rogers (raof)]

Hello Christopher, or anyone else affected,

Accepted fprintd into groovy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/fprintd/1.90.9-1~ubuntu20.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-groovy to verification-done-groovy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-groovy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Chris Halse Rogers (raof)]

Hello Christopher, or anyone else affected,

Accepted fprintd into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/fprintd/1.90.9-1~ubuntu20.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Brian Murray (brian-murray)]

The fix for this bug has been awaiting testing feedback in the -proposed repository for focal for more than 90 days. Please test this fix and update the bug appropriately with the results. In the event that the fix for this bug is still not verified 15 days from now, the package will be removed from the -proposed repository.

[Marco Trevisan (Treviño) (3v1n0)]

Both with fprintd-enroll and using g-c-c now a password prompt is required when enrolling a new fingerprint.

This works concurrently when multiple users are trying to enroll.

❯ apt-cache policy fprintd
fprintd:
  Installato: 1.90.9-1~ubuntu20.04.1
  Candidato: 1.90.9-1~ubuntu20.04.1
  Tabella versione:
 *** 1.90.9-1~ubuntu20.04.1 400
        400 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages
        100 /var/lib/dpkg/status

[Chris Halse Rogers (raof)]

Is this also going to be verified for Groovy?

[Sebastien Bacher (seb128)]

@Chris, we are short on resources to do non LTS verifications, we will eventually get to it but is it getting in the way of the fix to be made available to LTS users now?

[Łukasz Zemczak (sil2100)]

Ok, I'll be proceeding with releasing this to focal users. But one thing to consider: since this feels like a security-related fix, should we maybe reach out to -security to get the package rebuilt and pushed there as well?

[Launchpad Janitor (janitor)]

This bug was fixed in the package fprintd - 1.90.9-1~ubuntu20.04.1

---------------
fprintd (1.90.9-1~ubuntu20.04.1) focal; urgency=medium

  * Backport to focal (LP: #1908119)

fprintd (1.90.9-1) unstable; urgency=medium

  [ Marco Trevisan (Treviño) ]
  * New upstream release:
    - Fix multiple daemon lockup issues (#97)
    - Fix print garbage collection to not delete used prints
    - pam: Use the device with the most prints
  * debian/control: Mark fprintd-doc as Multi-Arch: foreign

  [ Helmut Grohne ]
  * Fix nocheck FTFBS: Drop <!nocheck> from non-optional dependencies.
    (Closes: #977395)

fprintd (1.90.8-1~ubuntu20.04.1) focal; urgency=medium

  * Backport to focal (LP: #1908119)
  * debian/{control,gbp.conf}: Prepare for ubuntu focal branching
  * debian/{control, rules}: Do not use debhelper 13 features
  * debian/rules: Use meson test directly to handle timeouts
  * debian/patches: Drop all the patches applied upstream

fprintd (1.90.8-1) unstable; urgency=medium

  * New upstream release
    - pam: Only listen to NameOwnerChanged after fprintd is known to run
    - Place new ObjectManager DBus API at /net/reactivated/Fprint
  * debian/patches: Remove all patches, applied upstream or not needed anymore
  * debian/control: Depend on systemd 235, but only in linux
  * debian/rules: Require systemd and set unit path only on linux
  * debian/fprintd.install: Use dh-exec to filter linux-only files

fprintd (1.90.7-1) unstable; urgency=medium

  * New upstream release
    - Fix fprintd DBus configuration (Closes: #976990)
    - Change details of what requires authorization
    - Fix various race conditions in pam_fprintd
    - Permit interactive authorization from fprintd utilities
    - Do not allow deletion while another operation is ongoing
    - pam: Guard strdup calls against NULL pointers
  * debian/patches:
    - Refresh
    - Ignore NameOwnerChanged until fprintd is running

fprintd (1.90.5-2) unstable; urgency=medium

  * debian/patches: Make tests run with actual required libfprint version
  * debian/control: Remove test-only dependency on libfprint 1.90.4.
    Tests are now working with older libfprint versions too
  * debian/control: Add myself to Uploaders
  * debian/gbp.conf: Include suggested settings by GNOME team.
    Even if fprintd is not part of GNOME I think these settings are good
    practice anyways.

fprintd (1.90.5-1) unstable; urgency=medium

  * New upstream release:
    - Permit building with polkit older than 0.114
    - Fix possible issues with PAM test
    - Fix incorrect DBus policy
    - Fix build so that CFLAGS environment is correctly used
    - Skip hotplug test with older libfprint (which times out otherwise)
  * debian/patches: Drop patches applied upstream

fprintd (1.90.4-1) unstable; urgency=medium

  * Team upload.
  [ Marco Trevisan (Treviño) ]
  * New upstream release:
    - Use GDBus and async Polkit checks
    - Authentication is now required to enroll a new print (LP: #1532264,
      Closes: #719004)
    - Add support for the libfprint early reporting mechanism
    - Proper hotplug support together with libfprint 1.90.4
    - Handle STATE_DIRECTORY containing multiple paths
    - Vario...

[Łukasz Zemczak (sil2100)]

The verification of the Stable Release Update for fprintd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Brian Murray (brian-murray)]

The Groovy Gorilla has reached end of life, so this bug will not be fixed for that release