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