Security pitfalls of .tar.asc

Security pitfalls of .tar.asc

[Jason]

Hi list,

The upcoming cgit 1.2 release will have support for attaching .asc
signatures to tarballs. Adding a .tar.xz.asc is straightforward and
works as expected. But there's also display logic for showing .tar.asc
signatures next to .tar.xz files. The intent is to do something like
this:

$ curl -LO https://git.zx2c4.com/cgit/snapshot/cgit-1.1.tar.xz
 % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                Dload  Upload   Total   Spent    Left  Speed
100 86268    0 86268    0     0   122k      0 --:--:-- --:--:-- --:--:--  123k
$ curl -LO https://git.zx2c4.com/cgit/snapshot/cgit-1.1.tar.asc
 % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                Dload  Upload   Total   Spent    Left  Speed
100   858    0   858    0     0   2150      0 --:--:-- --:--:-- --:--:--  2177
$ unxz cgit-1.1.tar.xz
$ gpg --verify cgit-1.1.tar.asc
gpg: assuming signed data in 'cgit-1.1.tar'
gpg: Signature made Thu 05 Jul 2018 02:34:20 AM CEST
gpg:                using RSA key AB9942E6D4A4CFC3412620A749FC7012A5DE03AE
gpg:                issuer "jason at zx2c4.com"
gpg: Good signature from "Jason A. Donenfeld <Jason at zx2c4.com>" [ultimate]

This works fine, but there's something a bit troubling about it: it
means that users are instructed to run untrusted tarballs through
`unxz`, which is big and complicated and could have nasty
vulnerabilities. My understanding is that this is desired because
.tar.xz is not stable -- xz might do different things between versions
or compression levels -- whereas git considers its .tar output to be a
stable format. So I can see why it'd be desirable to host .tar.asc
instead of .tar.xz.asc. But from a security perspective, this might be
sub-optimal.

Thoughts?

Regards,
Jason

Security pitfalls of .tar.asc

[list]

"Jason A. Donenfeld" <Jason at zx2c4.com> on Thu, 2018/07/05 02:54:
> Hi list,
> 
> The upcoming cgit 1.2 release will have support for attaching .asc
> signatures to tarballs. Adding a .tar.xz.asc is straightforward and
> works as expected. But there's also display logic for showing .tar.asc
> signatures next to .tar.xz files. The intent is to do something like
> this:
> 
> $ curl -LO https://git.zx2c4.com/cgit/snapshot/cgit-1.1.tar.xz
>  % Total    % Received % Xferd  Average Speed   Time    Time     Time
> Current Dload  Upload   Total   Spent    Left  Speed
> 100 86268    0 86268    0     0   122k      0 --:--:-- --:--:-- --:--:--
> 123k $ curl -LO https://git.zx2c4.com/cgit/snapshot/cgit-1.1.tar.asc
>  % Total    % Received % Xferd  Average Speed   Time    Time     Time
> Current Dload  Upload   Total   Spent    Left  Speed
> 100   858    0   858    0     0   2150      0 --:--:-- --:--:-- --:--:--
> 2177 $ unxz cgit-1.1.tar.xz
> $ gpg --verify cgit-1.1.tar.asc
> gpg: assuming signed data in 'cgit-1.1.tar'
> gpg: Signature made Thu 05 Jul 2018 02:34:20 AM CEST
> gpg:                using RSA key AB9942E6D4A4CFC3412620A749FC7012A5DE03AE
> gpg:                issuer "jason at zx2c4.com"
> gpg: Good signature from "Jason A. Donenfeld <Jason at zx2c4.com>" [ultimate]
> 
> This works fine, but there's something a bit troubling about it: it
> means that users are instructed to run untrusted tarballs through
> `unxz`, which is big and complicated and could have nasty
> vulnerabilities. My understanding is that this is desired because
> .tar.xz is not stable -- xz might do different things between versions
> or compression levels -- whereas git considers its .tar output to be a
> stable format. So I can see why it'd be desirable to host .tar.asc
> instead of .tar.xz.asc. But from a security perspective, this might be
> sub-optimal.
> 
> Thoughts?

Well, providing signatures for the uncompressed tar is common practice for
different projects, linux [0] and e2fsprogs [1] just being two of them.

This was requested from Konstantin Ryabitsev to be used on kernel.org.

As nobody is forced to use this I am fine this way. Note that providing a
signature for .tar.{gz,bz2,xz} makes the download link for .tar.asc disappear
even if the signature is available.

[0] https://cdn.kernel.org/pub/linux/kernel/v4.x/
[1]
https://mirrors.edge.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/v1.44.2/

-- 
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Best regards             my address:    */=0;b=c[a++];)
putchar(b-1/(/*    Chris            cc -ox -xc - && ./x    */b/42*2-3)*42);}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/cgit/attachments/20180705/78ee37aa/attachment.asc>

Security pitfalls of .tar.asc

[konstantin]

On Thu, Jul 05, 2018 at 02:54:52AM +0200, Jason A. Donenfeld wrote:
> This works fine, but there's something a bit troubling about it: it
> means that users are instructed to run untrusted tarballs through
> `unxz`, which is big and complicated and could have nasty
> vulnerabilities. My understanding is that this is desired because
> .tar.xz is not stable -- xz might do different things between versions
> or compression levels -- whereas git considers its .tar output to be a
> stable format. So I can see why it'd be desirable to host .tar.asc
> instead of .tar.xz.asc. But from a security perspective, this might be
> sub-optimal.
> 
> Thoughts?

I've had the same discussion with Debian folks a little while back,
which I won't rehash here -- see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882694#25

Worrying about vulnerabilities in unxz is valid, but xz is merely the
last tool in a whole chain of software a person would need to use to get
the tarball and the signature file to where they could run unxz and
gpg --verify. We'd also need to worry about curl/wget/firefox, the tcp
stack, the "ls" and "cp" commands, etc etc.

On the kernel.org side of things we offer sha256sums.asc file in each
directory specifically as a way to quickly verify file integrity before
running unxz (but you still have to download that file, so the caution
about wget/curl/firefox/etc/etc remains :)).

-K