On 07/02/2017 07:01 PM, Ismael Bouya wrote: > (Mon, Jul 03, 2017 at 12:29:44AM +0200) Morten Linderud : >> But HTTPS doesnt matter here. We have a trusted signer inn the PKGBUILD, anyone can MITM for the good of their life. >> Unless they can fake the signature (Hint; they cant), or trick Lennart into signing something he shouldnt (Hint; he >> wont), we don't have a case here. It doesn't really matter if its HTTP or HTTPS. >> >> You also didn't really reply about the threat model. > > If I understand correctly what Nicohood meant, > what could happen is that version X of systemd (or anything else) has a > well known vulnerability, fixed in X+1. X+1 is packaged, so anyone > up to date thinks "good I'm safe now". But since a man in the middle can > force to download version X (signed by the systemd maintainer so > considered "secure"), he can force you to download that version when you > create the package and you'll think you have the safe version while > having the unsafe one. Okay, this I am genuinely curious about. In what circumstances can I have: - the systemd repository cloned over the git:// protocol - an annotated tag for systemd v233 signed by Lennart Poettering. - an annotated tag for systemd v232 signed by Lennart Poettering. - a man in the middle attack - `git verify-tag --raw v233` reports a GOODSIG with a VALIDSIG ${fingerprint} that matches with Lennart's known GPG fingerprint as recorded in validpgpkeys And as a result, when I run the git command `git checkout refs/tags/v233`, I am tricked into getting v232 instead which contains a vulnerability. Also, I wouldn't be alerted by the verbose printing of the systemd version which happens during the boot process, nor by $systemd_binary --version ... Because I don't think git works that way, but I am willing to be proven wrong. Also I bet the git developers would be fascinated to hear the details, you might even get some sort of bounty for successfully hacking git like that. -- Eli Schwartz
Attachment:
signature.asc
Description: OpenPGP digital signature