Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Wed, 20 Apr 2022 11:07:00 +0200
From: Matthias Gerstner <>
Subject: tpm2-abrmd: possibly surprising security model for local users could
 result in a local DoS against TPM configuration and data

Hello list,

this is both a heads up and an invitation for discussion of a situation
that some end users and TPM integrators might find surprising.

The Intel TPM 2.0 software stack offers software components for
accessing TPM 2.0 hardware features. The stack's main components are the
core libraries tpm2-tss [1], a set of command line tools tpm2-tools [2]
and the userspace resource manager and access broker tpm2-abrmd [3] used
for multiplexing parallel access to a TPM device.

I was made aware that, after installing all three of the mentioned
tpm2 packages on openSUSE, arbitrary local users may issue arbitrary
commands to the TPM chip [4], including a `tpm2_clear` operation. The
reporter of this was afraid that this could be used as a local
denial-of-service vector especially in the light of recent feature
developments like TPM assisted unattended unlocking of encrypted file
systems during boot.

The Intel TPM 2.0 software stack supports different communication
backends (TCTIs, TPM Command Transmission Interfaces) for accessing a
TPM device. For example the tcti-device backend accesses the /dev/tpm0
character device directly while tcti-tabrmd attempts to invoke the D-Bus
interface of the tpm2-abrmd daemon. The packaging of tpm2-abrmd in
openSUSE uses configuration files to allow transparent autostart of the
daemon via D-Bus [5] and to allow everybody to invoke the service's
D-Bus methods via the D-Bus service configuration [6].

What happens is that upon invocation of a tpm2-tools command, even by a
regular system user (even a user like 'nobody'), different TCTI
backends will be probed by the tool. The probing of the tcti-tabrmd will
cause the tpm2-abrmd service to be started, even if not enabled on
systemd level. Since there are no restrictions on D-Bus level and no
further authentication layers exist on top of it, the operation will

The /dev/tpm0 character device is typically owned by root:root (mode
0700) or root:tss (mode 0770) and does not allow world access. Thus
without tpm2-abrmd installed, arbitrary local users are *not* able to
issue TPM commands. I contacted upstream about their security model in
this regard and the statement is that they purely rely on the
cryptographic security provided by the TPM itself. This means to avoid
arbitrary local users being able to e.g. reset TPM state, the respective
TPM properties would need to be protected by TPM level authorization.
The /dev/tpm0 device should still not be world accessible, because
otherwise the TPM device itself could suffer from a local DoS. The
tpm2-abrmd implements measures against the latter.

Upstream told me that they considered to implement e.g. polkit
authorization for individual actions in tpm2-abrmd but in the end
decided against it as they did not see a clear benefit for integrators.

I generally agree with upstream in that properly setup TPM level
authorization will prevent any local DoS issues. On the other hand I
found that many people seem to find this situation surprising. Tests
on other Linux distributions like Debian or Fedora show that they
exhibit the same behaviour when all three mentioned tpm2 packages are
installed. Thus integrators might want to reduce the level of surprise
for some of their users. This can be done relatively simple by
restricting the D-Bus level access to members of a separate group, for
example. Upstream recommends *not* to use the same 'tss' group for this
as is used for group ownership of /dev/tpm0, because this would
introduce DoS issues against the kernel level device again.

Upstream stresses the point that this is not a known vulnerability. I
still would be interested to hear further opinions on this.

Best Regards



Matthias Gerstner <>
Security Engineer
GPG Key ID: 0x14C405C971923553
SUSE Software Solutions Germany GmbH
HRB 36809, AG Nürnberg
Geschäftsführer: Ivo Totev

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.