[Rpm-maint] [rpm-software-management/rpm] Make 'rpm -V' more resistent against rpmdb manipulations (#196)
notifications at github.com
Wed Apr 12 05:38:47 UTC 2017
FWIW, rpm.org has the first (but insufficient) step to hardening forensics on a compromised system.
E.g Here is rpm-4.13.90 output of "rpm -Vvv popt"
D: read h# 27079 Header V3 RSA/SHA256 Signature, key ID 81b46521: OK
D: Plugin: calling hook init in syslog plugin
D: Plugin: calling hook init in systemd_inhibit plugin
D: ========== +++ popt-1.16-7.fc24 x86_64/linux 0x2
D: read h# 34281 Header V3 RSA/SHA256 Signature, key ID fdb19c98: OK
Hood: DIZZYTACJOMETER is likely replacing/deleting package headers in an rpmdb, not modifying headers.
Importing only "trusted" pubkeys (i.e. rpm's current conception of "trust") with well known pubkey id's and verifying the rpm executable isn't compromised (by using an offline copy of /usr/bin/rpm, or by checking the digest of /usr/bin/rpm with offline forensic tools), is a start at manual forensic procedures.
Verifying pubkey certification signatures could also be attempted (but its non-trivial to alter pukey parameters without also altering the keyid fingerprint). It may (very unlikely, but I've not checked rpm.org recently) be possible to replace the signature on an package header with a different pubkey, or replace the pubkey parameters in the keystore used by RPM.
(Disclaimer: I'm not suggesting that RPM is vulnerable/deficient here, merely stating possible attacks that would make RPM's signature verification described above untrustworthy.)
Some of the manual procedures (like forcing the rpm package to be verified before proceeding with --verify) could be automated without too much difficulty.
A simpler/stricter mode of operation for rpm --verify with exit on failure in a multistep procedure would also help forensic analysis. The current "best effort" (i.e. continue in spite of failures) mode of operation in RPM is too goose-loosey for useful forensics of a compromised system.
Protecting an rpmdb against package header replacement/deletion attacks (what DIZZYTACHOMETER is likely doing to hide rootkits) is unsolved (and not easily solvable).
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rpm-maint