Bug 1197532 - VUL-0: tpm2.0-abrmd: users with D-Bus system bus access can run arbitrary TPM operations
VUL-0: tpm2.0-abrmd: users with D-Bus system bus access can run arbitrary TPM...
Status: RESOLVED FIXED
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Matthias Gerstner
Security Team bot
https://smash.suse.de/issue/327295/
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2022-03-25 16:31 UTC by Antonio Feijoo
Modified: 2022-05-17 13:29 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Antonio Feijoo 2022-03-25 16:31:04 UTC
The tpm2_clear command clears lockout, endorsement and owner hierarchy authorization values. If the system is configured to decrypt the root partition using the TPM2 chip (e.g.: https://en.opensuse.org/SDB:LUKS2,_TPM2_and_FIDO2#Decryption_using_TPM2), any non-privileged user can break the startup process after running this command.

Tested in SLE15-SP4 and TW.
Comment 1 Marcus Meissner 2022-03-26 09:15:11 UTC
matthias, can you check if this valid / wanted or bad?
Comment 3 Matthias Gerstner 2022-03-28 10:21:29 UTC
Thanks for reporting this.

Can you please point out which TCTI you are using when this happens? Is
tpm2-abrmd running? Which groups is your user in?
Comment 4 Matthias Gerstner 2022-03-28 10:31:51 UTC
I can reproduce this on Tumbleweed. tpm2-abrmd is automatically started and
accepts the request.

It's unclear what the security model of tpm2-abrmd is here. It doesn't use
polkit for authentication. The D-Bus configuration also doesn't restrict
anything. I'll investigate further.
Comment 5 Antonio Feijoo 2022-03-28 10:41:10 UTC
(In reply to Matthias Gerstner from comment #3)
> Thanks for reporting this.
> 
> Can you please point out which TCTI you are using when this happens? Is
> tpm2-abrmd running? Which groups is your user in?

dev@localhost:/home/dev> whoami
dev
dev@localhost:/home/dev> groups
users
dev@localhost:/home/dev> tpm2_clear
dev@localhost:/home/dev> systemctl status tpm2-abrmd
● tpm2-abrmd.service - TPM2 Access Broker and Resource Management Daemon
     Loaded: loaded (/usr/lib/systemd/system/tpm2-abrmd.service; disabled; vendor preset: disabled)
     Active: active (running) since Mon 2022-03-28 12:35:31 CEST; 40s ago
   Main PID: 18501 (tpm2-abrmd)
      Tasks: 6 (limit: 4915)
     CGroup: /system.slice/tpm2-abrmd.service
             └─18501 /usr/sbin/tpm2-abrmd

FYI reproduced also with a laptop running Leap 15.4 using a real TPM2 chip.
Comment 6 Matthias Gerstner 2022-03-28 10:55:28 UTC
I don't see any differences in Debian or Arch Linux abrmd configuration. Can
you retest e.g. on Debian when installing abrmd i.e.:

    root# apt-get install tpm2-abrmd

Does it behave the same as on openSUSE then?
Comment 7 Antonio Feijoo 2022-03-28 11:05:38 UTC
(In reply to Matthias Gerstner from comment #6)
> I don't see any differences in Debian or Arch Linux abrmd configuration. Can
> you retest e.g. on Debian when installing abrmd i.e.:
> 
>     root# apt-get install tpm2-abrmd
> 
> Does it behave the same as on openSUSE then?

I already had it installed.

> dev@debian:~$ systemctl status tpm2-abrmd
> ● tpm2-abrmd.service - TPM2 Access Broker and Resource Management Daemon
>      Loaded: loaded (/lib/systemd/system/tpm2-abrmd.service; enabled; vendor pr>
>      Active: active (running) since Mon 2022-03-28 13:00:58 CEST; 12s ago
>    Main PID: 436 (tpm2-abrmd)
>       Tasks: 7 (limit: 2319)
>      Memory: 3.8M
>         CPU: 8ms
>      CGroup: /system.slice/tpm2-abrmd.service
>              └─436 /usr/sbin/tpm2-abrmd
> 
> Warning: some journal files were not opened due to insufficient permissions.
> dev@debian:~$ tpm2_clear
> ERROR:tcti:src/tss2-tcti/tcti-device.c:440:Tss2_Tcti_Device_Init() Failed to open specified TCTI device file /dev/tpmrm0: Permission denied 
> WARNING:tcti:src/tss2-tcti/tctildr.c:79:tcti_from_init() TCTI init for function 0x7ff8412f4140 failed with a000a 
> WARNING:tcti:src/tss2-tcti/tctildr.c:109:tcti_from_info() Could not initialize TCTI named: tcti-device 
> ERROR:tcti:src/tss2-tcti/tctildr-dl.c:154:tcti_from_file() Could not initialize TCTI file: libtss2-tcti-device.so.0 
> ERROR:tcti:src/tss2-tcti/tcti-device.c:440:Tss2_Tcti_Device_Init() Failed to open specified TCTI device file /dev/tpm0: Permission denied 
> WARNING:tcti:src/tss2-tcti/tctildr.c:79:tcti_from_init() TCTI init for function 0x7ff8412f4140 failed with a000a 
> WARNING:tcti:src/tss2-tcti/tctildr.c:109:tcti_from_info() Could not initialize TCTI named: tcti-device 
> ERROR:tcti:src/tss2-tcti/tctildr-dl.c:154:tcti_from_file() Could not initialize TCTI file: libtss2-tcti-device.so.0 
> WARNING:tcti:src/util/io.c:252:socket_connect() Failed to connect to host 127.0.0.1, port 2321: errno 111: Connection refused 
> ERROR:tcti:src/tss2-tcti/tcti-swtpm.c:592:Tss2_Tcti_Swtpm_Init() Cannot connect to swtpm TPM socket 
> WARNING:tcti:src/tss2-tcti/tctildr.c:79:tcti_from_init() TCTI init for function 0x7ff8412f4490 failed with a000a 
> WARNING:tcti:src/tss2-tcti/tctildr.c:109:tcti_from_info() Could not initialize TCTI named: tcti-swtpm 
> ERROR:tcti:src/tss2-tcti/tctildr-dl.c:154:tcti_from_file() Could not initialize TCTI file: libtss2-tcti-swtpm.so.0 
> WARNING:tcti:src/util/io.c:252:socket_connect() Failed to connect to host 127.0.0.1, port 2321: errno 111: Connection refused 
> WARNING:tcti:src/tss2-tcti/tctildr.c:79:tcti_from_init() TCTI init for function 0x7ff8412f4310 failed with a000a 
> WARNING:tcti:src/tss2-tcti/tctildr.c:109:tcti_from_info() Could not initialize TCTI named: tcti-socket 
> ERROR:tcti:src/tss2-tcti/tctildr-dl.c:154:tcti_from_file() Could not initialize TCTI file: libtss2-tcti-mssim.so.0 
> ERROR:tcti:src/tss2-tcti/tctildr-dl.c:254:tctildr_get_default() No standard TCTI could be loaded 
> ERROR:tcti:src/tss2-tcti/tctildr.c:416:Tss2_TctiLdr_Initialize_Ex() Failed to instantiate TCTI 
> ERROR: Could not load tcti, got: "(null)"
Comment 8 Matthias Gerstner 2022-03-28 12:15:28 UTC
(In reply to antonio.feijoo@suse.com from comment #7)
> (In reply to Matthias Gerstner from comment #6)
> > I don't see any differences in Debian or Arch Linux abrmd configuration. Can
> > you retest e.g. on Debian when installing abrmd i.e.:
> > 
> >     root# apt-get install tpm2-abrmd
> > 
> > Does it behave the same as on openSUSE then?
> 
> I already had it installed.

Is also the TCTI installed? Please try

    root# apt-get install libtss2-tcti-tabrmd0
Comment 9 Antonio Feijoo 2022-03-28 14:40:46 UTC
(In reply to Matthias Gerstner from comment #8)
> (In reply to antonio.feijoo@suse.com from comment #7)
> > (In reply to Matthias Gerstner from comment #6)
> > > I don't see any differences in Debian or Arch Linux abrmd configuration. Can
> > > you retest e.g. on Debian when installing abrmd i.e.:
> > > 
> > >     root# apt-get install tpm2-abrmd
> > > 
> > > Does it behave the same as on openSUSE then?
> > 
> > I already had it installed.
> 
> Is also the TCTI installed? Please try
> 
>     root# apt-get install libtss2-tcti-tabrmd0

No, it wasn't installed. After installing this package, this report can be reproduced in Debian.
In Fedora, it's enough to install the tpm2-abrmd package (which I hadn't installed before).
Comment 10 Matthias Gerstner 2022-03-29 08:12:06 UTC
(In reply to antonio.feijoo@suse.com from comment #9)
> No, it wasn't installed. After installing this package, this report can be reproduced in Debian.
> In Fedora, it's enough to install the tpm2-abrmd package (which I hadn't installed before).

Thanks for reproducing. So now we know it isn't SUSE specific. Still it is an
interesting question what the security model for tpm2-abrmd is, because your
concern is valid. Maybe the idea is to set a TPM owner password? I will ask
upstream.
Comment 11 Matthias Gerstner 2022-03-29 09:50:41 UTC
I contacted the upstream maintainer of tpm2-abrmd privately about this. I will
report back when I have an official statement.

From a packaging point of view it would be possible to restrict D-Bus access
to abrmd only to members of the tss group, thereby mirroring the permission
model of /dev/tpm0.

Upstream could also implement a Polkit policy to allow more fine grained
control of what can and cannot be done. But that would be a bigger change.
Comment 12 Matthias Gerstner 2022-04-01 10:12:37 UTC
So my upstream contact explained to me that this is a delibarate decision for
tpm2-abrmd that any user can access the TPM. The tpm2-tss stack relies on the
TPM authorization mechanisms themselves, not on OS level restrictions.

The reason that /dev/tpm0 is protected accordingly is only for DoS protection
reasons, because any user could otherwise block the character device,
preventing others from accessing the TPM. Managing parallel TPM access without
interference is one of the main abrmd features, though.

I could still imagine to restrict D-Bus access to the abrmd to members of the
tpm group. At least in a hardened profile or easily configurable. I'm not
completely sure what users would expect, though.
Comment 13 Matthias Gerstner 2022-04-04 10:59:01 UTC
I will soon submit a change for the openSUSE:Factory packaging that restricts
access to tpm2-abrmd to members of the 'tss' group. This mimics the access
restriction of the /dev/tpm* devices. Let's see how many users are complaining
about this change.

Maybe we will also seek a large discussion with other distributors and
integrators to see what their opinion on this D-Bus access question is.
Comment 14 OBSbugzilla Bot 2022-04-04 11:40:03 UTC
This is an autogenerated message for OBS integration:
This bug (1197532) was mentioned in
https://build.opensuse.org/request/show/966798 Factory / tpm2.0-abrmd
Comment 18 Matthias Gerstner 2022-04-14 10:43:15 UTC
(In reply to matthias.gerstner@suse.com from comment #13)
> Maybe we will also seek a large discussion with other distributors and
> integrators to see what their opinion on this D-Bus access question is.

Upstream agreed to start such a discussion, although it emphazises that this
is not a security issue.

I will try to start the discussion in a couple of days after easter season is
over.
Comment 19 Matthias Gerstner 2022-04-20 08:31:05 UTC
I will soon make the posting to oss-security. Let's see what other integrators
think about this.

Upstream hinted me that the group that gets D-Bus access to the tpm2.0-abrmd
service should *not* be the same group that has access to /dev/tpm0, because
then members of this group could DoS the tpm0 character device, against which
the abrmd is protecting.

This means I would need to introduce a separate group like 'tabrmd' or such to
properly separate security domains.
Comment 20 Alberto Planas Dominguez 2022-04-20 08:40:08 UTC
(In reply to Matthias Gerstner from comment #19)

> This means I would need to introduce a separate group like 'tabrmd' or such
> to
> properly separate security domains.

Now a package that uses tpm2.0-tools should be part of the tss group, or part of this new group?

For example, keylime-agent creates the keylime user, that is part of tss group, so can use the tpm2_* CLI tools. Should that be moved?
Comment 21 Matthias Gerstner 2022-04-20 08:51:14 UTC
(In reply to aplanas@suse.com from comment #20)
> Now a package that uses tpm2.0-tools should be part of the tss group, or part of this new group?
> 
> For example, keylime-agent creates the keylime user, that is part of tss group, so can use the tpm2_* CLI tools. Should that be moved?

If the tpm2-abrmd is used then, as I understand it, only the abrmd should have
access to /dev/tpm0 and thus be a member of 'tss'. In that case keylime should
*not* be in 'tss'.

It gets more complicated when the tcti-device backend is used without
tpm2-abrmd, I guess. Then the caller *must* have access to /dev/tpm0,
involving the possible DoS issues. I don't know how common such a setup is, it
sounds like the tpm2-abrmd is the canonical way to access the TPM.
Comment 22 Alberto Planas Dominguez 2022-04-20 09:03:26 UTC
(In reply to Matthias Gerstner from comment #21)

> If the tpm2-abrmd is used 

Right, but we never know, do we? The application that uses tpm2_* CLI tools do not really know if is using abrmd or not, as depend on the running system (env vars, configuration, etc)

 
> It gets more complicated when the tcti-device backend is used without
> tpm2-abrmd, I guess. Then the caller *must* have access to /dev/tpm0,
> involving the possible DoS issues.

Exactly, and the issue is that the application never knows for sure how the TPM is being accessed.

> I don't know how common such a setup is, it
> sounds like the tpm2-abrmd is the canonical way to access the TPM.

I can be completely wrong here, but was my understanding when researching this that abrmd is being deprecated in favor of /dev/tpmrm0, the kernel's resource manager for the TPM2. If I read it correctly, they are today almost in the same level of features.
Comment 23 Matthias Gerstner 2022-04-20 09:33:00 UTC
The oss-security mail is out now:

https://www.openwall.com/lists/oss-security/2022/04/20/3
Comment 24 Matthias Gerstner 2022-04-20 09:37:38 UTC
(In reply to aplanas@suse.com from comment #22)
> Right, but we never know, do we? The application that uses tpm2_* CLI tools do not really know if is using abrmd or not, as depend on the running system (env vars, configuration, etc)

yeah this somewhat breaks the abstraction provided by TCTIs. I think mostly it
is an integration question, but a complex one.

> I can be completely wrong here, but was my understanding when researching
> this that abrmd is being deprecated in favor of /dev/tpmrm0, the kernel's
> resource manager for the TPM2. If I read it correctly, they are today almost
> in the same level of features.

Yes upstream intended to move to the kernel version of the RM as soon as it is
suitable. Even when this will happen it can still be the canonical way of
accessing the TPM. There will probably be another TCTI for it and the
permissions of /dev/tpmrm0 could mirror what we choose for the D-Bus
configuration of tpm2-abrmd.
Comment 25 Matthias Gerstner 2022-05-17 13:29:33 UTC
(In reply to matthias.gerstner@suse.com from comment #21)
> If the tpm2-abrmd is used then, as I understand it, only the abrmd should have
> access to /dev/tpm0 and thus be a member of 'tss'. In that case keylime should
> *not* be in 'tss'.
> 
> It gets more complicated when the tcti-device backend is used without
> tpm2-abrmd, I guess. Then the caller *must* have access to /dev/tpm0,
> involving the possible DoS issues. I don't know how common such a setup is, it
> sounds like the tpm2-abrmd is the canonical way to access the TPM.

The tss2 suite contradicts this point partly by itself. The fapi library
mechanism expects users to be in the tss group, see:

    https://github.com/tpm2-software/tpm2-tss/commit/15be0effa7b72f9a211d5f99f3e0a25d3a8ea043

I guess separating interactive group membership from non-interactive group
membership (like for tpm2-abrmd) would be something that would need to be done
upstream first.

I think the danger of users that have been actively placed into the tss group
DoSing the system is lower than the danger of arbitrary users DoSing the
system (in case the TPM level protection mechanisms are not in place).

I conclude this topic with this assessment for the time being. Tumbleweed gets
the new group requirement, backports will not happen at the time, because it
would be a breaking change.

There was no big outcry on the oss-security mailing list posting, so maybe we
are overrating this issue anyway.