Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sigstore - A new standard for signing, verifying and protecting software

sigstore.dev

Post reply on HN
Print view View original

21–28 of 28 posts

Re: Sigstore - A new standard for signing, verifying and protecting software

#21

Post by MattPalmer1086 »

netman21 wrote: post #6

This is all great. Signing and verifying software is important. But it is woefully inadequate in a post Solarwinds-Notpetya-FLAME world. We need something that allows an organization to verify that code has not been maliciously tampered with. I can only think of a combination of sandboxing to detect detonation and C&C comms, and reverse engineering to compare the updates with previous versions. The last is problemati…

NotPetya delivered itself via an official update, but then did nothing for a month. It was triggered using a response to a standard update check message. Seconds later it was compromising everything in sight.

My point being that sandboxing, etc. would not have helped you at all.

Re: Sigstore - A new standard for signing, verifying and protecting software

#22

Post by dlor »

dane-pgp wrote: post #15
dlor wrote: post #7

Sigstore maintainer here. I'll try to answer questions!

Are there plans to integrate it with something like Crev[0] for tying trusted code/security reviews to the binary artefacts? I suppose the people you trust to audit some code will likely not be the same people you trust to do build verification for you, but it might be nice to manage those trust relationships in a single UI/config. [0] https://github.com/crev-dev/crev

We use the generic in-toto Attestation data model which could capture crev style reviews, but there are no other concrete plans that I'm aware of.

To be honest, crev is pretty elegant but I find manual code review like this to be pretty ineffective in stopping attacks.

Re: Sigstore - A new standard for signing, verifying and protecting software

#23

Post by pineconewarrior »

vquemener wrote: post #18
pineconewarrior wrote: post #14

I know this might seem random and a bit of a big ask, but would you consider publishing some of your website's front-end bits on your github, too? It's a really nice job and seems highly optimized and I am curious about how it was made and delivered. In other words, kudos?

Is that what you're looking for? https://github.com/sigstore/sigstore-website

Yoo thanks! That is indeed what I was looking for.

(I am pretty bad at finding things after a long days work of development)

Re: Sigstore - A new standard for signing, verifying and protecting software

#24

Post by dane-pgp »

_8j50 wrote: post #20

Two hard facts are: 1) You need to get Microsoft onboard 2) It doesn't mean much without developer ID verification and financial cost Short of those two, it just becomes a way to maintain walled gardens by app stores or a means of replacing opensource gpg package signing with centralized web-of-trust? I guess the cosign part means some decentralization like GPG ? I am not bashing it, it can help with Supply chain att…

> 1) You need to get Microsoft onboard

Given the work they are (ironically) doing on open source supply chain security[0], it would be embarrassing if they didn't end up implementing something similar for apps in the Windows Store.

> 2) It doesn't mean much without developer ID verification and financial cost

Even without verifying an ID, tools will be able to accumulate trust in long-standing identities, and flag when you are installing a package made by an identity that no one has ever heard of (which could be a sure sign of a typosquatting attack[1], for example).

You're right, though, that in some reductionist sense, "all we're doing" is moving the trust problem from binaries to (source code to reviews/audits to) pseudonymous digital identities. Closing the gap between those identities and the legal system is a cultural/political question that needs to be thought about separately, but I do think that having a decentralised web-of-trust system would greatly increase the cost for attackers and make attacks significantly less frequent.

[0] https://news.ycombinator.com/item?id=27930594

[1] https://www.theregister.com/2017/08/02/typosquatting_npm/

Re: Sigstore - A new standard for signing, verifying and protecting software

#25

Post by dane-pgp »

dlor wrote: post #22
dane-pgp wrote: post #15

Earlier quoted context omitted.

Are there plans to integrate it with something like Crev[0] for tying trusted code/security reviews to the binary artefacts? I suppose the people you trust to audit some code will likely not be the same people you trust to do build verification for you, but it might be nice to manage those trust relationships in a single UI/config. [0] https://github.com/crev-dev/crev

We use the generic in-toto Attestation data model which could capture crev style reviews, but there are no other concrete plans that I'm aware of. To be honest, crev is pretty elegant but I find manual code review like this to be pretty ineffective in stopping attacks.

Perhaps we need better tools for helping manual code review. Detecting high-entropy strings would be a useful semi-automated check to find obfuscated code and accidentally-committed secret keys.

I think there should also be a culture of ensuring that a new patch release of some software passes the acceptance tests of the previous patch release (without changing or removing the tests).

A similar test for linting rules should also help (especially if those rules are designed to prevent Unicode homoglyph attacks), and a check for new uses of dangerous APIs like filesystem or network access would assist reviewers too.

Of course there is almost unlimited potential for underhanded code, if an attacker is skilled and patient enough to carefully introduce subtle bugs over time, but I think that a meaningful number of attacks could be avoided with these measures in place.

Re: Sigstore - A new standard for signing, verifying and protecting software

#26

Post by WhatIsDukkha »

dlor wrote: post #22
dane-pgp wrote: post #15

Earlier quoted context omitted.

Are there plans to integrate it with something like Crev[0] for tying trusted code/security reviews to the binary artefacts? I suppose the people you trust to audit some code will likely not be the same people you trust to do build verification for you, but it might be nice to manage those trust relationships in a single UI/config. [0] https://github.com/crev-dev/crev

We use the generic in-toto Attestation data model which could capture crev style reviews, but there are no other concrete plans that I'm aware of. To be honest, crev is pretty elegant but I find manual code review like this to be pretty ineffective in stopping attacks.

There is nothing limiting crev manual code review is there?

An ecosystem of useful bots would seem like a natural addition to it.

Re: Sigstore - A new standard for signing, verifying and protecting software

#27

Post by varunsharma07 »

MattPalmer1086 wrote: post #21
netman21 wrote: post #6

This is all great. Signing and verifying software is important. But it is woefully inadequate in a post Solarwinds-Notpetya-FLAME world. We need something that allows an organization to verify that code has not been maliciously tampered with. I can only think of a combination of sandboxing to detect detonation and C&C comms, and reverse engineering to compare the updates with previous versions. The last is problemati…

NotPetya delivered itself via an official update, but then did nothing for a month. It was triggered using a response to a standard update check message. Seconds later it was compromising everything in sight. My point being that sandboxing, etc. would not have helped you at all.

If there was a way to know the behavior of NotPetya and realize that it has code to do things that M.E.Doc (the tax preparation program that was backdoored) was not supposed to do, that could have been used as a way to reject its installation. We are far away from being able to do such analysis at scale, but my point is that it is ultimately the behavior of software that makes it malicious or not.

Re: Sigstore - A new standard for signing, verifying and protecting software

#28

Post by MattPalmer1086 »

varunsharma07 wrote: post #27
MattPalmer1086 wrote: post #21

Earlier quoted context omitted.

NotPetya delivered itself via an official update, but then did nothing for a month. It was triggered using a response to a standard update check message. Seconds later it was compromising everything in sight. My point being that sandboxing, etc. would not have helped you at all.

If there was a way to know the behavior of NotPetya and realize that it has code to do things that M.E.Doc (the tax preparation program that was backdoored) was not supposed to do, that could have been used as a way to reject its installation. We are far away from being able to do such analysis at scale, but my point is that it is ultimately the behavior of software that makes it malicious or not.

I don't think that is possible for any software that isn't completely trivial. It's related to the halting problem.

If you are relying on detecting behaviour, then you have to run it.

NotPetya did nothing abnormal until it was triggered by the response to a normal network call. The first opportunity to block it would be when it was triggered.

So you could not have blocked the install by this method.

You can detect likely malicious behavior and contain those systems, which would have helped.

Post reply on HN