[arch-general] Pacman Database Signatures

[Levente Polyak]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20200202/974c796b/attachment.sig>