| |||||||||||
|
| |||||||||||
Technology supportTechnology supportPosted Dec 21, 2007 7:05 UTC (Fri) by geertj (subscriber, #4116)Parent article: The backdooring of SquirrelMail
The more I read about source code being compromised, the more I am convinced we need technology support (as opposed to procedural support) to prevent any such modifications from being trusted and/or used by anyone. Projects have become so big that manual audits of the source code to look for backdoors become increasingly less effective. For example, if in the case of this SquirrelMail compromise, the attacker had also updated the checksum, then it may have taken even longer for this to come out. A good place for implementing such support would in my view be the version control system. The Monotone version control system identifies files and trees with a cryptographically secure fingerprints, and it uses digital signatures to assert arbitrary statements about versions and changes (such as: author so-and-so created this change on so-and-so date). The way I understand it, an attacker could add whatever he wants to a monotone repository, as long as the primary developers' public keys are not compromised, this will be completely harmless. A similar situation exists for a developer: you can pull whatever changes you want into your local repository database from whatever dodgy site on the net: as long as you have not assigned trust to a particular public key those changes will be harmless. I am thinking of switching a few of my open source projects over to Monotone just to see how it works.
(Log in to post comments)
Technology support Posted Dec 21, 2007 20:00 UTC (Fri) by giraffedata (subscriber, #1954) [Link] But that wouldn't be effective against what happened with Squirrelmail, since the code was changed after it came out of the source repository. And it may not be effective against hackers who put code into source repositories either, because if you can get commit privilege on a Subversion server, you can probably also add a public key to a Monotone server or sign code as some authorized developer.
Technology support Posted Dec 21, 2007 20:27 UTC (Fri) by geertj (subscriber, #4116) [Link] But that wouldn't be effective against what happened with Squirrelmail, since the code was changed after it came out of the source repository. It would be effective if the users would pull the code directly from a Monotone netsync server using "mtn sync". There is indeed no protection against modifying a tarfile after it is released from a monotone repository. And it may not be effective against hackers who put code into source repositories either, because if you can get commit privilege on a Subversion server, you can probably also add a public key to a Monotone server or sign code as some authorized developer.
Being a distributed version control system, a typical way to deploy monotone is for all developers to have their own repository on their private workstations, and in addition to this one central netsync server connected to the Internet to which everybody synchronises. The development workstations can be behind a firewall and do not need to accept any incoming connection. The developers would normally store their private keys only on their workstations, hopefully protected by a passphrase. In this setup, a compromise of the netsync server (which is more likely than a compromise of a developer workstation because it is a public server) would not impact the security of the monotone sources hosted on it. The attacker can add anything to the repository he wants, but he has no access to a key that is trusted by the other developers with which he can certify the new revision.
|
|||||||||||