Bug 1693356 - fprintd: stores user fingerprints as image files without encryption
Summary: fprintd: stores user fingerprints as image files without encryption
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1693357
Blocks: 1693359
TreeView+ depends on / blocked
 
Reported: 2019-03-27 16:02 UTC by Laura Pardo
Modified: 2021-02-16 22:11 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2019-04-09 05:54:03 UTC
Embargoed:


Attachments (Terms of Use)

Description Laura Pardo 2019-03-27 16:02:38 UTC
It was found that fprintd saves fingerprint data, in ISO/IEC 19794-2 format and without any encryption, to a file with root permission on the host. This could allow a privileged process to access the stored fingerprint.


Upstream Bug:
https://gitlab.freedesktop.org/libfprint/fprintd/issues/16

Comment 1 Laura Pardo 2019-03-27 16:02:52 UTC
Created fprintd tracking bugs for this issue:

Affects: fedora-all [bug 1693357]

Comment 2 Laura Pardo 2019-03-28 13:12:08 UTC
Acknowledgments:

Name: Seong-Joong Kim

Comment 4 Huzaifa S. Sidhpurwala 2019-04-09 05:54:03 UTC
The fprintf daemon in Red Hat Enterprise Linux is contained by the default installed selinux policy. This prevents other applications (which dont need access to fingerprint data) from accessing this fingerprint data and therefore ensures a good level of security for the same. 

Also as per upstream: https://gitlab.freedesktop.org/libfprint/fprintd/issues/16#note_141207 
such an LSM based security system should be enough to safeguard this data. And there is no short term plan for any other implementation.

Based on above, Red Hat Product Security does not believe this to be a security flaw.

Comment 5 Seong-Joong Kim 2019-04-11 05:21:24 UTC
I don’t think it would be as good.
Particularly, desktop users usually disable or change it to permissive mode in SELinux.
Instead, how about trying to add user authentication while attempting to access the fingerprint data?
It would be possible to apply it since the fingerprint data is separately located in different path (e.g., /var/lib/username/device-id/XXX).

Comment 6 Seong-Joong Kim 2019-04-12 09:55:27 UTC
Under such a scenario, I think it is not justifiable to shift protection responsibility to OS entirely.

Instead, we need to devise a data encryption/protection scheme at least.

This issue can be even more important than password exposure in cleartext.

Because once fingerprint has been leaked, victims are leaked for the rest of life since it lasts for a life.

What do you think of it?


Note You need to log in before you can comment on or make changes to this bug.