<p>FWIW, rpm.org has the first (but insufficient) step to hardening forensics on a compromised system.</p>
<p>E.g Here is rpm-4.13.90 output of "rpm -Vvv popt"<br>
<code>... 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 ...</code><br>
Hood: DIZZYTACJOMETER is likely replacing/deleting package headers in an rpmdb, not modifying headers.</p>
<p>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.</p>
<p>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.</p>
<p>(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.)</p>
<p>Some of the manual procedures (like forcing the rpm package to be verified before proceeding with --verify) could be automated without too much difficulty.</p>
<p>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.</p>
<p>Protecting an rpmdb against package header replacement/deletion attacks (what DIZZYTACHOMETER is likely doing to hide rootkits) is unsolved (and not easily solvable).</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/rpm-software-management/rpm/issues/196#issuecomment-293478974">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ANb808YgV-FVtEAGwtATnpKmmm9tggoCks5rvGNngaJpZM4M4Iiv">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ANb800Kx_f_bH2QWpiz_M9l7Vpc2GNnMks5rvGNngaJpZM4M4Iiv.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/rpm-software-management/rpm/issues/196#issuecomment-293478974"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/rpm-software-management/rpm","title":"rpm-software-management/rpm","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/rpm-software-management/rpm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@n3npq in #196: FWIW, rpm.org has the first (but insufficient) step to hardening forensics on a compromised system.\r\n\r\nE.g Here is rpm-4.13.90 output of \"rpm -Vvv popt\"\r\n`\r\n...\r\nD:  read h#   27079 Header V3 RSA/SHA256 Signature, key ID 81b46521: OK\r\nD: Plugin: calling hook init in syslog plugin\r\nD: Plugin: calling hook init in systemd_inhibit plugin\r\nD: ========== +++ popt-1.16-7.fc24 x86_64/linux 0x2\r\nD:  read h#   34281 Header V3 RSA/SHA256 Signature, key ID fdb19c98: OK\r\n...\r\n`\r\nHood: DIZZYTACJOMETER is likely replacing/deleting package headers in an rpmdb, not modifying headers.\r\n\r\nImporting 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.\r\n\r\nVerifying 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.\r\n\r\n(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.)\r\n\r\nSome of the manual procedures (like forcing the rpm package to be verified before proceeding with --verify) could be automated without too much difficulty.\r\n\r\nA 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.\r\n\r\nProtecting an rpmdb against package header replacement/deletion attacks (what DIZZYTACHOMETER is likely doing to hide rootkits) is unsolved (and not easily solvable)."}],"action":{"name":"View Issue","url":"https://github.com/rpm-software-management/rpm/issues/196#issuecomment-293478974"}}}</script>