Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maybe you shouldn't install new software for a bit

xeiaso.net

Post reply on HN
Print view View original

271–280 of 497 posts

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

#271

Post by echelon_musk »

YZF wrote: post #191
marcus_holmes wrote: post #57

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…

Do you ride an R1?

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

#272

Post by 1718627440 »

q3k wrote: 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.

When you control the bashrc of some other person, it is already kind of game over.

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

#273

Post by rounce »

jpollock wrote: post #102
tclancy wrote: 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?

This is related to a massive annoyance of mine: when I run a piece of software and the system is missing a required dependency, I want the software to *tell me* that dependency is missing so I can make a decision about proceeding or not. Instead it seems that far too often software authors will try and be “clever” by silently installing a bunch of dependencies, either in some directory path specific to the software, or even worse globally.

I run a distro that often causes software like this to break because their silent automatic installation typically makes assumptions about Linux systems which don’t apply to mine. However I fear for the many users of most typical distros (and other OS’ in general as it’s not just a Linux-only issue) who are subject to having all sorts of stuff foisted onto their system with little to no opportunity to easily decide what is being heaped upon them.

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

#274

Post by 1718627440 »

himata4113 wrote: post #44
q3k wrote: 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…

First, if you control the account of the administrator, you already have a worst case scenario. Second, this is why distros tell you to not use sudo. The purpose of sudo is to give some people the ability to run a very specific program with elevated privileges that wouldn't be allowed otherwise, while you don't want them to have any other administrative rights. If you want someone to be an admin over the system, just give them the root password.

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

#275

Post by 1718627440 »

q3k wrote: post #61
TacticalCoder wrote: post #55

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

Yes, you are very special and smart. Good for you! Most people however aren't and will happily run sudo after an npm postinstall script tells them to apt-install turboencabulator for their new frontend framework to function.

You really can't protect against a malicious sysadmin. Let them be bitten, maybe they will be smarter next time.

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

#277

Post by CriticalRegion »

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 carried out. Most supply chain attacks are performed via credential theft and social engineering. The more sophisticated ones are APT style attacks like the Solarwinds one (which were carried out by organisations that would already have exploits like these) or more creative stuff like the Shai-Hulud fiasco. All of these options existed before these LPEs. If you're worried about supply chain attacks you've been worried for longer than Mythos has been out. Not updating your software is never good security advice.

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

#278

Post by Luker88 »

Luker88 wrote: post #276

Dammit, this is why nobody uses NixOS. Nothing works on it! The copyFail didn't, the dirtyfrag doesn't. This copfail2 does modify /etc/passwd, but I can't `su - sick` as expected. /s

sligtly unrelated, but the portable way to execute stuff is via `/usr/bin/env`, not `/bin/bash`.

I did try fixing the path to use nixos paths, but it was still unsuccessful. Did not really check further.

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

#279

Post by rounce »

c7b wrote: post #179
weregiraffe wrote: post #168

Earlier quoted context omitted.

But you can't expect the language std to supply you with every package under the sun.

I don't have an answer what the alternative is going to look like. But smarter people than me may find something. C/C++ are doing fine without package managers. Go at least has a more capable standard library than Rust. But I'm not sure if Go's import github approach is the answer. One idea I've been entertaining is to not allow transitive imports in packages. It would probably lead to far fewer and more capable pack…

> Go at least has a more capable standard library than Rust.

Many Golang projects I see in the wild will import a number of dependencies with significant feature overlap with sections of the standard library, or even be intended as a replacement for them. So it seems that having an expansive stdlib isn’t sufficient to avoid deep dependency trees, it probably helps to some degree but it’s definitely not a panacea.

Post reply on HN