Signing snapshots

[John A Meinel]

Martin Pool wrote:

>On 21 Jun 2005, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
>
>
>>Hi all,
>>
>>Part of the plan for signing in bzr was to sign the snapshot, not the
>>data generated from it (i.e. the revision store gzips or whatever).
>>
>>In #arch, Andrew Suffield has listed a couple of reasons why he thinks
>>this is a terrible idea.
>>
>>00:29 < abentley> asuffield: let's say as a straw-man, we took an
>>                  inventory of the tree, with SHA-1 sums, sorted that
>>		  inventory in a rigorously defined way, and signed it. 			   What
>>kind of holes would you expect to find?
>>
>>
>
>As we discussed a little while ago, we primarily plan to actually sign
>the revision, which includes by reference the inventory.  That doesn't
>make any difference to asuffield's points though.
>
>
>
>>00:30 < asuffield> abentley: I would expect to find DoS attacks against
>>		   the inventory process and ways to slip files past it
>>		   which never appear in the inventory, and that's
>>		   without even thinking about it
>>
>>
>
>I think that is less plausible with bzr than with arch; files which
>aren't in the inventory simply don't exist from bzr's point of view,
>and won't be considered for merging.  I suppose someone could try
>tricks with those files existing as ignored or unknown, but that just
>means the tool must never assume those are covered by the signature,
>of course.
>
>
>
I agree. If you have a tarball, you might put extra files in there, and
then the inventory could have them removed. But with bzr, the way the
revisions are stored, they have to be in the inventory in order for them
to be requested.

>>00:31 < asuffield> I would also expect to find implementation bugs that
>>		   were exploitable, probably suitable for remote
>>		   arbitrary code execution
>>
>>
>
>This is certainly a good point; the verification should be done as
>early as possible in the pipe, so that untrusted data gets to touch
>the least code.
>
>>From this perspective the tla approach of writing the hash of the
>files then signing the hashes is rather nice.  All we need to do with
>untrusted data is calculate its hash, and we can be reasonably sure
>that there won't be vulnerabilities in the SHA-1 calculator.  There
>might be some in the code that parses the checksum file or the gpg
>signature.  On the other hand this approach flakes out of the more
>important problem of evaluating whether the code is signed by a
>meaningful key.
>
>One approach is to just put a GPG signature next to every revision
>file, and verify that before reading the revision.  In that case the
>only exploitable code is GPG itself.
>
>  gpg --detach-sign .bzr/revision-store/thingthing
>
>
The question I have is do you sign the original text, or do you sign the
gzipped form of the text? To me it seems that you want to sign the
actual text, but that would require uncompressing the file.
When I was playing around with signing, I found that detached signatures
would be a lot easier to support, as they do not change the text you
care about (elementtree doesn't handle skipping signatures, you have to
extract it by yourself). However, that does add 1 more file per
revision. Not a lot, though.
I assume that with a detached signature there is a way to determine what
key was used, without actually having to check the validity of the
signature.

>Perhaps the most interesting attack method is to mail someone a
>malicious changeset, because this avoids the need to convince the
>targetted user to access a malicious server.
>
>
>
Well, if you are being paranoid, only accept signed changesets, and only
accept signatures you trust. Depending on the serialization format, it
is pretty easy to wrap it in a signature.

...

>>He also pointed out that there have been exploits against gzip in the
>>past, that that, in his estimate neither tar nor gzip can be considered
>>secure.  Good thing we don't use tar, I guess :-)
>>
>>
>
>asuffield will probably disagree, but I don't feel obliged to design
>something safe in the presence of holes in gzip.
>
I would guess that there are a couple layers which are implicitly
trusted. Spelling them out explicitly would probably not be a bad idea.

Also, out of curiosity, how are you planning to interface to signature
stuff? Just spawing gpg for now?

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050621/00027726/attachment.pgp