[HN Gopher] Unauthorized gem takeover for some gems
___________________________________________________________________
Unauthorized gem takeover for some gems
Author : mooreds
Score : 100 points
Date : 2022-05-07 20:48 UTC (2 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| 3ds wrote:
| I love the transparency! Even if no one was affected.
| thenerdhead wrote:
| 2020 - The year of secure supply chain.
|
| 2021 - THE year of secure supply chain.
|
| 2022 - THE YEAR OF SECURE SUPPLY CHAIN.
|
| Working in this general space, I can say that this is only going
| to get worse before it gets better. Many people are rallying
| behind pushing towards best security practices however.
|
| The dash requirement is interesting given it's somewhat of a
| pseudo prefix/namespace. Good that this was caught now and looks
| to not be exploited.
| d4mi3n wrote:
| 100% this. My CSIO has been harping on this since 2018. I've
| been harping on this since 2019. Security vendors are JUST now
| starting to provide SCA offerings (software composition
| analysis, for those not in infosec).
|
| Events like these don't surprise anyone who's been following
| this space. It's been a rough ride that will get rougher.
| Consider:
|
| 1. NPM just recently started enforcing 2FA for some packages.
| The NPM has yet to support mechanisms like package signing.
| Post install scripts are still a thing.
|
| 2. Rubygems does not support package signing.
|
| 3. Go dependency management is a hot mess.
|
| 4. Clojure dependency management is still a hot mess.
|
| Initiatives like Google's SLSA will help here, but there's a
| whole ecosystem of stuff across multiple technical ecosystems
| they need to mature, and fast.
| roblabla wrote:
| I agree with most of your post, but I do not understand this:
|
| > Post install scripts are still a thing
|
| I cannot find a situation where post-install script actually
| pose a security issue. I find that you'll always end up
| running the code you just installed on your machine (either
| through running unit tests, or running the actual code, or
| whatever). Hence, the only scenario where post-install
| scripts are a problem is:
|
| - You install deps on a machine that has access to security
| sensitive resources (think: your ssh keys)
|
| - BUT you do not run the resulting code on that machine.
|
| Are there really any use-case that satisfies those
| requirement where post-install scripts would actually result
| in a security issue?
| dec0dedab0de wrote:
| NPM for compiled frontend JavaScript. The resulting code
| only gets run in your users browsers, but the post install
| script could be run on your Jenkins/whatever box.
|
| In general, anyone who gathers dependencies ahead of time
| before deployment, so they can just copy them over. So most
| people deploying to multiple machines/containers.
| ilammy wrote:
| Maintainer scripts lower the bar for the attack.
|
| In order to get the code in scripts executed at a
| predictable time - you add it there and done. In order to
| get the code in the library executed on the build box, you
| have to add it somewhere that's actually used by the
| environment you want to attack. Scripts allow more coverage
| more easily.
|
| Plus, it's not unheard for people to run "npm" as root to
| run some scripts as root.
| larusso wrote:
| Given the fact that deployments can also include a npm
| install, depending how you package and run your code. But
| that is not the point. An attacker can run code in the name
| of the current user. He can download and inject other code
| on the host or the project. Which means that even if you
| bundle your code in a docker image and you never run the
| install on the same machine, some code could have been
| injected. And I personally see any attack being against a
| production system or development machine relevant.
| [deleted]
| intunderflow wrote:
| > An audit of gem changes for the last 18 months did not find any
| examples of this vulnerability being used in a malicious way. A
| deeper audit for any possible use of this exploit is ongoing, and
| we will update this advisory once it is complete.
|
| How would folks do that with strong enough guarantees? Surely
| they can't review every gem change by hand?
| hkolk wrote:
| From what I understand, they only have to review/audit the
| times a gem was yanked, to see if it was a legitimate action. I
| reckon there is a lot less occurrences
| dragonwriter wrote:
| > Surely they can't review every gem change by hand?
|
| Given the nature of the vulnerability, they only have to audit
| yanks of gems with a dash in the name that were either not
| updated in the 100 days prior to the yank or created 30 or
| fewer days before the yank, which is a much smaller universe
| than "all gem changes".
| mrtweetyhack wrote:
| brasic wrote:
| This test seems to be a good example of the vulnerability:
| https://github.com/rubygems/rubygems.org/commit/58c755a7a62a...
| AviationAtom wrote:
| This goes to show: no matter how great your network defenses, you
| have to be prepared for WHEN you get breached.
|
| Supply chain vulnerabilities are becoming a greater problem by
| the day. I think Solarwinds demonstrated this greatly.
___________________________________________________________________
(page generated 2022-05-07 23:00 UTC)