Received-SPF: pass (google.com: domain of oss-security-return-30176-linux.lists.archive=gmail.com@lists.openwall.com designates 193.110.157.125 as permitted sender) client-ip=193.110.157.125;
Mailing-List: contact oss-security-help@lists.openwall.com; run by ezmlm
Precedence: bulk
Reply-To: oss-security@lists.openwall.com
MIME-Version: 1.0
References: <CACVjhxWPjerPGKeJ=4ynPuJVH2E4nYGEt+cBaHhjqhS5=Fq+2w@mail.gmail.com>
 <CACVjhxVQm2LLSopp6CzXAjGaHFqtKWO=64oGvNcU43MuSwrB1w@mail.gmail.com>
In-Reply-To: <CACVjhxVQm2LLSopp6CzXAjGaHFqtKWO=64oGvNcU43MuSwrB1w@mail.gmail.com>
From: Yaron Shahrabani <sh.yaron@gmail.com>
Date: Thu, 30 May 2024 12:18:00 +0300
Message-ID: <CACVjhxUD21YUHf4ZMCqO_qzXT93p5ukSW6sKANvzDzxuXqaZCg@mail.gmail.com>
To: oss-security@lists.openwall.com
Content-Type: text/plain; charset="UTF-8"
Subject: [oss-security] Security vulnerability in fprintd

Hi everyone, I'm writing to this mailing list since I've already
shared the details with Benjamin Berg and Marco Trevisan privately,
and we have yet to conclude about this vulnerability.
This information was also disclosed to the fprintd mailing list:
https://lists.freedesktop.org/archives/fprint/2024-May/001231.html

My sudo is configured to approve access with pam_fprintd; this is the
config file:

#%PAM-1.0

auth            sufficient      pam_fprintd.so
auth            include         system-auth
account         include         system-auth
session         include         system-auth

So, unless I'm not already authenticated, running the following command:
sudo whoami
Replies with the following prompt:
Place your finger on the fingerprint reader

Placing my finger on the fingerprint reader leads to the following output:
root

The security concern is that this process can also happen behind the
scenes, so if I'm running a script that has a sudo prompt to delete
something I care about, I can accidentally place my fingerprint on the
fingerprint reader for any other reasons, and my beloved files will be
removed.

How do we recreate the issue?
You can open your favorite console app on Linux.
If it supports tabs open two tabs, if not just open another window.
On the first tab, type: sudo whoami
Switch to the second tab and type: echo Place your finger on the
fingerprint reader;cat
Place your fingerprint on the fingerprint reader
Return to the first tab (You should see that the command was approved
and the output is root)

Assume the user was running some background process and didn't see the
fingerprint prompt from the other terminal. The second terminal may
deceive the user into placing the finger on the fingerprint reader and
elevating permissions without the user being fully aware.

On Ubuntu, if I want to recreate the same configuration, all I have to
do is enroll my fingerprints in System Settings,
then install the pam-auth-update and select the Fingerprint
authentication from the selection screen (apt specific) as described
in the following SO thread:
https://askubuntu.com/questions/1015416/use-fingerprint-authentication-not-only-for-login.

This problem was solved in macOS by simply displaying a window; if the
window is out of focus, the fingerprint won't work.
Since we can't rely on any graphical window on Linux since it can be
terminal only, we need to ensure that the user fingerprint is used
only for the sole purpose of the request and with full attention to
the specific action the fingerprint was requested for. Otherwise, the
fingerprint can be hijacked (just like clickjacking).

Benjamin was kind enough to respond, and I allowed myself to summarize
his reply:
It can happen with fprintd as with any other external authentication
method (aside from password, we have Bluetooth proximity, NFC Tag,
Smart Card, etc.), so it is not unique to fprintd.
Benjamin also offered mitigating ways, such as changing the
configuration or using pkexec instead of sudo.

I addressed this issue with the sudo maintainer, Todd C. Miller, and
again, I allowed myself to summarize his response:
Although I understand the concern, I need a security attention
mechanism to fix it.

CVSS 4.0 ranked this CVE as 7.3.

Thank you,
PS, I'm not a security researcher, and I'm not affiliated with any organization.

Yaron Shahrabani - DevOps, Hebrew translator