[Dev] Mirrors vulnerability issue, Many outdated installs in the wild

fauno fauno at endefensadelsl.org
Sun Feb 14 14:59:39 GMT 2016

Denis 'GNUtoo' Carikli <GNUtoo at no-log.org> writes:
> As for shorter term, we probably need to make sure the mirrorlist is
> coming from a trusted mirror that can be updated.
> We should of course use transports that can't be tempered with, such
> as https or onion services it. Else a man in the middle can just
> replace what is being downloaded by older versions.

i think to trick pacman into installing compromised packages an attacker
would need to compromise the ISOs first, since it's the moment you
bootstrap the keyring database.

any modified package after that would throw an error, because:

* the package won't be signed and default pacman.conf requires

* the package would be signed with a gpg key that's not on the keyring,
thus asking the user what to do

* the attacker would include her gpg key into the keyring, but she would
  have to sign the keyring with a key from the previous keyring

but if you distribute ISOs with your key on it, you would have control
over what's trusted by pacman afterwards :D

at this point it would just be easier to become a parabola packager and
start pushing compromised packages.  a clever attacker could just
replace the parabola-keyring with another one including gpg keys under
her control, and pushing it for a few minutes at a time so we don't
notice the swap :3

or just distribute backdoored stuff and get away with it!

i also think pacman shouldn't trust new keys, even when the signature of
the package is valid (meaning someone trusted the packager for you).
new keys should be signed by at least three other keys already trusted
by pacman.

the ideal scenario would be for people to build a solid wot with
packagers, and pacman to check package validity against this database.
of course this is impractical (?)

> We should also warn the users on the parabola website as soon as
> possible.
> I should also do a proper bugreport.
> I've also no idea how CVE are created.


> Medium term:
> ------------
> We might want to split the db update files from the packages, and make
> the parabola infrastructure serve them, still with a transport that
> can't be tempered with to avoid man in the middle attacks.

you mean the databases will always be served from our servers?  this
would require patching pacman to hardcode those addresses no?

wouldn't this be solved by signing databases?

> Long term:
> ----------
> We should make sure that pacman update the db files safely, in a
> distributed manner.
> I've also heard about an update framework that
> address some of the issue https://theupdateframework.github.io/ but I
> didn't look into it yet.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 584 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20160214/0322ef5e/attachment.sig>

More information about the Dev mailing list