Date: Mon, 12 Mar 2001 13:58:03 -0500 (EST) From: Trevor Johnson <trevor@jpj.net> To: Maxim Sobolev <sobomax@FreeBSD.ORG> Cc: Kris Kennaway <kris@obsecurity.org>, <ports@FreeBSD.ORG>, Alistair Crooks <agc@pkgsrc.org> Subject: Re: new message digest support in pkgsrc (fwd) Message-ID: <20010312072136.C2937-100000@blues.jpj.net> In-Reply-To: <3AACBA28.FA288681@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Please think about it again: in the case when author is in fact attacker he would not have to break md5 to get his > code into users' machines. How many FreeBSD port maintainers read every single line of code/configure > scripts/makefiles/whatever in the new version of software to detect possible trojans? Stronger checksum will not > help in this case, sorry. Indeed, some software in the ports collection is only available to us as binaries. However, the source for some ported software has been reviewed. For those ports, stronger checksums will help. For the rest, I believe that they will not hurt significantly. This is another tangential problem which should be addressed in its own right. A way to address it would be by distinguishing the carefully reviewed ports in some way. Keeping a list of them and/or having a makefile variable to indicate it, together with an /etc/make.conf variable that users can set if they only want to install reviewed ports, or want to install unreviewed ports manually, rather than having them automatically added by dependencies, would be a possible solution. > See above. In the case when author == attacker checksum algorithm doesn't protect anything, ...except for ports which were reviewed. >, in all other cases MD5 > is more than adequiate. My (possibly incorrect) understanding is that an attack is sometimes possible, but more computationally expensive, when the original distfile was generated innocently. For example: - honest programmer writes a program which gets ported - attacker verifies that a colliding distfile can be constructed - attacker copies distfile to a "mirror site" (under control of attacker) - attacker gets porter to add the "mirror" to MASTER_SITES - attacker places malicious distfile To lessen the expense, I conjecture that an attacker could instead change a distfile in such a way that it would still extract correctly, with at most a harmless-looking warning. For instance, I did this on freefall: $ touch foo $ gzip foo $ echo "garbage" >>foo.gz $ gzip -tv foo foo.gz: gzip: foo.gz: decompression OK, trailing garbage ignored OK $ tar cf foo.tar foo.gz $ echo "more garbage" >>foo.tar $ tar tvf foo.tar -rw-r--r-- trevor/trevor 32 Mar 12 07:00 2001 foo.gz $ tar xvf foo.tar foo.gz $ zip foo.zip foo.gz adding: foo.gz (deflated 16%) $ echo "still more garbage" >>foo.zip $ unzip -tv foo.zip Archive: foo.zip testing: foo.gz OK No errors detected in compressed data of foo.zip. $ rm foo;touch foo $ bzip2 -9 foo $ echo "garbage in" >>foo.bz2 $ bzip2 -tv foo.bz2 foo.bz2: trailing garbage after EOF ignored ok $ bzip2 -d foo.bz2 bzip2: foo.bz2: trailing garbage after EOF ignored $ rm foo* $ touch foo $ echo "garbage pail" >bar $ gzip foo $ gzip -c bar >>foo.gz $ gzip -tv foo.gz foo.gz: OK $ rm * $ touch foo $ tar cf foo.tar foo $ ls -l foo.tar -rw-r--r-- 1 trevor trevor 10240 Mar 12 09:10 foo.tar $ split -b 5120 foo.tar $ echo "mal" >bar $ cat xaa bar xab >myfoo.tar $ tar tvf myfoo.tar -rw-r--r-- trevor/trevor 0 Mar 12 09:10 2001 foo $ tar xvf myfoo.tar foo $ ls -l foo -rw-r--r-- 1 trevor trevor 0 Mar 12 09:10 foo Note my lack of subtlety, the reassuring "ok" from bzip2 and double "OK" from gzip, and the lack of any warnings from tar and unzip (also gzip was silent, once I put the padding into gzipped format--yes, it took me awhile to think of these examples). Such changes could easily escape notice in a source code review. After all, the source was not changed. If they were noticed, they would be unlikely to arouse suspicion. Even the gzipped padding might be assumed to have come from an innocent mixup with another gzipped file. A note on -ports like: Please add ftp://ftp.0wn3d.invalid/malware/ to MASTER_SITES for the saintlyware port. The one master site, ftp.saintlyware.invalid, acts really weird, but I used FTP Search and found the tarball on ftp.0wn3d.invalid. The copy I found has a different sum, so please add that too. You can keep the old checksum and keep ftp.saintlyware.invalid in the MASTER_SITES, just in case it comes back online someday. I kinda doubt it will. How about having the 0wn3d site as the first one so people don't waste time checking saintlyware? It takes forever to time out! Anyway, there's a distfile on ftp.freesoftware.com with the old sum. I untarred both of them and ran diff. It didn't show any changes. There was just a message about "trailing garbage" when I untarred. Some crap must've gotten tacked onto the end in one of saintlyware's disk crashes. Damn their flaky Linux boxes! or a PR to the same effect might well be successful. At the attacker's leisure, the copy on the new (owned) master site would be replaced by the colliding distfile to complete the attack. If the Saintlyware site were itself "owned" then the attack could still work, so long as the honest programmer didn't bother to replace the changed distfiles. Suppose she hadn't kept any other copy besides the one she uploaded, or just wasn't troubled by a few harmless-looking garbage characters, or didn't even notice (maybe the FreeBSD porter "fixed" the port without telling her). Another possibility would be for an attacker to gain control of a site that has a submission queue for uploads, then wait for the honest programmer to upload a new version of her program. While in the submission queue, it could be intercepted and modified to create a hash collision. This relies on the honest programmer not noticing the changes (because her original submission never sees the light of day, it's likely no one will tell her about them), on the legitimate operators (if any) of the site not noticing the substitution, and on the submission queue being slow enough to disguise the time needed to create the colliding pair. -- Trevor Johnson http://jpj.net/~trevor/gpgkey.txt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010312072136.C2937-100000>