[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 21 Apr 2020 19:47:47 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Cc: "info@...nvakil.com" <info@...nvakil.com>
Subject: Re: Pacman package manager - taking untrusted input
On Tue, 21 Apr 2020 at 21:51:56 +0430, Amin Vakil wrote:
> On 4/21/20 8:57 PM, jellicent@...tonmail.com wrote:
> > The code supports database signatures, so the real issue is the distro
> > infrastructure.
I interpret this as: pacman can accept either signed or unsigned
databases, but the various distros that use pacman (such as Arch Linux)
currently only publish unsigned databases in practice. Is that correct?
Can pacman be configured to *only* accept signed databases, so that a
mirror containing an unverifiable database (unsigned, signed with a key
that is not explicitly trusted, or with an invalid signature) is treated
as an error? If it cannot, then there's an obvious downgrade attack:
a malicious mirror could substitute an unsigned database and the pacman
client would happily use that.
On Tue, 21 Apr 2020 at 17:41:42 +0000, jellicent@...tonmail.com wrote:
> An attacker need only find a bug in how Pacman does
> parsing/reading of the database file to potentially get code execution
> on the box as root.
My understanding is that this is a risk, and at least arguably a design
flaw, but not generally considered to be a vulnerability (CVE IDs,
etc.) unless/until an unfixed parser bug with the necessary severity
is found.
Of course, that doesn't mean it wouldn't be a good idea to authenticate
the database before parsing it: that would mitigate a lot of potential
vulnerabilities.
Something that might be considered to be a vulnerability already (or not,
depending on the pacman and distro maintainers' threat models) is that
an attacker could substitute a database that lists obsolete packages
with known vulnerabilities. Those packages will presumably be validly
signed by distro developers (because at one time they were considered
to be the best version available). Presumably pacman won't normally
downgrade from the version it has installed to a strictly older version
from a mirror, but if a user installs a new (not currently installed)
package using that mirror/database, they'll unknowingly be installing
an older package that has known vulnerabilities.
That form of attack is difficult to address in general, because it needs
a revocation or expiry mechanism. apt-based distros are starting to
address equivalent issues by setting a Valid-Until field on their archive
metadata, so that clients will warn their user if presented with outdated
archive metadata (the equivalent of pacman's database) - although this is
somewhat awkward to deploy, because it requires a signing key to be
made available on a regular basis, which conflicts with the idea that
high-value signing keys should be kept offline when not in use.
smcv
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
