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

A GitHub Issue Title Compromised 4k Developer Machines

grith.ai

Post reply on HN
Print view View original

191–200 of 216 posts

Re: A GitHub Issue Title Compromised 4k Developer Machines

#191

Post by drewda »

inezk wrote: post #183
drewda wrote: post #182

FWIW, the best way to get your website on Hacker News is to write a content-marketing blog post about someone else's work. Don't get me wrong. This post is an interesting read. But the company publishing it appears to have nothing to do with the exploit or the people who discovered or patched it. I tip my hat at their successfully marketing :)

You mean.. like a newspaper?

No. A newspaper is in the business of selling you content (or advertising alongside content)

grith.ai appears to be in the business of guiding you click a "request early access" button so they can eventually sell you software (or so they can pitch seed investors on the length of their list of prospects)

Again, I'm not criticizing. Just pointing out a pattern that's becoming pretty common on HN, especially for stories about vulnerabilities written up by companies selling cybersecurity solutions or services.

Re: A GitHub Issue Title Compromised 4k Developer Machines

#192

Post by riquito »

inezk wrote: post #183
drewda wrote: post #182

FWIW, the best way to get your website on Hacker News is to write a content-marketing blog post about someone else's work. Don't get me wrong. This post is an interesting read. But the company publishing it appears to have nothing to do with the exploit or the people who discovered or patched it. I tip my hat at their successfully marketing :)

You mean.. like a newspaper?

A newspaper that sells you a product to allegedly fix/avoid the issue in the article

Re: A GitHub Issue Title Compromised 4k Developer Machines

#193

Post by WorldMaker »

simlevesque wrote: post #34

What can Github do about this ?

I think there are two big takeaways that GitHub has the power to implement:

1) actions/cache could default to workflow-isolated caches and require opt-in to shared caches between workflows, forcing workflow writers to understand the risks when they want to take them. This is a relatively "traditional" CI system safety design and perhaps something of an oversight.

2) GitHub needs a stronger defense against fork "commit-washing" than a banner in the UI because the greatest risks are places where the UI isn't visible. Right now GitHub will allow you to check out commits from forks as if they are commits in the main repository. This is a part of how GitHub works, all forks are stored in essentially the same repo under the hood for storage and computation benefits. But it's also a key to too many exploits that `action: actions/checkout@someCommitHash` might come from any fork of `actions/checkout` not just the GitHub official repo and any use of `npm install github:microsoft/vscode#someCommitHash` might come from any fork of `microsoft/vscode`. If a developer follows those commit links into the GitHub UI there's a warning banner those commits are from a fork, but you don't see that in a workflow YAML today and npm has no warnings if it happens. Even though this is a deep part of how GitHub works under the hood, it probably shouldn't be allowed to be this visible from outside of GitHub's walls and more security tools should prevent it both internal to GitHub and external to it (with npm being sort of both in that npm's developers are under GitHub's roof, too).

Re: A GitHub Issue Title Compromised 4k Developer Machines

#196

Post by pvillano »

Ukv wrote: post #147
yread wrote: post #106

> Cline’s (now removed) issue triage workflow ran on the issues event and configured the claude-code action with allowed_non_write_users: "*", meaning anyone with a GitHub account can trigger it simply by opening an issue. Combined with --allowedTools "Bash,Read,Write,Edit,Glob,Grep,WebFetch,WebSearch", this gave Claude arbitrary code execution within default-branch workflow. Has everyone lost their minds? AI agent w…

> AI agent with full rights running on untrusted input in your repo? Boundary was meant to be that the workflow only had read-only access to the repository: > # - contents: read -> Claude can read the codebase but CANNOT write/push any code > [...] > # This ensures that even if a malicious user attempts prompt injection via issue content, > # Claude cannot modify repository code, create branches, or open PRs. https:/…

I put 50% of the blame on GitHub, and 50% of the blame on postinstall. A cache is expected to have no observable effects other than increased storage usage and decreased download time. A package cache must not be able to inject malware.

GitHub could

1. Call the Actions Cache the "Actions key-value database that can be written to by any workflow and breaks the idempotence of your builds" (unlikely)

2. Disable install scripts (unlikely)

3. Make an individually configured package cache unnecessary by caching HTTP requests to package repositories [^1]

4. Make the actions cache versioned as if it were a folder in the repo itself. This way, it can still be an arbitrary build + package cache, but modifications from one branch can't change the behavior of workflows on another branch.

[1]: Assuming most of the work saved is downloading the packages.

Re: A GitHub Issue Title Compromised 4k Developer Machines

#197

Post by QuercusMax »

zbentley wrote: post #169
brookst wrote: post #164

Earlier quoted context omitted.

SQL I’m injection is a great parallel. Pervasive, easy to fix individual instances, hard to fix the patterns, and people still accidentally create vulns decades later.

This is substantially worse. SQL injection still happens a lot, it’s true, but the fix when it does is always the same: SQL clients have an ironclad way to differentiate instructions from data; you just have to use it. LLMs do not have that, yet. If an LLM can take privileged actions, there’s no deterministic, ironclad way to indicate “this input is untrusted, treat it as data and not instructions”. Sternly worded en…

It's like the evil twin of "code is data"

Re: A GitHub Issue Title Compromised 4k Developer Machines

#198

Post by [deleted] »

nstart wrote: post #125
yread wrote: post #106

> Cline’s (now removed) issue triage workflow ran on the issues event and configured the claude-code action with allowed_non_write_users: "*", meaning anyone with a GitHub account can trigger it simply by opening an issue. Combined with --allowedTools "Bash,Read,Write,Edit,Glob,Grep,WebFetch,WebSearch", this gave Claude arbitrary code execution within default-branch workflow. Has everyone lost their minds? AI agent w…

This is how people intend to run open claw instances too. Some folks are trying to add automated bug report creation by pointing agents at a company's social media mentions. I personally think it's crazy. I'm currently assisting in developing AI policies at work. As a proof of concept, I sent an email from a personal mail address whose content was a lot of angry words threatening contract cancellation and legal actio…

[deleted]

Re: A GitHub Issue Title Compromised 4k Developer Machines

#199

Post by forrestthewoods »

stavros wrote: post #120
forrestthewoods wrote: post #108

Earlier quoted context omitted.

I’ll do you one better. I refuse to install npm or anything like npm. Keep that bloated garbage off my machine plz. I guaranteed way for me to NOT try a piece of software is if the first setup step is “npm install…”

Sure, but throwing the baby out with the bathwater tends to not be a solution that people will find clever or reasonable.

I guess it’s because I do C++ and robotics. But npm is just not part of my world. The only time I come across it is when someone gets real lazy and doesn’t ship a proper single exe distributable. Claude Code and Codex CLIs were both naughty on initial release. But are now a single file distributable the way the lord intended.

Re: A GitHub Issue Title Compromised 4k Developer Machines

#200

Post by phendrenad2 »

Orygin wrote: post #150
hunterpayne wrote: post #73

Earlier quoted context omitted.

Create registry entries in a config file for all local printers found in the existing OS configuration. Remember that the installer runs with privileges that the application won't normally have. So anytime you have to use those privileges you don't do it at runtime, you do it at install time. And this requires the hook.

If I install a package and it starts scanning my local printers, it get immediately removed and the author put on a blacklist. No other ecosystem is that dense, none of them require such stupid and dangerous flows to work.

Yeah I'm not sure hunterpayne isn't an AI that did some research to answer my question and immediately found a printer-based hack in an npm package.
Post reply on HN