Live data from Hacker News

Maybe you shouldn't install new software for a bit

xeiaso.net

421–430 of 497 posts

Re: Maybe you shouldn't install new software for a bit

#421

This is a baffling take.. These exploits are local privilege escalations for linux systems. They'll allow an attacker with a foothold in a shared environment or with low privilege access to a system to affect the rest of the system. They aren't RCEs and won't let attackers access environments that they couldn't before other than the shared hosting scenarios. That is absolutely not how most supply chain attacks are ca…

Well it does say "install" new software, as in run code locally

Re: Maybe you shouldn't install new software for a bit

#422
post #65

Earlier quoted context omitted.

So, to play Pandora, what if the net effect of uncovering all these unknown attack vectors is it actually empties the holsters of every national intelligence service around the world? Just an idea I have been playing with. Say it basically cleans up everything and everyone looking for exploits has to start from scratch except “scratch” is now a place where any useful piece of software has been fuzz tested, property t…

Faults are injected into the code at a constant rate per developer. Then there's the intentional injections. Auto-installing random software is the problem. It was a problem when our parents did it, why would it be a good idea for developers to do it?

Is it really a constant rate? Or is it a Law of Large Numbers kind of thing, where past a certain scale the randomness gets smoothed out and looks constant? Or something else?

(Obviously some developers are better or worse than others, so I presume your observation is assuming developer skill as a constant.)

Re: Maybe you shouldn't install new software for a bit

#423
Genuine question: I wonder if AI coding is responsible for the new exploits coming to light.

AI coding is great at is helping you try out things you wouldn't have the time or energy to normally do. It shines for writing scripts that aren't part of a larger codebase, and helping with boring, rote tasks.

Hackers are also very motivated to use new tools to find any kind of opening (unlike normal devs who aren't always as... motivated :).

Re: Maybe you shouldn't install new software for a bit

#424
post #400

Earlier quoted context omitted.

> It's impossible to convince the "frequent upgrader" that maybe that's a risk in terms of introducing new issues. Well, you critisize people who run the latest software here. Two counter-arguments: 1) If you don't upgrade frequently, you end up with super stable debian stuck on ... ancient software. This in turn means that many more recent software, won't work, unless you recompile a lot. I had this issue with mesa…

Debian had backports since forever. You could totally upgrade the kernel and MESA since month 1.

Not forever, backports were introduced with Sarge IIRC. And typically versions only appears in backports that are also in testing/unstable, e.g. Linux 6.19 is currently in trixie-backports but the non-LTS kernels between 6.12 and 6.18 were not available there, nor is the current 7.0 (yet).

Re: Maybe you shouldn't install new software for a bit

#425

Earlier quoted context omitted.

> we're entering a more hardened era of software This is one force that operates. Another is that, in an effort to avoid depending on such a big attack surface, people are increasingly rolling their own code (with or without AI help) where they might previously have turned to an open source library. I think the effect will generally be an increase in vulnerabilities, since the hand-rolled code hasn't had the same amo…

While agreeing, it also changes the mathematics of it: if a bad actor wants to hack me specifically now they have to write custom code that targets my software after figuring out what it _is_. This swaps the asymmetry around: instead of one bad actor writing an exploit for all the world (and those exploits being even harder to find), you have to hate me specifically. Admittedly, not hard to do, but it could save some…

Depends how cheap running llms against your software becomes in the future.

Re: Maybe you shouldn't install new software for a bit

#426

Earlier quoted context omitted.

One. "Copy Fail 2" and "Dirty Frag" are the same thing.

And consideing the size of the kenel, I call this stupendously good. You (anyone, not you personally) write that much code yourself and let's see how well you did in comparison.

But that's the attacker advantage. You can do things right a billion times and one mistake will still take you down.

Re: Maybe you shouldn't install new software for a bit

#427
post #65

This was always a nightmare waiting to happen. The sheer mass of packages and the consequent vast attack surface for supply chain attacks was always a problem that was eventually going to blow up in everyone's face. But it was too convenient. Anyone warning about it or trying to limit the damage was shouted down by people who had no experience of any other way of doing things. "import antigravity" is just too easy to…

So, to play Pandora, what if the net effect of uncovering all these unknown attack vectors is it actually empties the holsters of every national intelligence service around the world? Just an idea I have been playing with. Say it basically cleans up everything and everyone looking for exploits has to start from scratch except “scratch” is now a place where any useful piece of software has been fuzz tested, property t…

Here's a crazy idea -- what if some of these vulnerabilities are surfacing because they have actually been found, already, and exist in the training data?

Even an intelligence agency doesn't have perfect opsec, and something could get mentioned offhand somewhere on a forum, but never get picked up until the LLM uses it.

Re: Maybe you shouldn't install new software for a bit

#428
post #191

This was always a nightmare waiting to happen. The sheer mass of packages and the consequent vast attack surface for supply chain attacks was always a problem that was eventually going to blow up in everyone's face. But it was too convenient. Anyone warning about it or trying to limit the damage was shouted down by people who had no experience of any other way of doing things. "import antigravity" is just too easy to…

I worked for one company where we were super conservative. Every external component was versioned. Nothing was updated without review and usually after it had plenty of soak time. Pretty much everything built from source code (compilers, kernel etc.). Builds [build servers/infra] can't reach the Internet at all and there's process around getting any change in. We reviewed all relevant CVEs as they came out to make a…

Honestly the de facto standard is to blame: at my dev job, we vacuum up all the packages we need and get the software deployed to production ASAP, then later go over the SBOM and make sure nothing looks sketchy. I'd imagine this is the default most places; an intensive approval process would slow down CI/CD too much.

Re: Maybe you shouldn't install new software for a bit

#429
post #138

Earlier quoted context omitted.

If I hand roll my logging library, I unlikely include automatic LDAP request based on message text (infamous Log4j vulnerability).

I’m seeing a lot of similar things during code reviews of substantially LLM-produced codebases now. Half-baked bad idea that probably leaked from training sets.

It would be very helpful to see even just one example of this syndrome posted so others could become better informed.

Re: Maybe you shouldn't install new software for a bit

#430
post #199

Earlier quoted context omitted.

I’m not trying to say use pledge/unveil to make capabilities, I’m saying use pledge/unveil to limit exposure. To me it’s easier to get a program to let the system know what it needs vs. try to contain it from the outside. Anyway, have a good one.

There's an interesting distinction here where one approach is to build sandboxes that limit exposure, while the other is just allowing the program to be more secure. One approach is "Trust No Code" and the other is "Trusted code should run safely". the first one sounds better on paper, but leads to a very complicated system. That said, I haven't worked with jails much or other forms of sandboxing. It just seems to me…

I definitely lean to the “trusted code should run safely” because it’s just simpler in general.

At what point do you trust the system? And if you don’t trust any of it what are you trying to accomplish?

Re OpenBSD: I think it just shows we’re all human(fallible) at the end of the day :)

Post reply on HN