Re: IMA gadgets

[Grant Taylor <gtaylor () tnetconsulting net>]

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature