Live data from Hacker News

Maybe you shouldn't install new software for a bit

xeiaso.net

191–200 of 497 posts

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

#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 call on if they apply to us or not and how we mitigate or address them.

Then I moved to another company where we had builds that access the Internet. We upgrade things as soon as they come out. And people think this is good practice because we're getting the latest bug fixes. CVEs are reviewed by a security team.

Then a startup with a mix of other practices. Some very good. But we also had a big CVE debt. e.g. we had secure boots on our servers and encrypted drives. We had a pretty good grasp on securing components talking to each other etc.

Everyone seems to think they are doing the right thing. It's impossible to convince the "frequent upgrader" that maybe that's a risk in terms of introducing new issues. We as an industry could really use a better set of practices. Example #1 for me is better in terms of dependency management. In general company #1 had well established security practices and we had really secure products.

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

#192

Earlier quoted context omitted.

>there's no reason to assume the average author would magically create fewer bugs than the original OS library authors initially did Have you read this old code? It's terrible and written with no care at all to security often in C. AI is much much better at writing code.

Do you have a specific library in mind? I think it would have to be an ancient, unmaintained C library. But I think most OSS code isn't like this -- even C code born long ago, if it's still in wide use, has been hardened by now. Examples: Linux kernel, GNU userland, PostgreSQL, Python.

> even C code born long ago, if it's still in wide use, has been hardened by now. Examples: Linux kernel

There have been two LPE vulnerability and exploits in the Linux kernel announced today. After the one announced just last week. I don't think as much of the C code born long ago has been as carefully hardened as you think.

(Copy Fail 2 and Dirty Frag today, and Copy Fail last week)

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

#193

"Wait a week to install software" does not work. Just a few months ago a massive exploit hit the web, which was a timed attack which sat for more than a month before executing. If everyone starts waiting a week, their exploits will wait 2 weeks. Cyber criminals do not need to exploit you immediately, they just need to exploit you. (It also doesn't change a large range of vuln classes like typosquatting)

Every dependency compromise that I can remember "in the past few months" were discovered in hours, if not minutes (litllm, axios, bitwarden CLI, Checkmarx docker images, Pytorch lightning, intercom/intercom-php). What's more, the discovery of these compromises did not at all rely on whether the compromises were actively used.

That's why I don't understand:

> If everyone starts waiting a week, their exploits will wait 2 weeks

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

#194

Earlier quoted context omitted.

What we are seeing so far come out of the AI agent era is reduced not increased code quality. The few advances are by far negated by all the slop that's thrown around and that's unlikely to change. > any useful piece of software has been fuzz tested, property tested and formally verified. That would require effort. Human effort and extra token cost. Not going to happen, people want to rather move fast an break things…

Isn't blaming AI for that similar to blaming C for buffer overflows? More people are producing more code because of easier tools. Most code is bad. But that's not the tools fault. And in the end it is a problem of processes and culture.

We are not in disagreement here. I'm not blaming AI, I'm blaming the culture around its use.

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

#195

Earlier quoted context omitted.

This assumes that there are no new exploits being generated. We're seeing maintainers retreat from maintaining because the amount of AI slop being pushed at them is too much. How many are just going to hand over the maintenance burden to someone else, and how many of those new maintainers are going to be evil? The essential problem is that our entire system of developing civilisation-critical software depends on the…

That is already how it works. The loner hacker in moms basement working for free on his super critical OSS package is largely a myth. The vast majority of OSS code is contributed by companies paying their employees to work on it.

I'm thinking of projects like curl [0]

this is a cornerstone of modern software development. If it died, or if got taken over by a malicious entity, every single company on the planet would have an immediate security problem. Yet the experience of that maintainer is bad verging on terrible [1].

We need to do better than this.

[0] https://curl.se/docs/governance.html

[1] https://lwn.net/Articles/1034966/

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

#196
post #69

Earlier quoted context omitted.

TBH this is a pretty good way of looking at it. Yeah we're seeing an explosion of vulnerabilities being found right now, but that (hopefully) means those vulnerabilities are all being cleaned up and we're entering a more hardened era of software. Minus the software packages that are being intentionally put out as exploits, of course. Maybe some might say it's too optimistic and naive, but I think you have a good poin…

> 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…

[deleted]

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

#198
post #161
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…

I think it will be an arms race in the future as well. Easier to fix known vulnerabilities automatically, but also easier to find new ones and the occasionally AI fuckup instead of the occasionally human fuckup.

Yeah.

Right now it kinda feels to me like "Open Source" is the Russian army, assuming their sheer numbers and their huge quantity of equipment much off which is decades old.

Meanwhile attackers and bug hunters are like the Ukrainians, using new, inexpensive, and surprisingly powerful tools that none of the Open Source community has ever seen in the past, and for which it has very little defence capability.

The attackers with cheap drones or LLMs are completely overwhelming the old school who perhaps didn't notice how quickly the world has changed around them, or did notice but cannot do anything about quickly enough.

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

#199
post #146

Earlier quoted context omitted.

Have you heard of pledge in OpenBSD? I prefer it’s model of declaring this is what I want to use, any calls to code outside that error out.

Yes. But its nowhere near as powerful as capabilities. - Pledge requires the program drop privileges. Process level caps move the "allowed actions" outside of an application. And they can do that without the application even knowing. This would - for example - let you sandbox an untrusted binary. - Pledge still leaves an entire application in the same security zone. If your process needs network and disk access, ever…

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.

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

#200

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 am feeling really uncomfortable sitting on a large React project.

Whether to do constant npm upgrades to keep the high-priority security issues count at zero (for what seems like about 15 minutes), or whether to hang back a bit to avoid catching the big one that everyone knows is coming real soon now.

Not enjoying npm at all.

Post reply on HN