<p>Hmmm ... its not clear what  exploit is used (from just reading the file at the URL you gave).</p>
<p>The RPM versions (4.1/4.2) mentioned in the URL are quite ancient (circa RHL 8/9).</p>
<p>Even on those ancient systems, /var/lib/rpm requires access to root:root (or rpm:rpm) in order to modify an rpmdb (but the derivative task of the exploit is hiding a rootkit, where root:root has already been achieved, by changing information in the rpmdb).</p>
<p>The provision in RPM for careful rootkit forensics is to use "rpm -Vp ..." from a CDROM (or other offline/immutable media).</p>
<p>Hardening the manifest of installed packages (i.e. what is in an rpmdb) on an already exploited system would require a security protocol to authenticate/authorize rpm installations, most likely using a TPM and a trusted boot to ensure that the RPM executable was not compromised, and then to keep track of the list of package headers which SHOULD be installed, as well as verifying header signatures before verifying package contents.</p>
<p>This isn't an easy problem to solve.</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-292833133">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ANb802x0chSQeTWqTGSsPEEj991A0mPqks5ruY9pgaJpZM4M4Iiv">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ANb80wVwk9V3-S7t5GSqNHPJmyyuA8Mdks5ruY9pgaJpZM4M4Iiv.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-292833133"></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: Hmmm ... its not clear what  exploit is used (from just reading the file at the URL you gave).\r\n\r\nThe RPM versions (4.1/4.2) mentioned in the URL are quite ancient (circa RHL 8/9).\r\n\r\nEven on those ancient systems, /var/lib/rpm requires access to root:root (or rpm:rpm) in order to modify an rpmdb (but the derivative task of the exploit is hiding a rootkit, where root:root has already been achieved, by changing information in the rpmdb).\r\n\r\nThe provision in RPM for careful rootkit forensics is to use \"rpm -Vp ...\" from a CDROM (or other offline/immutable media).\r\n\r\nHardening the manifest of installed packages (i.e. what is in an rpmdb) on an already exploited system would require a security protocol to authenticate/authorize rpm installations, most likely using a TPM and a trusted boot to ensure that the RPM executable was not compromised, and then to keep track of the list of package headers which SHOULD be installed, as well as verifying header signatures before verifying package contents.\r\n\r\nThis isn't an easy problem to solve.\r\n\r\n"}],"action":{"name":"View Issue","url":"https://github.com/rpm-software-management/rpm/issues/196#issuecomment-292833133"}}}</script>