OpenBSD Journal

g2k16 Hackathon Report: Marc Espie on package signing evolution

Contributed by rueda on from the Let us signify you dept.

The next developers' hackathon report is from Marc Espie, who writes:

First time in Cambridge!

I wasn't expecting it to live up to the hype, but it really is a lovely place... maybe a bit too clean and cliche for comfort, it's like you wandered into a Harry Potter movie.
Anyway, I came into this hackathon with a stupid idea. Turned out, I showed it to people and they liked it (oh noes), so I ended up spending half of the hackathon expanding signify(1) and the second half working on pkg_add proper.

(Proper is appropriate... everything is proper in Cambridge. Proper food, proper language, GDBO... we finally had proper english weather during the week-end).

So, the gist of that idea is that FreeBSD got a fairly sophisticated attack against some upgrade mechanism. The upgrade data is signed, but everything is inside an archive, and the attack was against the archive, most specifically the decompression code, before signatures are even checked.

Sounds familiar ? We used to do the same. Binary packages are gzip'd tarballs, which used to contain a signed plist, and checksums for every file.

With that scheme, the same problem could happen. You have to trust the decompression code to not be broken... Compressors are notorious for being complicated and fast... just because you don't *know* about a bug in there doesn't mean there isn't one.

So I thought: "let's move the signature outside the compressed data, so that we never ever pass unsecure data to the decompression algorithm".

We had some try at that a lot of years back (gzsig), but that old program was very clunky and inadequate, and we've learnt so much since.

So the new scheme is a signify option (-z) that stuffs signatures straight into the gzip header "comment" field. Signify gained some very simple code to parse gzip headers (without any fancy options, so that this code is simple enough). The signature proper is just sha512/256 checksums for 64K blocks.

The nice thing about that scheme is that you don't have to download the full archive first... just the header and signature part, then you can pass the data along at 64K per block. Ideal for pipelining situations.

This stuff is fairly generic and can actually be used to sign any gzip'd file.

The next part involved getting pkg_add to cooperate... Moving back to older code somewhat, as we used to have an extra pipe for gzip. Tweaking things so that we get decent error reports from signify. And getting actual data thru the (verified) comment, such as signing date, and whatnot.

The last part should happen over the next week. As soon as everybody involved is satisfied and relevant signing infrastructure has been updated, we just have to distribute new packages, and flip a switch in pkg_add.

The old signing scheme is going to die very very quickly. There's still some option that allows you to install older packages, but really, there's little point to installing older packages with the new scheme once the snapshots catch up.

The only "drawback" to the new scheme is that there is no longer any way to install unsigned packages once you commit to using signify.

So you have to specify upfront that you don't want to check signatures (pkg_add -Dunsigned), otherwise everything involving gzip files will error out... there is no "after the fact" interactive prompt involved.

Thanks for the report and the work that went into the code, Marc!

(Comments are closed)


  1. By Blake (2a01:e34:ec06:8f90:cabc:c8ff:fedb:4d83) undeadly@2112.net on 2112.net

    <A HREF="http://fr.urbandictionary.com/define.php?term=GDBO">In case anyone's wondering what "GDBO" means...</A>

    1. By Marc Espie (espie) on

      > <A HREF="http://fr.urbandictionary.com/define.php?term=GDBO">In case anyone's wondering what "GDBO" means...</A>

      dude, of course you can google it up. That's what I did.

      But the joke is to use the acronym and not explain it, if you explain it, that kind-of spoils the effect.

      1. By Anonymous Coward (2001:470:caec:0:c62c:3ff:fe1d:1685) on

        > > <A HREF="http://fr.urbandictionary.com/define.php?term=GDBO">In case anyone's wondering what "GDBO" means...</A>
        >
        > dude, of course you can google it up. That's what I did.
        >
        > But the joke is to use the acronym and not explain it, if you explain it, that kind-of spoils the effect.

        Kinda like https://xkcd.com/1460/

  2. By Marc Espie (espie) espie@nerim.net on

    Found back the link that led to this week's work. freebsd security ml message

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]