Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <87wnkp8kmj.fsf@oldenburg.str.redhat.com>
Date: Tue, 30 Nov 2021 21:16:20 +0100
From: Florian Weimer <fweimer@...hat.com>
To: oss-security@...ts.openwall.com
Subject: IMA gadgets

There's an idea floating around that you can take an established Linux
distribution, create IMA signatures for all installed files in its
packages, and use those signatures to lock out bad content at run time
using IMA verification in the kernel.

I do not think this works in the sense that it can detect serve for more
than just detecting file corruption (as an unsigned hash would).  First
of all, there is the issue that IMA signatures (at least as they exist
in RPM today) are content-only and do not cover file permissions or file
capabilities.  This means an attacker can turn any binary into a SUID
binary.  The signatures do not cover these file attributes, so they will
still verify.

The signatures do not cover the file names, either.  Therefore, an
attacker can take a file and put it into a difference place in a file
system.  For example, there's a debug-shell.service file that, when
dropped into the right directory, will open a root shell on /dev/tty9.
This may seem a bit silly, but I think the intent behind the IMA
signatures is to combine them with remote attestation, and make
(remote) interaction with devices in places without physical security
trustworthy.

Another example is /usr/share/perl5/vendor_perl/App/cpanminus.pod from a
typical distribution of the App::cpanminus package.  If this is dropped
into /etc/sysconfig/run-parts, after a while, the system will download
untrusted code over the network and execute it, as far as I can see.
(CPAN does not seem to be authenticated.)  The file does nothing when
parsed by perl on the command line, but bash will try to run it and
invoke a cpan shell command that triggers the download and code
execution.  I don't think this kind of file type confusion is addressed
by the proposed trusted_for system call, either.

I'm sure there are many gadgets like this.  These two are just the first
examples I found.

So in short, I don't really see how IMA signatures shipped as part of
all distribution packages, on all files, can provide value beyond that
of the hash that the already contain.

Thanks,
Florian

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.