[arch-general] Severity of Failed checksum for PKGBUILD

[Daniel Micay]

On 20/02/15 10:22 AM, Florian Pelz wrote:
> On 02/20/2015 03:59 PM, Daniel Micay wrote:
>> The vast majority of users make use of the binary packages and the 
>> checksums do absolutely nothing to secure the main attack vector
>> which is a compromise of the sources downloaded by the packager. It
>> is only relevant to the tiny minority of people building a package
>> with ABS.
>>
>> The more meaningful compromise needs to happen to the actual
>> package in the repositories. A compromise of the server hosting the
>> sources is the most likely way for this to happen. HTTPS can't do
>> anything to defend against it. HTTPS can only defend against a MITM
>> attack on a specific downstream packager.
>>
> 
> The difference is that if certain government organizations infiltrate
> the Arch servers or upstream, they break everyone's security. They may
> be less likely to do that compared to breaking just yours.

Compromising the Arch servers doesn't provide the ability to produce
valid signed packages, and compromising the upstream servers doesn't
provide the ability to produce valid signed sources. You would need to
compromise the machine used by the developer and gain access to their
private key and whatever else you're after. There's little that can be
done once that is accomplished...

>> There is support for validating sources with GPG signatures, which
>> is a complete solution to this issue. If you care, then file issues
>> for any packages that aren't using the upstream signatures yet, and
>> complain to upstream if they aren't signing the releases.
>>
> 
> This certainly is the right way to go, but I don't think enough
> upstream projects care to make it a viable option for personal
> computers today. PKGBUILD checksums provide less security, but they do
> provide some.

Lots of our packages already use them, and that's only a fraction of the
ones that could be using them. Just look at how long the rebuild list
for pacman 4.2's improved signing was or look at the Arch package source
tree yourself.

PKGBUILD checksums provide *zero*, yes *zero* security for the case that
matters most, which is the build done by the packager. It does provide
the ability for other people to verify that a MITM attack was not used
to target a specific packager... but that is far, far less likely than a
compromise of the sources on the upstream server and it can't do
anything about that.

Providing an audit trail is distinct from providing security, and there
is more than one way to do that. Signed source tarballs would tackle the
same thing while avoiding the problem of upstream clobbering the sources
or the sources simply becoming unavailable. Many upstreams don't
continue hosting sources for older versions...

Clobbering the sources is common enough that a validation failure is
only a bit suspicious and likely isn't even going to be investigated.
That is the reality of the hashes - they are near useless.

>> On 20/02/15 09:41 AM, Florian Pelz wrote:
>>> I'm not sure if downloads over the git:// protocol are actually 
>>> verified, because the transfer is definitely not secure. I do
>>> hope so.
>>
>> Git's read-only protocol is not authenticated. It supports SSH and
>> HTTPS which do have two different forms of authentication, both of
>> which are very flawed. Signed tags make a lot more sense, and you
>> shouldn't be using code from development branches if you care a lot
>> about robustness and security, since
>>
> 
> It is not authenticated, but I care about checksums. (Authentication
> would be even better because it ensures others don't know what
> software I am running -- but that is too much to ask.) I don't see why
> SSH and HTTPS are flawed, other than a distrust in certificate
> authorities.

It can also only protect against a MITM attack against upstream and
downstream, which as I already pointed out is not as likely as
compromising the sources on the upstream server - and it can't do
anything about that.

Trust in certificate authorities is trust in many corporations and
governments around the world. It's trust in tends of thousands of
individuals with the ability to sign whatever they want. An attacker
with the ability to perform a targeted MITM attack on a specific Arch
developer likely has the ability to sign whatever they want.

Compromising the upstream sources in a subtle way when they upload the
next release will be nearly impossible to detect - only the upstream
developer who uploaded the source tarball

Git's SSH protocol implies having SSH access to at least a Git shell on
the server and isn't ever used for read access in practice. SSH has a
simple, sane whitelist-based model based on a public key / IP pair. It
will warn whenever the server IP changes which is not at all uncommon
and means that nearly every developer has learned to ignore it.

> I still hope that git:// downloads use checksums. I'm not sure.

They can do it if they're fetching a specific version...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20150220/abad63b0/attachment.asc>