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@xxxxxxxxxxxxx> 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 > >
