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…
Maybe you shouldn't install new software for a bit
421–430 of 497 posts
Re: Maybe you shouldn't install new software for a bit
#422Earlier 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?
(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
#423AI 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
#424Earlier 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.
Re: Maybe you shouldn't install new software for a bit
#425Earlier 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…
Re: Maybe you shouldn't install new software for a bit
#426Earlier 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.
Re: Maybe you shouldn't install new software for a bit
#427This 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…
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
#428This 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…
Re: Maybe you shouldn't install new software for a bit
#429Earlier 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.
Re: Maybe you shouldn't install new software for a bit
#430Earlier 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…
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 :)