Live data from Hacker News

Maybe you shouldn't install new software for a bit

xeiaso.net

71–80 of 497 posts

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

#71
post #69
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…

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…

To be fair, to some extent that’s up to us. Time to get cleaning, I guess.

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

#72

Earlier quoted context omitted.

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 agree that de facto the biggest security flaw in Linux is "okay I'm tired of getting interrupted all day assisting you, I know you're competent, I'll put you on the sudoers list." But there are a lot of academic and research institutions that actually do have good Linux user management. I worked at a pediatric hospital, and the RHEL HPC admins did not mess around in terms of who was allowed to access which patients…

I think we've concluded already that user isolation is not safe and shouldn't be trusted, that's why we've invested to hard into namespacing(containers). users should only have what they need if you really care about security and don't want to tolerate the overhead of virtualization based security.

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

#73
post #42

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…

If you are switching to a BSD for security reasons, why FreeBSD? Isn't OpenBSD the super secure one? Sorry, it's been a while since I've looked at those projects

The person suggesting FreeBSD is a FreeBSD developer (Colin Percival - actually according to Wikipedia FreeBSD engineering lead), would be weird for him to suggest openbsd.

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

#74
post #63

Earlier quoted context omitted.

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

[flagged]

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.

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

#75

Earlier quoted context omitted.

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…

> 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. I won't enter into all the details but... It's totally possible to not have the sudo command (or similar) on a system at all and to have su with the setuid bit off. On my main desktop there's no sudo command there are zero binaries with the setuid bit set. The only way to get root invo…

nixos comes to mind, rootless runpod, qubesos.

but they all have something in common, the issue is that your user is compromised that means the applications running in that user are compromised the only thing you gain is that you can trust your system, you can trust that your system is not compromised which is only relevant with infrastructure since if your user is compromised you're already fucked, multi-user setups with untrusted accounts are inheritly insecure and in infrastrucure the blast radius might be thousands of users that use the said service.

the breakdown looks something like this:

  - you heavily compromise a single user 

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

#76
post #19
post #16

There's already an okay solution to supply-chain attacks against dependency managers like npm, PyPI, and Cargo: set them to only install package versions that are more than a few days old. The recent high-profile attacks were all caught and rolled back within a day, so doing this would have let you safely avoid the attacks. It really should be the default behavior. Let self-selected beta testers and security scanner…

So you get security updates late too? Many vulnerabilities are in the wild for years before being noticed, and patched. Once noticed, that's where the exploit explosion erupts, excited exploiters everywhere, emboldened... enticed... excessively encouraged, by your delayed updates.

Presumably npm exempts security updates from its minimum release age, but even if it doesn't, I think the times where you need an important security update are relatively rare enough that handling the real cases on a case-by-case basis with whitelisting is fine. Outside of Next.js's React2Shell vulnerability last year, I'm not sure I've ever had a security update of a dependency written in a memory-safe language (ie. not C/C++) which I've installed through npm/PyPI/Cargo that patched a security vulnerability that had been making my application exploitable to others in practice. Almost all security vulnerabilities I've personally seen flagged through npm are about things I only use at build-time and are only relevant if a user can create and pass an arbitrary object to the function, which is rarely the case. Most security vulnerabilities I've encountered and fixed in working on web apps were things like XSS, SQL injections, and improperly enforced permissions, and they nearly always happened in the application's own code rather than inside a dependency.

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

#80

The post is about Linux vulnerabilities, but given the recent supply chain attacks, I'd be especially careful with Homebrew: https://x.com/i/status/2052106143271354859

Often convenience and security are at odds, but `export HOMEBREW_NO_AUTO_UPDATE=1` is more convenient and more secure.
Post reply on HN