Sabitlenmiş Tweet
New blog post. This is a fun one: wts.dev/posts/chatgpt-…
thanks to @theo for connecting me with the OpenAI team, and thanks to @zemnmez for working with me on this (even though it wasn't patched)
English
Watch This Space
1.6K posts
Watch This Space
@wtsdev
Watch This Space: A security research blog.
The Interwebs Katılım Ağustos 2024
524 Takip Edilen596 Takipçiler
Had a similar thing with Opus 4.6 - a macOS SIP bypass that is still under embargo.
You still need to monitor a model's output, especially for non-trivial things.
chompie@chompie1337
Claude helped me with this bug too but in a different way... Tried to gaslight me saying it wasn’t ~exploitable in practice~ and I got obsessed with proving it wrong 😩
English
@yo_yo_yo_jbo Of course, yeah! I've just never heard the term "embargo" used to refer to the Apple Security Bounty program terms. Looking forward to if you write about it post-patch!
English
@ryanaraine If (and, honestly, probably *when*) they (or anyone with AI) find a deep logic bug in macOS is the moment I will be fully convinced. A bit biased, maybe, but those are the bugs I've been able to find myself, so I know what goes into finding them.
English
> We didn’t build the chain alone. Mythos Preview helped[...]
This is still memory corruption, and I might still be holding onto logic bugs as less reachable by AI. But I'm growing less and less sure.
Great work! Scary work, but great work!
Calif@calif_io
Early this week, we had a meeting at Apple Park in Cupertino. While there, we also shared with Apple our latest vulnerability research report: the first public macOS kernel memory corruption exploit on M5 silicon, surviving MIE. It was laser printed, in honor of our hacker friends. Full story: open.substack.com/pub/calif/p/fi…
English
@daradoescode iirc, @theo has called out this video more than once on stream: youtu.be/7fGB-hjc2Gc?t=…
YouTube
English
@OrdinaryInds I feel like handed-ness world play a role here, but maybe not.
English
It’s often a negative action. It intentionally requires more effort to prevent speedy clicks. This is extremely well studied.
Peter Piekarczyk (🥧🚗🐥)@peterpme
apple just updated their human interface guidelines and double downed on the top left close button for an iphone 17 pro max crazy stuff. the folks that decide these things must be giants
English
@yilmazcanyigit Congrats! This was something I speculated might be possible, but never investigated it fully. Will you be doing a write-up?
English
Apple, güvenlik güncellemesiyle raporladığım bir sorunu düzeltti ve ismimi 170’dan fazla kez onur listesine ekledi.
Safari’den indirilen, Gatekeeper karantinasındaki bir imaj dosyasındaki kötü amaçlı yazılım; tek tıklamayla karantinayı aşıp rastgele kod çalıştırabiliyordu.
Türkçe
@crutchcorn Ok, that makes sense! Funnily enough, I actually just recently reading about the dangers of `pull_request_target`. Glad you've excised it from your pipelines!
English
@wtsdev Apologies; yes. We already had that enabled. That rule was being bypassed by `pull_request_target`, which AFAIK has no similar rule.
English
In many of my comms about the TanStack attack, I mentioned a list we published to keep us accountable.
But I only realized that this was removed between the draft I saw and the public publication.
We'll have this all in a blog post very soon, but 🧵 on what we're fixing
English
@crutchcorn Is it feasible for you to require a maintainer to click a button to let CI jobs run on a PR instead of auto-running them?
English
Hopefully this shows that we're taking this incident very seriously and are working hard on adding resilience measures to fix our processes.
Please don't hesitate to let us know if there's more you think we can be doing. We're listening.
English
@wtsdev Nope! And a cache hit is arbitrary file write on the runner by design.
(Extracted with tar -P). Replace a script that always runs = arbitrary code execution.
English
PSA - GitHub is planning on hardening Actions Caching github.com/orgs/community…
Please chime in to share how the new cache model should be secure by default instead of requiring opting-in to secure settings!
Short term discomfort > this supply chain attack agony.
English
@roerohan Naming the service the exact same on both platforms implies it was either a detail-oriented human or slightly over-engineering AI who wrote it. And I don't like either possiblity.
English
If you found the malicious service, here's how to remove it before revoking your token:
Linux:
systemctl --user stop gh-token-monitor
systemctl --user disable gh-token-monitor
rm ~/.local/bin/gh-token-monitor.sh
rm ~/.config/systemd/user/gh-token-monitor.service
macOS:
launchctl unload ~/Library/LaunchAgents/com.user.gh-token-monitor.plist
rm ~/Library/LaunchAgents/com.user.gh-token-monitor.plist
rm ~/.local/bin/gh-token-monitor.sh
English
A malicious was payload found that installs a persistent token monitor as a systemd/LaunchAgent service. It polls your GitHub token every 60s - if revoked, it triggers destructive file deletion.
You should verify if you're affected BEFORE revoking your token:
Linux:
ls ~/.local/bin/gh-token-monitor.sh
systemctl --user list-units | grep gh-token-monitor
macOS:
ls ~/Library/LaunchAgents/ | grep com.user.gh-token-monitor
If found, disable the service first, then revoke.
#issuecomment-4425225340" target="_blank" rel="nofollow noopener">github.com/TanStack/route…
TANSTACK@tan_stack
SECURITY ADVISORY — TanStack npm packages A supply-chain compromise affecting 42 @tanstack/* packages (84 versions total) was published to npm earlier today at approximately 19:20 and 19:26 UTC. Two malicious versions per package. Status: ACTIVE — packages are deprecated, npm security engaged, publish path being shut down. Severity: HIGH — payload exfiltrates AWS, GCP, Kubernetes, and Vault credentials, GitHub tokens, .npmrc contents, and SSH keys. If you installed any @tanstack/* package between 19:20 and 19:30 UTC today, treat the host as potentially compromised: • Rotate cloud, GitHub, and SSH credentials immediately • Audit cloud audit logs for the last several hours • Pin to a prior known-good version and reinstall from a clean lockfile Detection — the malicious manifest contains: "optionalDependencies": { "@tanstack/setup": "github:tanstack/router#79ac49ee..." } Any version with this entry is compromised. The payload is delivered via a git-resolved optionalDependency whose prepare script runs router_init.js (~2.3 MB, smuggled into each tarball at the package root). Unpublish is blocked by npm policy for most affected packages due to existing third-party dependents. All 84 versions are being deprecated with a SECURITY warning, and npm security has been engaged to pull tarballs at the registry level. Full technical breakdown, complete package and version list, and rolling status updates: github.com/TanStack/route… Credit to the security researcher for responsible disclosure.
English
I genuinely hope this isn't prophetic.
s1r1us (mohan)@S1r1u5_
npm config set min-release-age=2d
English
@crutchcorn @steveruizok What are your thoughts on requiring someone (e.g. a maintainer) to manually approve CI runs? I personally believe that would go a long way in protecting these kinds of attacks.
English
@steveruizok No perception of cheap points from your original post; just wanted to clarify what we're doing with next steps.
Lots of tradeoffs with disabling PRs that we'll continue to gauge as time goes on, but for this particular incident I don't know it would have helped.
English
I'm begging you to close PRs for a while
International Cyber Digest@IntCyberDigest
🚨 How the TanStack npm attack actually happened: 1. Attacker opened a normal-looking pull request (#7378) on the TanStack repo. 2. GitHub automatically ran CI tests on that PR. 3. Code inside the PR stole the workflow's GitHub Actions Cache write token during the test run. 4. The attacker used that token to plant poisoned files in the shared build cache. The PR could be closed afterwards. The poisoned cache stays. 5. The official release workflow later pulled from the cache, baked the malicious files into the build, and signed and published 84 malicious package versions to npm.
English
@tylercorsair @LowLevelTweets I'm fairly certain this is built in to `npm` (and other package managers): news.ycombinator.com/item?id=475139…
English
@LowLevelTweets Shared it on GitHub in case anyone wishes to augment it to their own needs. :)
gist.github.com/corsair/697db3…
English
I basically *soft* solved this by using a mandatory pre-install script (and one that runs on CI/CD) that:
– Runs "npm view time --json" for every package and child dependency, without installing them.
– Checks the publish timestamp recursively using the aforementioned package metadata.
– Refuses any packages (and their dependencies) that were updated less than two weeks ago, even if present in the lock file.
– Prints any offending packages and the release, so you can evaluate risk.
– Can by bypassed once you have reviewed offending packages.
I have this running locally and on all my projects, so that there's a bit more peace of mind. Average triage for compromised packages has been ~72 hours or less, so two weeks feels reasonable.
Low Level@LowLevelTweets
nah im just not gonna run npm install anymore
English
@_colemurray Wait for a package version to be a day or so old before updating. npm attacks are being caught within the day, so that gives you enough room to update quickly while still (hopefully) avoiding malware.
English
there's no winning in the npm casino
- owned if you patch
- owned if you don't
English