[arch-general] Pacman Database Signatures

[Justin Capella]

Could a tempfile be used or the file name from the URL instead of the
content disposition? At least prior to signature verification? Seems this
could still be "exploited" by specifying a file name of another source in
the package perhaps? Makes me wonder about the ::dest suffix of sources
albeit that is somewhat different case.

On Sun, Feb 2, 2020, 2:26 PM Levente Polyak via arch-general <
arch-general at archlinux.org> wrote:

> On 2/2/20 10:59 PM, Christopher W. via arch-general wrote:
> > Hi. The wiki states that database signatures for pacman are currently
> > a work in progress. It's been that way for a long time, so I assume
> > there is no "progress" happening. What is currently in the way of this
> > much-needed security feature to be fully implemented?
> >
> > Right now, pacman is taking untrusted input from the internet as root.
> > That's very bad. Most of the comments I've seen say that an attacker
> > could hold back vulnerable packages, but this is assuming the attacker
> > does not have bigger plans. The pacman tool is not immune to bugs in
> > the way it parses the database files. It has no privilege separation
> > in the download/parsing code as far as I can see (apt and others have
> > had this for a long time) so it's really an even more dire situation.
> > Pacman should not perform any operations as root until it has verified
> > the signature of all files being used to install/upgrade the packages,
> > but it currently does everything (downloading, verifying, etc) as root.
> >
> > I'd like to get a discussion going about how and when these two issues
> > could be resolved so that all Arch users can be safer. Thanks.
> >
>
> Hi,
>
> it was indeed stalled for quite a long time without real progress. The
> reason has been that some packagers refused to sign the database file
> with their own key for various reasons.
> The good news is, it is being worked on lately. Right now we are
> figuring out some flows and models how we want to do that, like
> smartcards or TPM and how to set that up and maintain it. In fact we
> have been working on that today and during the whole weekend at FOSDEM,
> so things are moving and we will get there :)
>
> However, this doesn't mean it will instantly become bullet proof.
> Software and security is far more complex than that and also APT and
> friends are not an unbreakable software even when having signed
> databases/indicies:
>
> APT CVE-2019-3462
> Incorrect sanitation of the 302 redirect field in HTTP transport method
> of apt versions 1.4.8 and earlier can lead to content injection by a
> MITM attacker, potentially leading to remote code execution on the
> target machine.
>
> In case of pacman, signed databases would have protected against
> CVE-2019-18183 and CVE-2019-18182 but not against:
> https://security.archlinux.org/CVE-2019-9686 leading to arbitrary code
> execution when using -U on a remote target.
>
> Before drifting to much away and philosophizing about privilege
> separation and dropping privileges for certain tasks, lets get back to
> the main question/topic here: Right now there isn't much discussion
> needed, a team is actively working on exactly that topic and will
> present their considerations, implementations and results to A-D-P for
> some feedback rounds before potentially going live.
>
> cheers,
> Levente
>
>