Open source package with 1 million monthly downloads stole user credentials

If you're one of millions using element-data, it's time to check for compromise.

See full article...

 

[Hypatia]

On Friday, unknown attackers exploited the vulnerability to push a new version of element-data, a command-line interface that helps users monitor performance and anomalies in machine-learning systems.

Tired of struggling with the alignment problem with “AI”? Just wait until you run into the alignment problem between actual people and other actual people.

 

[chekk]

Tired of struggling with the alignment problem with “AI”? Just wait until you run into the alignment problem between actual people and other actual people.

A colleague complained once about the technology stack we were using making his job difficult. I was surprised and responded "the technology is the easy part, at least it's deterministic; other people are the hard part."

 

[markgo]

The paranoia of larger corporations controls on use of external software is starting to look justified.

Developers of all sizes would be wise to take a far more critical look at whether, when, and how to accept upgrades of external components.

For one thing, restricting packages to versions that have been available for 30 days or other reasonable bake time (unless there are critical security fixes) gives quite a bit of protection from watering hole attacks by letting others be the guinea pigs.

It would be lovely if package update tools supported this directly.

But regardless of policy, each update should be individually examined and “update all package” actions need to die.

Yes, this takes time and effort. But attacks like these are why we can’t have nice things.

 

[quamquam quid loquor]

The jokes write themselves.

 

[tgeeks]

The security incident report says: "An attacker exploited a script-injection vulnerability in one of our GitHub Actions workflows to publish it."

Is the script-injection vuln only present due to how the developers configured GitHub Actions or is this something that also needs to be mitigated by GitHub?

Forgive me if this is a stupid question - I have a very shallow understanding of and limited hands-on experience with GitHub.

 

[bone_collector]

restricting packages to versions that have been available for 30 days or other reasonable bake time (unless there are critical security fixes) gives quite a bit of protection from watering hole attacks by letting others be the guinea pigs.

It would be lovely if package update tools supported this directly.

You know what’s really frustrating? When your package manager DOES support this feature, but the proxy service your org has put in front of the public package repository for “security” does not proxy package metadata, such as package upload dates, breaking this feature for everyone. Looking at you, Sonatype Nexus!

 

[Fred Duck]

HD Moore, a hacker with more than four decades of experience and the founder and CEO of runZero, said that user-developed repository workflows, such as GitHub actions, are notorious for hosting vulnerabilities.

Odd. If a technology is so dangerous, why do they insist on maintaining the functionality instead of removing it? At least that attitude isn't prevalent in software.

Sam AItman has entered the chat

For one thing, restricting packages to versions that have been available for 30 days or other reasonable bake time (unless there are critical security fixes) gives quite a bit of protection from watering hole attacks by letting others be the guinea pigs.

So then in future, malicious directors will simply mark it as containing a critical security fix...

 

[Secondfloor]

The security incident report says: "An attacker exploited a script-injection vulnerability in one of our GitHub Actions workflows to publish it."

Is the script-injection vuln only present due to how the developers configured GitHub Actions or is this something that also needs to be mitigated by GitHub?

Forgive me if this is a stupid question - I have a very shallow understanding of and limited hands-on experience with GitHub.

Yes, it was a vulnerability in the script they wrote, nothing about GitHub itself.

 

[taxythingy]

It’s a “a major problem for open source projects with open repos,” he said. “It’s really hard to not accidentally create dangerous workflows that can be exploited by an attacker’s pull request.”


He said this package can be used to check for such vulnerabilities.

Cool, so the answer to some security issues with packages is to install a package?

 

[Secondfloor]

Cool, so the answer to some security issues with packages is to install a package?

Not sure if serious, but yes.

 

[adespoton]

The paranoia of larger corporations controls on use of external software is starting to look justified.

Developers of all sizes would be wise to take a far more critical look at whether, when, and how to accept upgrades of external components.

For one thing, restricting packages to versions that have been available for 30 days or other reasonable bake time (unless there are critical security fixes) gives quite a bit of protection from watering hole attacks by letting others be the guinea pigs.

It would be lovely if package update tools supported this directly.

But regardless of policy, each update should be individually examined and “update all package” actions need to die.

Yes, this takes time and effort. But attacks like these are why we can’t have nice things.

That definitely eliminates the low hanging fruit, but we've seen a few situations now where OSS projects were targeted with backdoors that are a) non-obvious and b) attacker activated. This means that package updates in isolation would look perfectly fine in review, but a set of consecutive updates, or updates across a string of dependencies, build out to create a vulnerability that can be leveraged to target a small handful of selected targets, without tipping the attackers' hand on a global scale.

As such, not only is having a cooling time for package updates important (sometimes you'd want to shorten the time and increase the amount of effort spent vetting the package, if it's fixing a critical vulnerability), but also performing runtime testing and fuzzing within a sandboxed environment before pinning the new version and letting it run loose on production systems.

 

[nimble]

The paranoia of larger corporations controls on use of external software is starting to look justified.

Developers of all sizes would be wise to take a far more critical look at whether, when, and how to accept upgrades of external components.

For one thing, restricting packages to versions that have been available for 30 days or other reasonable bake time (unless there are critical security fixes) gives quite a bit of protection from watering hole attacks by letting others be the guinea pigs.

It would be lovely if package update tools supported this directly.

But regardless of policy, each update should be individually examined and “update all package” actions need to die.

Yes, this takes time and effort. But attacks like these are why we can’t have nice things.

Time and effort, you say? Just use that amazing Copilot thing that we've bought for you!

 

[markgo]

So then in future, malicious directors will simply mark it as containing a critical security fix...

I fear this is true. But it’s also likely to cause other maintainers and users to take a closer look at the actual changes, so it’s a bit of a mixed bag for the attacker.

 

[chekk]

Time and effort, you say? Just use that amazing Copilot thing that we've bought for you!

"Don't wait for third parties to steal your data, blow it up yourself in record time using AI!"
Ars forum post
Or Tom's Hardware direct

 

[Thunderforge8]

For one thing, restricting packages to versions that have been available for 30 days or other reasonable bake time (unless there are critical security fixes) gives quite a bit of protection from watering hole attacks by letting others be the guinea pigs.

Note going to fly in a lot of workplaces, especially if it fixes CVEs.

Recently we were using a library that disclosed a new High CVE. Dependabot said the new version wasn't published properly (something missing with signing, I think). A GitHub issue on the repo had the developer say he cut corners to get the CVE fixed faster, and was disinclined to publish a new fixed version because it was a lot of work.

I suggested we not upgrade on principle because it had signs of a supply chain attack (even though I was sure it was just the dev being lazy). Plus, I read the CVE and didn't think we were vulnerable (and might have even been a slop issue). But I got overruled because the company decided that "security dashboard must be green" was more important.

Lesson to hackers: fix a CVE while you poison the supply chain and box-ticking companies will insist their employees install it.

 

[Travis Griggs]

Quit making mashup software. It was naive from day one. Every dependency you engage with is a loan you take out. It had better pretty be damn well worth it to stay in your stack.

Somehow, for too many software developers, software creation became like managers who pad their egos using head count. It got cool to bring as many dependencies under your umbrella as possible. Adds gravitas and all that to your product.

Do more with less.

 

[Hypatia]

A colleague complained once about the technology stack we were using making his job difficult. I was surprised and responded "the technology is the easy part, at least it's deterministic; other people are the hard part."

That’s similar to what I tell clients: The science is easy. The people, however…

*edited for spelling

 

[TaxiZaphod]

The subtitle and first instance in the story call this "element-data" but the link goes to "elementary-data". I suspect the distinction is important, but to be fair, I know nothing about this.

 

[ferdnyc]

The subtitle and first instance in the story call this "element-data" but the link goes to "elementary-data". I suspect the distinction is important, but to be fair, I know nothing about this.

The distinction is pretty important if you actually want to correctly identify the package in question, which is called elementary-data. I don't know where "element-data" came from, but it would be good if Ars fixed that.

 

[GFKBill]

Quit making mashup software. It was naive from day one. Every dependency you engage with is a loan you take out. It had better pretty be damn well worth it to stay in your stack.

Somehow, for too many software developers, software creation became like managers who pad their egos using head count. It got cool to bring as many dependencies under your umbrella as possible. Adds gravitas and all that to your product.

Do more with less.

Yeah, reinvent that wheel! Rolling your own is more secure and there's lots of money in ...

Wait, neither of those is true? Huh. Never mind, as you were Devs!