You are not logged in.

#1 2012-10-15 03:37:50

Cylinder57
Member
Registered: 2012-04-30
Posts: 29

What Are the Security Implications of not Completely Signing Database?

Hello everyone,

What are the security implications of not completely signing the database?

From http://www.archlinux.org/pacman/ ,

The following quote implies that the database exists merely just in case hand tweaking is necessary:

maintains a text-based package database (more of a hierarchy), just in case some hand tweaking is necessary.

However, considering that there are cases that pacman's local database needs to be restored, there are implications that the database is essential for pacman to function properly.

From https://wiki.archlinux.org/index.php/Ho … l_Database :

Restore pacman's local database

Signs that pacman needs a local database restoration:

- pacman -Q gives absolutely no output, and pacman -Syu erroneously reports that the system is up to date.
- When trying to install a package using pacman -S package, and it outputs a list of already satisfied dependencies.
- When testdb (part of pacman) reports database inconsistency.

Most likely, pacman's database of installed software, /var/lib/pacman/local, has been corrupted or deleted. While this is a serious problem, it can be restored by following the instructions below.

I know that all official packages (from core, extra, community, etc.) are signed so that all files should be safe, but I'm just paranoid.
What if the database was hacked?  Will this lead to installation of harmful software?

Sincerely,

Cylinder57

Last edited by Cylinder57 (2012-10-15 03:42:31)

Offline

#2 2012-10-15 03:43:44

jasonwryan
Forum & Wiki Admin
From: .nz
Registered: 2009-05-09
Posts: 19,085
Website

Re: What Are the Security Implications of not Completely Signing Database?


Arch + dwm   •   Mercurial repos  •   Github

Registered Linux User #482438

Online

#3 2012-10-15 04:04:55

Cylinder57
Member
Registered: 2012-04-30
Posts: 29

Re: What Are the Security Implications of not Completely Signing Database?

The following information implies that database signing doesn't protect the packages themselves.  Rather, one known thing it does is that database signing protects the user from the possibility that the Arch system cannot be updated.  This can be a big deal in a scenario like this:
-A particular package has a major security vulnerability and it needs to be updated to fix said vulnerability.
-Someone hacks the database to prevent said update, then exploits said vulnerability.

But then considering that all official packages are signed, harmful software should not be installed on my computer directly through pacman -S or an update through pacman -Syu.  Rather, incomplete database signing only exposes me to not being able to update to fix a vulnerability (and then someone exploits the vulnerability and I get hacked.)

Besides, what would database signing do to protect against my listed scenario?

From https://bbs.archlinux.org/viewtopic.php?pid=1111674 (as you suggested,)

Leonid.I said:

No, it hasn't been implemented yet. I don't really know about the plans, but personally I don't see much value in it. If a mirror is compromised and someone alters the *.db files, the worst what can happen is that you won't get your update -- not a big deal IMHO. Such attacks may be profitable against RHEL/SLES (when lack of updates may open critical servers to an intrusion) but not against arch.

Allan Mcrae said:

That is a bigger attack vector than altering packages...  Hold back an update to an already signed package that has had a major security vulnerability found in it.

Last edited by Cylinder57 (2012-10-15 04:12:01)

Offline

#4 2012-10-15 05:56:25

Allan
Developer
From: Brisbane, AU
Registered: 2007-06-09
Posts: 10,416
Website

Re: What Are the Security Implications of not Completely Signing Database?

Woo... this is my favorite attack vector because you do not need to exploit anything!  Holding back an entire database update would be noticed fairly quickly, but holding back an individual package update might not.  Signing the repository databases would stop that.  There is some talk happening about how this could be done and hopefully this will happen soonish...  as in months, not years...

But, the OP (also?) talks about the local package database on his computer.  That is not signed at all as there is no point.  If someone can modify that, then they can regenerate the signature, or just modify any other piece of software on your computer.

Offline

#5 2012-10-15 06:13:43

ngoonee
Forum Fellow
From: Between Thailand and Singapore
Registered: 2009-03-17
Posts: 6,839

Re: What Are the Security Implications of not Completely Signing Database?

Allan wrote:

But, the OP (also?) talks about the local package database on his computer.  That is not signed at all as there is no point.  If someone can modify that, then they can regenerate the signature, or just modify any other piece of software on your computer.

Out of curiosity, how vulnerable is package (and database) signing to the tried-and-true 'bribe-the-one-with-access' hack? Would more than one person need to be bribed or is one person sufficient to break the protection of signing?


Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.

Offline

#6 2012-10-15 06:28:24

Allan
Developer
From: Brisbane, AU
Registered: 2007-06-09
Posts: 10,416
Website

Re: What Are the Security Implications of not Completely Signing Database?

ngoonee wrote:

Out of curiosity, how vulnerable is package (and database) signing to the tried-and-true 'bribe-the-one-with-access' hack? Would more than one person need to be bribed or is one person sufficient to break the protection of signing?

To have you key trusted by the master keys would require multiple bribes.   Individual packages would require a single bribe...

I accept bribes readily.

Offline

#7 2012-10-15 07:12:47

ngoonee
Forum Fellow
From: Between Thailand and Singapore
Registered: 2009-03-17
Posts: 6,839

Re: What Are the Security Implications of not Completely Signing Database?

Allan wrote:
ngoonee wrote:

Out of curiosity, how vulnerable is package (and database) signing to the tried-and-true 'bribe-the-one-with-access' hack? Would more than one person need to be bribed or is one person sufficient to break the protection of signing?

To have you key trusted by the master keys would require multiple bribes.   Individual packages would require a single bribe...

And the database would probably be....?

Not sure you'd take my banana money, actually =p


Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.

Offline

#8 2012-10-15 17:01:19

Barrucadu
Member
From: York, England
Registered: 2008-03-30
Posts: 1,158
Website

Re: What Are the Security Implications of not Completely Signing Database?

AFAIK the repository databases aren't signed - there would be no point, as pacman rejects a package with a bad signature, so even if you were to alter the repo database and upload something nasty in place of an actual package nobody would fall victim to it.

Offline

#9 2012-10-15 17:07:43

karol
Archivist
Registered: 2009-05-06
Posts: 25,431

Re: What Are the Security Implications of not Completely Signing Database?

Offline

#10 2012-10-15 22:26:32

Allan
Developer
From: Brisbane, AU
Registered: 2007-06-09
Posts: 10,416
Website

Re: What Are the Security Implications of not Completely Signing Database?

Barrucadu wrote:

AFAIK the repository databases aren't signed - there would be no point, as pacman rejects a package with a bad signature, so even if you were to alter the repo database and upload something nasty in place of an actual package nobody would fall victim to it.

Except for all the explanations above about holding back a particular packages that has a known exploit....

Offline

#11 2012-10-18 05:44:43

Cylinder57
Member
Registered: 2012-04-30
Posts: 29

Re: What Are the Security Implications of not Completely Signing Database?

From this quote:

Allan wrote:

But, the OP (also?) talks about the local package database on his computer.  That is not signed at all as there is no point.  If someone can modify that, then they can regenerate the signature, or just modify any other piece of software on your computer.

Is it going to be easy for anyone other than the authorized user to modify the local package database?

And, are the following statements correct:

If the repository databases are modified, the hacker might be able to modify the packages on the server (Considering that if someone can modify the local package database, that person can modify any other piece of software on that particular computer.)
However, pacman won't let users from installing the modified packages (due to package signing,) unless at one person with access is bribed (at least, for an individual package.)

Offline

#12 2012-10-20 21:49:53

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,277

Re: What Are the Security Implications of not Completely Signing Database?

Cylinder57 wrote:

From this quote:

Allan wrote:

But, the OP (also?) talks about the local package database on his computer.  That is not signed at all as there is no point.  If someone can modify that, then they can regenerate the signature, or just modify any other piece of software on your computer.

Is it going to be easy for anyone other than the authorized user to modify the local package database?

Allan basically answered that with the quote above already as I understand it. Someone who has access to the installation, e.g. is able chrooting your PC via USB, is not held back by any ACLs. However, modifying the local database only makes limited sense because the packages are already installed. Pacman would only recheck, if you re-install a package. The only really relevant attack vector for the package database is
(1) installing an older package with a vulnerability,
(2) re-placing the up-to-date package sig in the local database with the older one and
(3) modifying the system, e.g. via pacman.conf excludes, to not update that.
then also re-installing would not create a sig-error and you get stuck with the bogus old package.
With a signed database this would not be possible. However, as Allan wrote earlier also with a signed database that criminal can manually install (totally leaving pacman & package cache) whatever it needs in this scenario. So, if you are -really- paranoid about that, you probably want to spend (a lot of configuring) time with something like the "aide" package.

Cylinder57 wrote:

And, are the following statements correct:

If the repository databases are modified, the hacker might be able to modify the packages on the server (Considering that if someone can modify the local package database, that person can modify any other piece of software on that particular computer.)
However, pacman won't let users from installing the modified packages (due to package signing,) unless at one person with access is bribed (at least, for an individual package.)

I don't know the intricacies of the server infrastructure - only saw they have great names :-), but I am pretty certain your statements assume that correctly. It is pretty unlikely that someone able to modify the central repository database fails at placing a bogus package for shipping with those access rights at this time. Yet it does no harm not to post any details of such a scenario here imo. In any case: A compromised mirror would be enough for that - and easier to achieve (hacked anywhere or e.g. in a non-democratic state). Plus you also answered it yourself. The keys are key for our safety there. Which keeps me hoping that no criminal lawnmover salesmen frequent the Brisbane area.

As you put up a thread about this, one question you can ask yourself is:

Have you always checked on updates new signatures keys which pacman asks about? If you ever pressed "accept/enter" without checking them out-of-band (e.g. the webserver), that compromised mirror database might have just created a "legitimate" key .. user error, but another attack vector the database signing would catch.

edit: Re-thinking the last paragraph just after posting, I now believe it would not be that easy as implied - simply because the bogus key is not trusted by one of the master keys. The pacman pgp trust model should catch that without database signing. At least it would if only the official repositories are activated, but that's a pre-requisite to the whole thread.

Last edited by Strike0 (2012-10-20 23:01:26)

Offline

Board footer

Powered by FluxBB