|
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.