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
Hi Yaron,
Thanks for taking time to look into this issue.
We appreciate the analysis you did, although, as we already shared
privately, we don't think that this is a fprintd issue but rather an
architectural issue of how PAM modules interact with sudo that, by
design, does not permit an additional attention mechanism beyond
displaying a prompt in the terminal.
It's important to note that no graphical PAM front-end (that we are
aware of) is affected by this problem. For example, the PolicyKit
dialog that gnome-shell integrates and also the GDM login and lock
screens will properly ensure user attention. Said differently, there
should be no user attention issue as long as fingerprint authentication
is restricted to properly implemented graphical front-ends. This is a
policy decision for administrators and distributors to ensure using the
PAM configuration.
We would like to point out that similar behaviors may occur with any
PAM module that uses an out-of-band authentication mechanism (whether
using another device or not) that doesn't require the user to pay
attention to the main device (SSO, web authentication, hardware-token
based, …).
The discussed behavior completely depends on the PAM configuration
(which, in most cases, needs to be enabled by the user). If this is
considered an issue, then it cannot be resolved within fprintd (and
pam_fprintd.so in particular). Should this be considered an issue, then
it needs to be addressed by modifying the PAM configuration to restrict
pam_fprintd.so to front-ends that implement a proper attention
mechanism. This is out of scope for fprintd and must be done by
administrators and possibly distributions as part of a policy decision.
A policy decision that the reporter made when enabling fingerprint
authentication using pam-auth-update.
As explained, this is not an fprintd issue, and it cannot be considered
a security flaw in fprintd, and therefore we believe that it should not
have been assigned a CVE number.
Thank you again for caring about fingerprint security.
The fprintd maintainers,
Benjamin and Marco
Il giorno gio, 30/05/2024 alle 09.18 +0000, Yaron Shahrabani ha
scritto:
> 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
At Marco's request, I am asking MITRE to either revoke CVE-2024-37408 or for
MITRE to transfer CVE ownership to Canonical's CNA for revocation.
On Thu, Jun 13, 2024 at 06:40:51PM +0200, Marco Trevisan wrote:
> Hi Yaron,
>
> Thanks for taking time to look into this issue.
>
> We appreciate the analysis you did, although, as we already shared
> privately, we don't think that this is a fprintd issue but rather an
> architectural issue of how PAM modules interact with sudo that, by
> design, does not permit an additional attention mechanism beyond
> displaying a prompt in the terminal.
>
> It's important to note that no graphical PAM front-end (that we are
> aware of) is affected by this problem. For example, the PolicyKit
> dialog that gnome-shell integrates and also the GDM login and lock
> screens will properly ensure user attention. Said differently, there
> should be no user attention issue as long as fingerprint authentication
> is restricted to properly implemented graphical front-ends. This is a
> policy decision for administrators and distributors to ensure using the
> PAM configuration.
>
> We would like to point out that similar behaviors may occur with any
> PAM module that uses an out-of-band authentication mechanism (whether
> using another device or not) that doesn't require the user to pay
> attention to the main device (SSO, web authentication, hardware-token
> based, …).
>
> The discussed behavior completely depends on the PAM configuration
> (which, in most cases, needs to be enabled by the user). If this is
> considered an issue, then it cannot be resolved within fprintd (and
> pam_fprintd.so in particular). Should this be considered an issue, then
> it needs to be addressed by modifying the PAM configuration to restrict
> pam_fprintd.so to front-ends that implement a proper attention
> mechanism. This is out of scope for fprintd and must be done by
> administrators and possibly distributions as part of a policy decision.
> A policy decision that the reporter made when enabling fingerprint
> authentication using pam-auth-update.
>
> As explained, this is not an fprintd issue, and it cannot be considered
> a security flaw in fprintd, and therefore we believe that it should not
> have been assigned a CVE number.
>
> Thank you again for caring about fingerprint security.
>
> The fprintd maintainers,
> Benjamin and Marco
>
>
> Il giorno gio, 30/05/2024 alle 09.18 +0000, Yaron Shahrabani ha
> scritto:
> > 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
>
This seems to be a system administration and configuration problem rather
than a built in issue.
On Fri, Jun 14, 2024 at 09:52 Yaron Shahrabani <[email protected]> wrote:
> Thank you all for your response and care.
>
> I would like to point out that although I managed to demonstrate this
> vulnerability with a virtual terminal in a graphical interface it also
> applies to TTY, so even if I don't have any graphical interface I can still
> exploit this vulnerability.
>
> Adding a graphical awareness mechanism will solve the vulnerability for
> graphical interface but not entirely (unless there's a way to switch to the
> requesting TTY for approval).
>
>
> Thank you!
>
> On Thu, 13 Jun 2024, 23:36 Mark Esler, <[email protected]> wrote:
>
> > At Marco's request, I am asking MITRE to either revoke CVE-2024-37408 or
> > for
> > MITRE to transfer CVE ownership to Canonical's CNA for revocation.
> >
> > On Thu, Jun 13, 2024 at 06:40:51PM +0200, Marco Trevisan wrote:
> > > Hi Yaron,
> > >
> > > Thanks for taking time to look into this issue.
> > >
> > > We appreciate the analysis you did, although, as we already shared
> > > privately, we don't think that this is a fprintd issue but rather an
> > > architectural issue of how PAM modules interact with sudo that, by
> > > design, does not permit an additional attention mechanism beyond
> > > displaying a prompt in the terminal.
> > >
> > > It's important to note that no graphical PAM front-end (that we are
> > > aware of) is affected by this problem. For example, the PolicyKit
> > > dialog that gnome-shell integrates and also the GDM login and lock
> > > screens will properly ensure user attention. Said differently, there
> > > should be no user attention issue as long as fingerprint authentication
> > > is restricted to properly implemented graphical front-ends. This is a
> > > policy decision for administrators and distributors to ensure using the
> > > PAM configuration.
> > >
> > > We would like to point out that similar behaviors may occur with any
> > > PAM module that uses an out-of-band authentication mechanism (whether
> > > using another device or not) that doesn't require the user to pay
> > > attention to the main device (SSO, web authentication, hardware-token
> > > based, …).
> > >
> > > The discussed behavior completely depends on the PAM configuration
> > > (which, in most cases, needs to be enabled by the user). If this is
> > > considered an issue, then it cannot be resolved within fprintd (and
> > > pam_fprintd.so in particular). Should this be considered an issue, then
> > > it needs to be addressed by modifying the PAM configuration to restrict
> > > pam_fprintd.so to front-ends that implement a proper attention
> > > mechanism. This is out of scope for fprintd and must be done by
> > > administrators and possibly distributions as part of a policy decision.
> > > A policy decision that the reporter made when enabling fingerprint
> > > authentication using pam-auth-update.
> > >
> > > As explained, this is not an fprintd issue, and it cannot be considered
> > > a security flaw in fprintd, and therefore we believe that it should not
> > > have been assigned a CVE number.
> > >
> > > Thank you again for caring about fingerprint security.
> > >
> > > The fprintd maintainers,
> > > Benjamin and Marco
> > >
> > >
> > > Il giorno gio, 30/05/2024 alle 09.18 +0000, Yaron Shahrabani ha
> > > scritto:
> > > > 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
> > >
> >
> >
> >
>
Thank you all for your response and care.
I would like to point out that although I managed to demonstrate this
vulnerability with a virtual terminal in a graphical interface it also
applies to TTY, so even if I don't have any graphical interface I can still
exploit this vulnerability.
Adding a graphical awareness mechanism will solve the vulnerability for
graphical interface but not entirely (unless there's a way to switch to the
requesting TTY for approval).
Thank you!
On Thu, 13 Jun 2024, 23:36 Mark Esler, <[email protected]> wrote:
> At Marco's request, I am asking MITRE to either revoke CVE-2024-37408 or
> for
> MITRE to transfer CVE ownership to Canonical's CNA for revocation.
>
> On Thu, Jun 13, 2024 at 06:40:51PM +0200, Marco Trevisan wrote:
> > Hi Yaron,
> >
> > Thanks for taking time to look into this issue.
> >
> > We appreciate the analysis you did, although, as we already shared
> > privately, we don't think that this is a fprintd issue but rather an
> > architectural issue of how PAM modules interact with sudo that, by
> > design, does not permit an additional attention mechanism beyond
> > displaying a prompt in the terminal.
> >
> > It's important to note that no graphical PAM front-end (that we are
> > aware of) is affected by this problem. For example, the PolicyKit
> > dialog that gnome-shell integrates and also the GDM login and lock
> > screens will properly ensure user attention. Said differently, there
> > should be no user attention issue as long as fingerprint authentication
> > is restricted to properly implemented graphical front-ends. This is a
> > policy decision for administrators and distributors to ensure using the
> > PAM configuration.
> >
> > We would like to point out that similar behaviors may occur with any
> > PAM module that uses an out-of-band authentication mechanism (whether
> > using another device or not) that doesn't require the user to pay
> > attention to the main device (SSO, web authentication, hardware-token
> > based, …).
> >
> > The discussed behavior completely depends on the PAM configuration
> > (which, in most cases, needs to be enabled by the user). If this is
> > considered an issue, then it cannot be resolved within fprintd (and
> > pam_fprintd.so in particular). Should this be considered an issue, then
> > it needs to be addressed by modifying the PAM configuration to restrict
> > pam_fprintd.so to front-ends that implement a proper attention
> > mechanism. This is out of scope for fprintd and must be done by
> > administrators and possibly distributions as part of a policy decision.
> > A policy decision that the reporter made when enabling fingerprint
> > authentication using pam-auth-update.
> >
> > As explained, this is not an fprintd issue, and it cannot be considered
> > a security flaw in fprintd, and therefore we believe that it should not
> > have been assigned a CVE number.
> >
> > Thank you again for caring about fingerprint security.
> >
> > The fprintd maintainers,
> > Benjamin and Marco
> >
> >
> > Il giorno gio, 30/05/2024 alle 09.18 +0000, Yaron Shahrabani ha
> > scritto:
> > > 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
> >
>
>
>
MITRE responded:
> Thank you for contacting us. The oss-security thread says:
>
> The discussed behavior completely depends on the PAM configuration
> (which, in most cases, needs to be enabled by the user). If this is
> considered an issue, then it cannot be resolved within fprintd (and
> pam_fprintd.so in particular). Should this be considered an issue, then
> it needs to be addressed by modifying the PAM configuration to restrict
> pam_fprintd.so to front-ends that implement a proper attention
> mechanism. This is out of scope for fprintd and must be done by
> administrators and possibly distributions
>
> We understand that nothing within fprintd/pam_fprintd.so is going to
> be changed in order to attempt to "fix" the reported concern. However,
> CVE is not about fixes. CVE consumers may wish to discuss the reported
> outcome of "unexpected actions might be authorized" regardless of
> where any type of fix is ultimately implemented, or even if nobody
> ever implements a fix.
>
> We have no plans to either reject or transfer CVE-2024-37408.
I asked in reply:
> Please share your analysis of why you believe a vulnerability exists in
> fprintd and not in downstreams [0].
>
> Please transfer CVE-2024-37408 to the Canonical CNA under the "right of
> first refusal" as the appointed CNA of fprintd for this issue [1].
I'll share the outcome when this is sorted out.
[0] https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_4-1_Vulnerability_Determination
[1] https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_4-2_CVE_ID_Assignment
On Fri, Jun 14, 2024 at 10:11:04AM -0400, Benjamin Cance wrote:
> This seems to be a system administration and configuration problem rather
> than a built in issue.
>
> On Fri, Jun 14, 2024 at 09:52 Yaron Shahrabani <[email protected]> wrote:
>
> > Thank you all for your response and care.
> >
> > I would like to point out that although I managed to demonstrate this
> > vulnerability with a virtual terminal in a graphical interface it also
> > applies to TTY, so even if I don't have any graphical interface I can still
> > exploit this vulnerability.
> >
> > Adding a graphical awareness mechanism will solve the vulnerability for
> > graphical interface but not entirely (unless there's a way to switch to the
> > requesting TTY for approval).
> >
> >
> > Thank you!
> >
> > On Thu, 13 Jun 2024, 23:36 Mark Esler, <[email protected]> wrote:
> >
> > > At Marco's request, I am asking MITRE to either revoke CVE-2024-37408 or
> > > for
> > > MITRE to transfer CVE ownership to Canonical's CNA for revocation.
> > >
> > > On Thu, Jun 13, 2024 at 06:40:51PM +0200, Marco Trevisan wrote:
> > > > Hi Yaron,
> > > >
> > > > Thanks for taking time to look into this issue.
> > > >
> > > > We appreciate the analysis you did, although, as we already shared
> > > > privately, we don't think that this is a fprintd issue but rather an
> > > > architectural issue of how PAM modules interact with sudo that, by
> > > > design, does not permit an additional attention mechanism beyond
> > > > displaying a prompt in the terminal.
> > > >
> > > > It's important to note that no graphical PAM front-end (that we are
> > > > aware of) is affected by this problem. For example, the PolicyKit
> > > > dialog that gnome-shell integrates and also the GDM login and lock
> > > > screens will properly ensure user attention. Said differently, there
> > > > should be no user attention issue as long as fingerprint authentication
> > > > is restricted to properly implemented graphical front-ends. This is a
> > > > policy decision for administrators and distributors to ensure using the
> > > > PAM configuration.
> > > >
> > > > We would like to point out that similar behaviors may occur with any
> > > > PAM module that uses an out-of-band authentication mechanism (whether
> > > > using another device or not) that doesn't require the user to pay
> > > > attention to the main device (SSO, web authentication, hardware-token
> > > > based, …).
> > > >
> > > > The discussed behavior completely depends on the PAM configuration
> > > > (which, in most cases, needs to be enabled by the user). If this is
> > > > considered an issue, then it cannot be resolved within fprintd (and
> > > > pam_fprintd.so in particular). Should this be considered an issue, then
> > > > it needs to be addressed by modifying the PAM configuration to restrict
> > > > pam_fprintd.so to front-ends that implement a proper attention
> > > > mechanism. This is out of scope for fprintd and must be done by
> > > > administrators and possibly distributions as part of a policy decision.
> > > > A policy decision that the reporter made when enabling fingerprint
> > > > authentication using pam-auth-update.
> > > >
> > > > As explained, this is not an fprintd issue, and it cannot be considered
> > > > a security flaw in fprintd, and therefore we believe that it should not
> > > > have been assigned a CVE number.
> > > >
> > > > Thank you again for caring about fingerprint security.
> > > >
> > > > The fprintd maintainers,
> > > > Benjamin and Marco
> > > >
> > > >
> > > > Il giorno gio, 30/05/2024 alle 09.18 +0000, Yaron Shahrabani ha
> > > > scritto:
> > > > > 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
> > > >
> > >
> > >
> > >
> >