Before anything .. I only speak for RPM's
> Second, we produced trojaned .deb and .rpm files. The
> .deb file was trivial to modify, as only a checksum
> stood between a valid hacked version and us. The .rpm
> was a bit more difficult, because RedHat signs their
> packages with a PGP key. However, once we rebuilt the
> package and did not sign it with PGP, we had a fixed
> package.
This seems a little naive. If a sysadmin is that concerned he would have
imported RedHat's public GPG key. Once an RPM is downloaded doing
rpm --checksig -v packagename
checks the signature. If a person X signed it (or left it unsigned)
rather than RedHat it would be very obvious! (Assuming that RedHats'
private key is kept secret by RedHat and was;nt stolen by somebody).
Furthermore -U and -i options automatically check the signature
All this is in the manpage :-/
As an example consider the zebra package on the Shrike CD's
Before importing RH's public GPG key:
[EMAIL PROTECTED] redhat9]# rpm --checksig -v zebra-0.93b-1.i386.rpm
zebra-0.93b-1.i386.rpm:
Header V3 DSA signature: NOKEY, key ID db42a60e
Header SHA1 digest: OK (9e6c9a2b83beddb8c3c61322ac9eda6ba9bcb524)
MD5 digest: OK (255982e3ae6271a4ac1cc831d26010f0)
V3 DSA signature: NOKEY, key ID db42a60e
^^^^^
Then,
[EMAIL PROTECTED] root]# rpm --import /usr/share/rhn/RPM-GPG-KEY
[EMAIL PROTECTED] redhat9]# rpm --checksig -v zebra-0.93b-1.i386.rpm
zebra-0.93b-1.i386.rpm:
Header V3 DSA signature: OK, key ID db42a60e
Header SHA1 digest: OK (9e6c9a2b83beddb8c3c61322ac9eda6ba9bcb524)
MD5 digest: OK (255982e3ae6271a4ac1cc831d26010f0)
V3 DSA signature: OK, key ID db42a60e
^^
Clearly, doing a --checksig before install would let a sysad know that
theres something wrong here. And even if he did go ahead and install it,
during an install he would see
[EMAIL PROTECTED] redhat9]# rpm -ivh zebra-0.93b-1.i386.rpm
warning: zebra-0.93b-1.i386.rpm: V3 DSA signature: NOKEY, key ID
db42a60e
Preparing... ###########################################
1:zebra ###########################################
He would be immediatly alerted that this package was'nt a genuine RedHat
package. As you can see, a plain install of an RPM package checks the
GPG signature automatically. As long as you have RH's public key, you're
safe insofar as knowing that a non RH package was installed
> Fourth, we went to the Redhat box and did an 'rpm -U'
> pointed at the updates.redhat.com server. We got the
> trojaned RPM back, with no warnings or prompt to warn
> that it hasn't been signed.
I'm not sure how they can say this. Even doing rpm -U displays the above
warning if you dont have RH's public key.
> Linux distributions need to band together and find a
> trusted individual who will be responsible for signing
> all packages and verifying that they do not contain
> backdoors. That is the only way to solve this issue.
How does this solve the issue? It just replaces RH with a single person!
And if they dont trust RH to 'check' for backdoors how in hell is *one*
person going to check package sources for backdoors? I get the feeling
that somebody is feeling left out of things :)
> Because I myself can demonstate DNS hijacking
> targeting a network, wherein I can fool every OS on
> the network into believing that it's connected to the
> right "http://www.redhat.com/.."; which has the correct
> IP say "64.9.45.5", but using the DNS Hijacking
> utility redirect the network to "202.09.8.24" !
> I am not joking. You can get the gist of it at Robert
> Graham's site..
DNS hijacking is'nt really the point here. The redirection step is just
to get a user to download the trojanned package. The focus should be on
the package and how to check its validity. A failed GPG check is the
indicator that something is not right with your package. And once yo
have that indicator your DNS redirection is more or less useless.
> Moreover, of how many .tar.gz's that we download from
> the net do we really check the MD5 Digest?
> Many sites even do not list the MD5 Digest, leave
> alone sign the packages using PGP.
Thats very true and if I were a sysadmin managing a signifcant
infrastructure I would be very very wary of downloading random packages
- source or binary. And you could also raise the question even if you do
download a signed tarball - how do you trust the signer?
> Don't worry ! "Magic Lantern" should be targeted at
> specific users(who may interest the FBI..) and *not*
> all of us, but do think of what something similar
> might do!
Well heres a 3 step way to protect yourself:
1. Import RH's public key
2. rpm --checksig -v packagname
3. If the DSA sig is OK, install else, rm packagename
> The time is now ripe to go easy on writing everyone's
> own version of his favourite document processor, and
> focus more on standards, regression testing, quality
> and DOCUMENTATION!
How does this help the above situation?
> Let's take some time to think....
IMO the inlined article was basically FUD. Whoever wrote did'nt really
think it through. I dont think its as scary as you describe
-------------------------------------------------------------------
Rajarshi Guha <[EMAIL PROTECTED]> <http://jijo.cjb.net>
GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE
-------------------------------------------------------------------
Paper or plastic?
Not 'Not paper AND not plastic!!'
-- Augustus DeMorgan in a grocery store
--
To unsubscribe, send mail to [EMAIL PROTECTED] with the body
"unsubscribe ilug-cal" and an empty subject line.
FAQ: http://www.ilug-cal.org/node.php?id=3
