Bug 11539

(In reply to Peter Müller from comment #0)
> IPFire downloads a PGP key at the first time connected to the internet. That
> key is used to verify (and decrypt?) updates and packages fetched via
> Pakfire.
> 
> However, it is not validated properly. A MITM attacker might compromise the
> system by injecting a key which passes the validation criterias; however, in
> case the correct key was already downloaded, this is not possible anymore.
> 
> IPFire should either
> - ship the appropriate PGP key already (solves some network problems) or
> - verify it correctly after being downloaded.
> 
> I will have a look at this.

Yes, I am aware that this is possible. The key should be included in the image and checked into Git.

We never have any user-interaction to check this unfortunately but potentially we could show the key on the system info page?

I will work on this but have little spare time at the moment.

Please stay patient...

(The severity is correct in my point of view, since it affects all users, and might be a major (security) issue. Well, hopefully not.)

Seems like we are still using DSA-keys for pakfire?!?!

> gpg2 -v -a -d -o decrypt 7zip-15.14.1-6.ipfire
gpg: Ursprünglicher Dateiname='7zip-15.14.1-6.ipfire'
gpg: Signatur vom Di 20 Sep 2016 17:53:09 CEST mittels DSA-Schlüssel ID 64D96617
gpg: Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel

Submitted an initial patch to validate keys by fingerprint.

Next steps:
 * develop a patch that displays a warning on likely compromised systems
 * generate a secure (4096/RSA) GPG key and
 * bake the key into the IPFire image itself.

@Michael: Any thoughts on this?

(In reply to Peter Müller from comment #3)
> Seems like we are still using DSA-keys for pakfire?!?!
> 
> > gpg2 -v -a -d -o decrypt 7zip-15.14.1-6.ipfire
> gpg: Ursprünglicher Dateiname='7zip-15.14.1-6.ipfire'
> gpg: Signatur vom Di 20 Sep 2016 17:53:09 CEST mittels DSA-Schlüssel ID
> 64D96617
> gpg: Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel

Yes. I do not have a good plan to migrate to a new set of keys.

(In reply to Peter Müller from comment #4)
> Submitted an initial patch to validate keys by fingerprint.
> 
> Next steps:
>  * develop a patch that displays a warning on likely compromised systems
>  * generate a secure (4096/RSA) GPG key and
>  * bake the key into the IPFire image itself.
> 
> @Michael: Any thoughts on this?

I do not think that it is likely that all systems are compromised for now. It is a possibility through this, but so is weak passwords, the recent possibilities to exploit OpenSSL, the kernel, etc. I would probably even weigh the likelihood of the latter higher.

Yes, I would be in favour of creating a new key. We in fact have a small chain of trust for pakfire 3 and the builders that sign the packages:

http://pgp.ipfire.org/pks/lookup?op=vindex&fingerprint=on&search=0x9B4A7F53C79921A7

Problem here is about the same where the master key is only 1024 bit long (which was standard when we created it). The builders have keys that are 4k long.

Baking the key into the image itself has the same problem that we have today: it could be changed by a third party and that would go unrecognised if people don't validate the downloaded images (which not many do). Probably need to execute #11345 first.

Patch accepted, but as mentioned already, it does not fully solve the issue.

Bringing this up again: In my opinion, we should bake the PGP key into the distribution image itself, as most Linux distributions are doing.

This saves us from downloading (and validating) the key initially, which can be problematic because of network issues.

In case we need to change the PGP key at some point - which I recommend for IPFire 2.x since we still use 1024 bit DSA -, we just release an update which contains the new key, installs it via "gpg --add-key ...", and removed the old one.

Since a client cannot skip a Core Update, no key validation issues will occur.

Thoughts?

Add the Pakfire crypto issues here for cross-reference.

This will be fixed in upcoming Core Update 120 since we do not download the key there anymore. Further, an new key is introduced which provides better cryptographic strength.

The key is not being imported in the flash image, yet.

I do not really want to do this at build time, but haven't really written an initscript yet, that does this because I am not sure how easy it is to exploit this.

(In reply to Michael Tremer from comment #10)
> The key is not being imported in the flash image, yet.
> 
> I do not really want to do this at build time, but haven't really written an
> initscript yet, that does this because I am not sure how easy it is to
> exploit this.
Thanks for the update here. As soon we made some progress with rspamd, I'll thake a look at the initscript.

Better be quick, since this is going to be shipped with C120.

(In reply to Michael Tremer from comment #12)
> Better be quick, since this is going to be shipped with C120.
All right, here you go...

The initscript looks okay to me. Thinking paranoid, I would like to have a checksum verification first, however, this does not make sense since if anybody is able to change the key at _that_ point, he/she/it needs to have access to a newly set up firewall systems, and its operator might have more serious problems then. :-)

So, I am happy with this.

Yes, I had a similar concern, but if someone is able to change the key file,
they can also import other keys or worse...

On Mon, 2018-03-26 at 18:54 +0000, IPFire Bugzilla wrote:
> Comment # 13 on bug 11539 from Peter Müller
> (In reply to Michael Tremer from comment #12)
> > Better be quick, since this is going to be shipped with C120.
> All right, here you go...
> 
> The initscript looks okay to me. Thinking paranoid, I would like to have a
> checksum verification first, however, this does not make sense since if
> anybody
> is able to change the key at _that_ point, he/she/it needs to have access to a
> newly set up firewall systems, and its operator might have more serious
> problems then. :-)
> 
> So, I am happy with this.
> You are receiving this mail because:
> You are on the CC list for the bug.

This plan has just received a considerable blow:

> [root@ipfire ~]# gpg --verify server-list.db
> gpg: Signature made Thu Mar 29 20:46:12 2018 CEST using DSA key ID 64D96617
> gpg: Good signature from "Michael Tremer (Pakfire Signing Key) <paks@ipfire.org>"
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:          There is no indication that the signature belongs to the owner.
> Primary key fingerprint: 1797 40DC 4D8C 47DC 63C0  99C7 4BDE 364C 64D9 6617
> gpg: Signature made Thu Mar 29 20:46:12 2018 CEST using RSA key ID D713594B
> gpg: Can't check signature: public key not found

Exit code is 2, and therefore Pakfire considers the file being signed with two keys as invalid.

I do not see a way how we can perform some backwards-compatible changes to pakfire here so that it will just ignore the other signature.

What we should have done is:

> [root@ipfire ~]# gpg --verify < server-list.db --status-fd 1
> gpg: Signature made Thu Mar 29 20:46:12 2018 CEST using DSA key ID 64D96617
> [GNUPG:] SIG_ID RJIOkTzxoyc78hTyRvkL4Ry5t+A 2018-03-29 1522349172
> [GNUPG:] GOODSIG 4BDE364C64D96617 Michael Tremer (Pakfire Signing Key) <paks@ipfire.org>
> gpg: Good signature from "Michael Tremer (Pakfire Signing Key) <paks@ipfire.org>"
> [GNUPG:] VALIDSIG 179740DC4D8C47DC63C099C74BDE364C64D96617 2018-03-29 1522349172 0 4 0 17 10 01 179740DC4D8C47DC63C099C74BDE364C64D96617
> [GNUPG:] TRUST_UNDEFINED
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:          There is no indication that the signature belongs to the owner.
> Primary key fingerprint: 1797 40DC 4D8C 47DC 63C0  99C7 4BDE 364C 64D9 6617
> gpg: Signature made Thu Mar 29 20:46:12 2018 CEST using RSA key ID D713594B
> [GNUPG:] ERRSIG 6FEF7A8ED713594B 1 10 01 1522349172 9
> [GNUPG:] NO_PUBKEY 6FEF7A8ED713594B
> gpg: Can't check signature: public key not found

And in this output, grep for VALIDSIG with the correct key.

Please have a think if you see a way how to continue with both signatures. Otherwise we have to wait until IPFire "2.21" where we create a new directory and sign packages and lists with the new key only.

Hmmm, we still have gnupg 1.4.x on IPFire. I am not quite sure, but I think 2.x was handling that case better. Except of grepping in the programs' output, I do not have a better solution, yet. Sorry.

For the records: Michael submitted https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=3e29608f826cb86244295697951ec0976345705e which changed the behaviour here.

We can update GnuPG if you prefer. 2.x only has many dependencies and
1.x is quite lightweight and still maintained AFAIK.

But please send patches if you would like to see this updated. But
please test pakfire thoroughly before.

For the record: Phase 1 of key rollover started with Core Update 120 (https://www.ipfire.org/news/ipfire-2-19-core-update-120-released).

Yes, if next becomes IPFire 2.21, then we will remove the old key straight away
and sign all packages with the new key only.

@Michael: It seems like mirror data for 2.21 is signed with the new key. Can this be closed?

Yes, this is all done and seems to be working well.

Great. Thanks very much.