[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d2b2c4b7-cba4-349e-1856-23f84fc6a198@spamtrap.tnetconsulting.net>
Date: Tue, 30 Nov 2021 14:27:31 -0700
From: Grant Taylor <gtaylor@...tconsulting.net>
To: oss-security@...ts.openwall.com
Subject: Re: IMA gadgets
Pre-script: I'm new to Linux's Integrity Measurement Architecture so my
comments below may be completely off base. Please gently correct me if
that's the case.
On 11/30/21 1:16 PM, Florian Weimer wrote:
> 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).
My understanding is that the signature which uses public & private keys
would be more resilient than just a hash in that the signature created
with the private key (which need not be on system) can be verified with
the public key on system. A simple hash doesn't provide that same level
of integrity.
> First of all, there is the issue that IMA signatures (at least as they
> exist in RPM today) are content-only ...
My initial skim of the Integrity Measurement Architecture page on
Gentoo's Wiki indicates that the pathname is included in the template has.
The columns (from left to right) are:
*PCR* (Platform Configuration Register) in which the values are
registered. This only makes sense if a TPM chip is in use.
*Template hash* of the entry, which is a hash that combines the
length and values of the file content hash /and/ /the/ /pathname/
*Template* that registered the integrity value (ima-ng the case)
*File content* hash which is the hash of the file itself
Link - Integrity Measurement Architecture - Gentoo Wiki
- https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture
So ... I may be mistaken, but I believe more than just the content is
covered by IMA signatures.
> ... and do not cover file permissions or file capabilities.
I see nothing to refute that portion of your statement.
> 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.
It may be possible to add SUID and / or capabilities to a signed file.
But I have to question how such a questionable non-SUID binary would be
given a signature in the first place? Or asked another why, why would a
questionable file be given a IMA signature in the first place?
> 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.
I question the veracity of that statement. It seems to disagree with
the template hash containing the path. Maybe it's a case of the file
hash being the same, but no longer matching with a template hash.
> 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.
Maybe I'm wrong, but I view IMA signatures as something akin to a real
time Tripwire as in has this file been modified since it was blessed ~>
approved to run?
> 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 not current on cpanminus so there could be plenty that I'm
overlooking. I would expect that download code to the site's Perl
installation. But I would expect that said code would not get executed.
Perhaps there is some form of chained process that I'm not cognizant of.
I still think that moving / copying / linking cpanminus.pod from it's
original location to the new location would run afoul of the template hash.
> I'm sure there are many gadgets like this. These two are just the
> first examples I found.
I think that it's worth looking at any and all gadgets to understand how
they would interact with IMA signatures. At best it is an academic
exercise of how IMA signatures would help. At worst it identifies a
vulnerability that needs to be remediated.
> 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.
I think the PKI signature would help more than /just/ a /simple/ hash.
Maybe the crux of the difference between my understanding of what you're
concern is and my understanding from skimming the linked page is that
you seem to be talking as if there is only a hash of the file contents
verses that has plush another hash that covers more system installation
specific data.
Post-Script: Please correct me if I'm wrong in any of my understanding.
--
Grant. . . .
unix || die
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4017 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.
