Live data from Hacker News

Maybe you shouldn't install new software for a bit

xeiaso.net

91–100 of 497 posts

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

#93

Don't install anything, use an LLM to write everything from scratch. It may have bugs, but no one will know how to exploit them, especially when closed source. Code is cheap and is becoming cheaper by the day. We need new paradigms.

Next: the back doors are written by the LLM!

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

#94
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

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

#95
post #39

You don't need a kernel LPE to root a Linux developer machine. Just alias sudo to sudo-but-also-keep-password-and-execute-a-payload in ~/.bashrc and wait up to 24 hours. Maybe also simulate some breakage by intercepting other commands and force the user to run 'sudo systemctl' or something sooner rather than later.

this, this is something I don't understand there are a billion ways to gain root once you control the user that regulary uses sudo. this is only scary for rootless containers as it skips an isolation layer, but we've started shipping distroless containers which are not vulnerable to this due to the fact that they lack priviledge escalation commands such as su or sudo. never trust software to begin with, sandbox every…

I doubt your “distroless” container is any safer for this vulnerability .

Infecting sudo just makes for a quick demo.

If your container has different processes at different user ids, the exploit would still be effective.

It would likely also be able to “modify” read only files mapped from the host.

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

#96
post #59

I got rid of half of my VSCode extensions a couple days ago, its too risky.

Those things scare the crap out of me…

Even worse are the “extension packs” that combine some normal things and one wonky thing nobody’s ever heard of…

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

#97

Earlier quoted context omitted.

So you have one example in hand and trash talked FreeBSD’s entire security team. Bold claims are fine but this is lazy. FreeBSD isn’t secure, I suspect you’re sitting on a pile of 0 days for it?

Ask yourself why Mythos was so easily able to develop a remote STACK buffer overflow vulnerability.

Define "so easily"?

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

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

New software is being generated faster than it can be adequately tested. We are in the same place we’ve always been; except everything is moving much too fast.

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

#99

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've been wanting a capability based security model for years. Argued about it here in fact. Capabilities are kind of an object pointer with associated permissions - like a unix file descriptor.

We should have:

- OS level capabilities. Launched programs get passed a capability token from the shell (or wherever you launched the program from). All syscalls take a capability as the first argument. So, "open path /foo" becomes open(cap, "/foo"). The capability could correspond to a fake filesystem, real branch of your filesystem, network filesystem or really anything. The program doesn't get to know what kind of sandbox it lives inside.

- Library / language capabilities. When I pull in some 3rd party library - like an npm module - that library should also be passed a capability too, either at import time or per callsite. It shouldn't have read/write access to all other bytes in my program's address space. It shouldn't have access to do anything on my computer as if it were me! The question is: "What is the blast radius of this code?" If the library you're using is malicious or vulnerable, we need to have sane defaults for how much damage can be caused. Calling lib::add(1, 2) shouldn't be able to result in a persistent compromise of my entire computer.

SeL4 has fast, efficient OS level capabilities. Its had them for years. They work great. They're fast - faster than linux in many cases. And tremendously useful. They allow for transparent sandboxing, userland drivers, IPC, security improvements, and more. You can even run linux as a process in sel4. I want an OS that has all the features of my linux desktop, but works like SeL4.

Unfortunately, I don't think any programming language has the kind of language level capabilities I want. Rust is really close. We need a way to restrict a 3rd party crate from calling any unsafe code (including from untrusted dependencies). We need to fix the long standing soundness bugs in rust. And we need a capability based standard library. No more global open() / listen() / etc. Only openat(), and equivalents for all other parts of the OS.

If LLMs keep getting better, I'm going to get an LLM to build all this stuff in a few years if nobody else does it first. Security on modern desktop operating systems is a joke.

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

#100
post #67

Alternatively, switch to an operating system like FreeBSD which doesn't take a YOLO approach to security. Security fixes don't just get tossed into the FreeBSD kernel without coordination; they go through the FreeBSD security team and we have binary updates (via FreeBSD Update, and via pkgbase for 15.0-RELEASE) published within a couple minutes of the patches hitting the src tree. (Roughly speaking, a few seconds for…

There’s always a guy. It’s great that your favorite distro is definitely safer. An order of magnitude fewer exploits will mean only a few thousand or so, I suppose. Ozymandis used Gentoo.

Calling FreeBSD "just a distro" is verging on insulting. It's an operating system.
Post reply on HN