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

[Denis 'GNUtoo' Carikli]

On Sun, 14 Feb 2016 11:59:39 -0300
fauno <fauno at endefensadelsl.org> wrote:

> 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.
I'm not talking about modified packages at all.
What I'm talking about is simply tricking pacman into not installing
the latest packages.
This can be done if your main mirror is not up to date.
All packages are valid and signed, they are just too old and may
be pledged with security issues.


Separate issues:
----------------
> 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!
This is a totally different issue. I think it should be addressed too.
Verified builds is probably the solution. Centralized building might or
might not be a good idea.

> 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.
Good idea.

> 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 (?)
Verified build would solve it I think.

> > 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.  
> 
> labs.parabola.nu
I'll do that as soon as I can, it was down yesterday.

> > 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?
No. This is the main issue here.
I've explained it in my other mail.


> > 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.  
I should look into that as soon as I've the time. Even if it cannot be
used as such, it might have good documentation that explains all the
potential issues and how to fix them.

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20160214/8b2f74e3/attachment.sig>