Top
Best
New

Posted by psxuaw 13 hours ago

Maybe you shouldn't install new software for a bit(xeiaso.net)
568 points | 305 commentspage 2
clbrmbr 1 hour ago|
So what do we do? Pin our dependencies (to hashes when possible), and only update when there are CVEs?

But problem is this could lead to abuse of the CVE system to try to force rapid adoption of attacked packages. What prevents this?

papichulo2023 1 hour ago||
Run everything as sudo so they cant escalate any further ;)
clbrmbr 1 hour ago||
Do you know if this exploit works on Docker containers? And if so, I assume it just allows escalation WITHIN the container? So this attack is scary for Linux desktops and servers, but a fully containerized system like common on CI/CD should be good. Right?
throawayonthe 1 hour ago||
Nothing :D
andai 10 hours ago||
Can someone help me understand the copyfail thing and how it relates to NPM packages?

Edit: I think I understand. copyfail is a kernel bug that lets a malicious npm package get root access on your Linux server, right?

So now, while there are unpatched servers, is when it would be the perfect time for attackers to target NPM packages.

And the advice isn't just "update your kernel" because we are still finding new related issues?

ahpeeyem 10 hours ago||
NPM supply-chain attacks spread really quickly.

If a popular NPM package was compromised and included a copy.fail exploit, it would make lots of systems vulnerable to root privilege escalation.

Gigachad 4 hours ago|||
The patches for the latest vulnerabilities aren’t even out yet. So it would be a real bad time for a new supply chain attack since it would get root on pretty much every system.
wavemode 5 hours ago|||
> And the advice isn't just "update your kernel" because we are still finding new related issues?

The advice isn't just "update your kernel" because there is no update. The latest vulnerability (the one discovered after copy.fail) still has no fix.

xena 10 hours ago||
npm can run on linux.
metaengies 4 hours ago||
Actively destructive opinion article. I could not begin to understand the rationale.

It takes 45 seconds to go check how old the copyfail and dirtyfrag vulnerabilities actually are. Which is longer than it takes to read TFA. Dirtyfrag may be relevant to systems from as far as 2017.

It's not "new" software being affected. And actual old software is in a much worse state because we had a lot more time to find their problems.

smallpipe 4 hours ago|
OP is suggesting that a supply chain attack would be bad now, and to reduce that risk by not installing/updating NPM packages.
rablackburn 7 hours ago||
Literally implemented PR guards today to prevent the team merging any dependencies that didn’t have explicit versions pinned (and that matched the resolution in the lock file).

People lamented semver not being trustable but that ship sailed a long time ago, and supply chain attacks are going to get worse before they get better.

Our team is pretty minimal when it comes to enforced hooks (everyone has their own workflow) but no one could come up with an objection to this one.

clbrmbr 1 hour ago|
Wouldn’t you prefer to pin to SHA hashes? Or does your package manager cloud-side ensure immutability of releases?
Animats 8 hours ago||
I'm holding off on upgrading to Ubuntu 26.04 LTS until we have a few months of experience with the new release. Canonical just had a huge DDOS attack, and there might have been other attacks hidden in all that traffic.
mobeigi 3 hours ago||
I saw a recent post about only adopting packages a certain number of days post release (say +3 days, or +7 days) after. The idea is you never bring in fresh commits, only older ones. This would need dangerous or bad commits to be marked vulnerable too.

It means you skip supply chain attacks but may miss fresh vulnerability patches too.

fkarg 12 hours ago||
the lottery of either getting a new supply-chain attack or the fixes from Mythos with every single update
1a527dd5 4 hours ago||
This applies to much more than just software, in fact it applies to almost everything.

I don't remember where I read it, but it basically boils down to need vs want.

I've used that rule for deciding between a new car or used. A fancy vacuum or basic.

A shiny new gadget.

Bringing new things into the tech stack.

Picking a new tech stack.

golem14 9 hours ago||
This gets me to ask whether I have been hacked . For a few weeks now, both my main mbp and iPhone have been showing unexpected hangs of 1-30 seconds. I can’t find out what’s causing it - not memory pressure, not cpu load.

I am worried that the sluggishness appeared about the same time on both devices

Gigachad 8 hours ago|
For ios, rebooting your phone is extremely effective at removing exploits. The boot chain attestation stuff can verify the system is in a known state. If you are ultra paranoid you could enable lockdown mode which preemptively disables the entrypoints for exploits. So far I don't believe there has been any exploit which works with lockdown mode enabled.
Georgelemental 7 hours ago||
If you are already exploited though, I doubt it helps
jeroenhd 6 hours ago|||
Getting persistent root is actually quite difficult on mobile operating systems. iOS famously so, but unless you're running a custom ROM other than Graphene, Android has some solid protections as well.

Regular phone reboots are a security measure at this point.

Gigachad 6 hours ago|||
It does though, the exploit exists in memory. When you reboot the phone the memory is reset, if it's modified system files, the checksums won't pass and your phone will refuse to boot. Requiring it to be wiped and reinstalled.

These days most exploits can not persist through a reboot due to secureboot and other bootchain attestations. In the boot process, everything loaded gets checksummed and compared to signed signatures from Apple, but this only helps at load time, not while the phone is running. Of course if the phone is not patched, the exploit could be reloaded, but this would require revising a malicious website or reopening a malicious bit of media.

cbarnes99 12 hours ago|
It really pisses me off that responsible disclosure timelines are being ignored.
creatonez 10 hours ago||
In this case, no insiders broke the embargo. It was reverse engineered from the patch by an unrelated third party and a proof of concept immediately came out of it. At that point, it's kinda fair game.
vintermann 6 hours ago||
I assume that while Mythos may be really good at finding vulnerabilities, lighter models may still do a pretty good job of explaining/exploiting the vulnerability if given the patch which fixes it.
bellowsgulch 12 hours ago|||
if you don't already consider responsible disclosure a quaint idea, you may want to grow warm on it

the idea that it exists at all is more or less a gentleman's agreement in the engineering world anyway

Root_Denied 11 hours ago|||
Less a gentleman's agreement and more of a question of economic incentives going away. Companies aren't paying out bounties at the rates they used to (possibly because they've realized there's little financial incentive to do so for most findings) and simultaneously they're being inundated with AI slop findings that somehow have to still be triaged and evaluated.
hluska 10 hours ago|||
[flagged]
ahpeeyem 9 hours ago|||
but there is punctuation: there's one comma and two apostrophes! everything we need to comprehend, nothing more

correctly using those tells me it was a stylistic choice not to use capital letters and omit the periods.

fwiw the HN guidelines say more about not posting "shallow dismissals", not complaining about "tangential annoyances" and being "kind, not snarky" than about grammar and punctuation: https://news.ycombinator.com/newsguidelines.html

irishcoffee 10 hours ago|||
Yeah, it isn’t an LLM. Missed 2 capitalizations and 2 periods, there is however a comma.

Btw, s/onto/on to

Onto can be synonymously replaced with “on top of” which doesn’t work in that sentence.

It’s much more interesting to pay attention to the spirit of the comment than the structure, which I believe is also in the site guidelines. I’m also confident I have multiple grammatical errors in this comment.

roxolotl 12 hours ago|||
The dirty frag repo says:

> Because the responsible disclosure schedule and the embargo have been broken, no patch exists for any distribution.

I had to do a double take reading that. It’s written something happened and prevented them from following a schedule but seemingly they chose to release the information. I hope I’m missing something where it was forcibly disclosed elsewhere.

Edit: Moments later I refreshed the homepage and saw the announcement. They do claim to have consulted with maintainers

rafram 11 hours ago||
> Due to external factors, the embargo has been broken, so no patch exists for any distribution.

Very odd wording. I assume there’s an interesting/upsetting story here that will come out soon.

tom_ 11 hours ago||
Presumably:

* https://github.com/V4bel/dirtyfrag/blob/master/assets/write-...

* https://github.com/V4bel/dirtyfrag/blob/master/assets/write-...

zmj 8 hours ago||
If the fix commit is public, so is the issue being fixed.
jeroenhd 6 hours ago||
With copy.fail the security patch wasn't listed as such so there wasn't a lot of attention on the issue as it remained dormant in most kernels for a while.

I don't doubt that the patch reversal + exploit PoC made by a third party is the result of people figuring out how patches work in open source projects like these.

Anyone with access to a good enough LLM can scour through supposedly minor bug fixes that might hide a critical vulnerability rather than doing it all manually. The LLM will probably throw up tons of false positives and miss half the issues, it you only need one or two successes.

More comments...