[arch-general] Pacman Database Signatures
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.
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
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
On 2/2/20 4: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?
As Levente said, this is supported by pacman, but not by Arch Linux -- and the reason for the latter is that it is complicated to come up with a signing scheme which everyone is happy with. It needs to support remote server signing by any of 74 different authorized individuals.
Hopefully there will be wonderful news soon. In the meantime, I for one make sure that my personal repository hosted on https://pkgbuild.com includes database signatures.
On Wednesday, February 5, 2020 3:55 AM, Eli Schwartz via arch-
As Levente said, this is supported by pacman, but not by Arch Linux -- and the reason for the latter is that it is complicated to come up with a signing scheme which everyone is happy with. It needs to support remote server signing by any of 74 different authorized individuals.
Hopefully there will be wonderful news soon. In the meantime, I for one make sure that my personal repository hosted on https://pkgbuild.com includes database signatures.
Thank you both for the replies. I hope there is some wonderful news soon.
On Wednesday, February 5, 2020 3:55 AM, Eli Schwartz via arch-general arch-general@archlinux.org wrote:
On 2/2/20 4: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?
As Levente said, this is supported by pacman, but not by Arch Linux -- and the reason for the latter is that it is complicated to come up with a signing scheme which everyone is happy with. It needs to support remote server signing by any of 74 different authorized individuals.
Hopefully there will be wonderful news soon. In the meantime, I for one make sure that my personal repository hosted on https://pkgbuild.com includes database signatures.
Has there been any update or progress in this area?
On 2/2/20 4:59 PM, Christopher W. via arch-general wrote:
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.
This is a more interesting topic to me, personally (as opposed to the first half of your email which I responded to separately) because it's a proposal for something that pacman itself could do better, without waiting on distro policy.
It's also a discussion that will go nowhere, and then die alone, on arch-general, since pacman development and proposals happen exclusively on the pacman-dev mailing list. Therefore, I am cc'ing the pacman-dev mailing list so that this has a chance to go somewhere. :)
Since I'm unfamiliar with apt and other tools, what exactly do they do? Given pacman/apt/your-choice-of-package-manager must somehow write to a cachedir, e.g. /var/cache/pacman/pkg, it would need a dedicated download user, which would then exclusively hold ownership of the cachedir.
pacman is one big binary at the moment, it doesn't fork+exec to run collections of binaries implementing different parts of the package manager (which is actually a plus when it comes to speed), so this might entail major re-architecturing of that part of pacman. Doing it for external XferCommand programs could be a start.
Is this a topic you're interested in exploring?
On 2/4/20 11:08 PM, Eli Schwartz wrote:
Since I'm unfamiliar with apt and other tools, what exactly do they do? Given pacman/apt/your-choice-of-package-manager must somehow write to a cachedir, e.g. /var/cache/pacman/pkg, it would need a dedicated download user, which would then exclusively hold ownership of the cachedir.
pacman is one big binary at the moment, it doesn't fork+exec to run collections of binaries implementing different parts of the package manager (which is actually a plus when it comes to speed), so this might entail major re-architecturing of that part of pacman. Doing it for external XferCommand programs could be a start.
Is this a topic you're interested in exploring?
I've opened a feature request for this: https://bugs.archlinux.org/task/65401
participants (4)
-
Christopher W.
-
Eli Schwartz
-
Justin Capella
-
Levente Polyak