Perhaps it’s time to plan for supply chain attacks before crystal is targetted.
Todo items:
- Set a security policy that details how to report vulnerabilities.
- TBD
2 Likes
As a security guy (blue team) I am supporting this effort!
The Crystal team does not run any infrastructure for the ecosystem. Shards is designed as a decentral package manager. As such there’s no place to enforce any such policy, each project has and should set their own. Of course we can think about providing recommendations or templates for this in some way or another, possibly as part of crystal init. But let’s not pretend like this is something we can reasonably enforce.
This lack of central infrastructure also means that we cannot build up a central emergency response team that could reasonably act. It could neither remove any vulnerable software from the ecosystem nor directly release patched versions.
Something we can do to help the ecosystem is however to provide a central collection point for these kinds of reports, something akin to for example https://rubysec.com/ (this used to provide a subscribable feed of advisories). This does not necessarily need to be an effort by the core Crystal team, but an easy start here could be a moderated category in this forum or a mailing list, where project owners can submit advisories, CVE entries etc. for their projects that users can subscribe to. Of course that doesn’t scale as the ecosystem grows, but might be good enough for now.
Now the second part of exploration here, that we probably should split into its own thread in case we decide to research this deeper, is code signing. In principle it should be fairly easy to validate the signature of for example git tags while installing dependencies with shards. But here again the lack of central infrastructure comes to bite us. Managing trust anchors in a decentral system is quite the rabbit hole, trust me. Especially in bigger projects you don’t want to bind being able to release to a single key or person. Key rotation also becomes a mess. Having to manually maintain the current signing keys of all dependencies will make people just not use the feature. In my ideal world we would just put keys into a DNSSEC signed zone, so you could add a signed dependency by something like
dependencies:
foo:
github: jhass/crystal-foo
signers: shardkeys.jhass.eu
which would then fetch valid keys or key fingerprints or so via a TXT record of that zone. But facing reality, the state of DNSSEC in resolvers, home routers and people’s minds is just too dire. So I don’t have good ideas here.
4 Likes
Shards is designed as a decentral package manager.
Nothing precludes shards from checking a central advisory list for malware. There’a a lot shards can do like locking git hashes in shard.lock that hasn’t been mentioned here (yet).
This lack of central infrastructure also means that we cannot build up a central emergency response team that could reasonably act.
False. See below.
It could neither remove any vulnerable software from the ecosystem nor directly release patched versions.
True, except shards could provide links to advisories, recommended courses of action, new repositories with patched software and more.
@jhass we should respond only to the Standard Library and compiler vulnerabilities.
Any shards can be scanned in the way how npm audit works and notify authors about found vulnerabilities. Until vulnerability is resolved it should show the message in shards install that specific shard has vulnerability.
1 Like
But then it’s no longer fully decentralized. 
Not say it would not be worth considering, just that it has implications like adding a single point of failure.
The advisory list could be published either on github for the exact same single point of failure as most shard repos or using any number of distributed or mirrored data distribution services.
Except people trying to compile on an offline machine…
What if we made some enhancement to https://shardbox.org/ that would also provide malware information on shards. At least then we’d have the information available in what is already a community driven effort. Then a new tool (not shards) could be created to validate installed shards.
The use of such a tool should be encouraged and well documented, perhaps even referenced on the crystal website, but I think this needs to be a community effort instead of a core team effort.
4 Likes
Agreed, you can’t expect the Crystal devs to protect us from ourselves.
Just like to point out a few things before we rush into writing shard scanning code. The attack described in the report isn’t a typical supply-chain attack (where legitimate and trusted libraries are compromised), but relied on Typo-Squating to fool users into installing the malicious libraries. Since shards are decentralized, the hosting provider (GitHub, Bitbucket, GitLab, etc) should be our first line of defense against malcious Typo-Squating. In fact, GitHub already scans dependency files for vulnerabilities, so they could in theory also scan for known bad shard dependencies that they’ve removed in the past. If we wanted to build our own malicious dependency scanner into shards, then we could maintain a list of bad shards (host, user/repo). If we wanted to integrating our own security advisory scanner into shards, then ruby-advisory-db and bundler-audit would be good projects to gain inspiration from.
1 Like
When offline or if the vulnerability database is unavailable then it could just put out a warning and otherwise continue like normal. For situations where you don’t want to proceed without checking dependencies for vulnerabilities, you could just have a flag that turns the warning into a failure.
4 Likes