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

251–260 of 497 posts

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

#251

Post by mahart »

tclancy wrote: post #65
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…

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…

Having casually read into a few recent incidents the vector has often been outside of software. A lot of mis-configurations or simply attacking the human in the chain. And nation states have basically unbounded resources for everything from bribes, insiders, and even standing up entire companies.

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

#253

Post by akoboldfrying »

spockz wrote: post #242
akoboldfrying wrote: post #124

Earlier quoted context omitted.

Yes, a lot hinges on how little you can get away with implementing for your use case. If you have an XML config file with 3 settings in it, you probably won't need to implement handling of external entities the way a full XML parsing library would, which will close off an entire class of attendant vulnerabilities. > Also, even seemingly trivial libraries can have bugs. The infamous leftpad library didn't handle certa…

This argument goes even further. If you have only 3 settings, why does it need to be an xml file?

ETA: I'm not saying it has to, I'm saying it's possible to imagine reasons that would justify this decision in some cases.

Because it might grow in future and you want to allow flexibility for that, because it might be the input to or output from some external system that requires XML, because your team might have standardised on always using XML config files, because introducing yet another custom plain text file format just creates unnecessary cognitive load for everyone who has to use it are real-world reasons I can think of.

But really I was just looking for a concrete example where I know the complexity of the implementation has definitely caused vulnerabilities, whether or not the choice to use it to solve the problem at hand was sensible. I have zero love for XML.

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

#254

Post by cromka »

nomilk wrote: post #80
leonidasv wrote: post #78

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.

Problem here is Brew does things in an anti-unix way by default, the auto updating of packages being the prominent reason.

I personally switched away from macOS with this being one of the reasons, after having realized brew will eventually compromise my system with their antics.

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

#255

Post by whilenot-dev »

hennell wrote: post #248
whilenot-dev wrote: post #233

Earlier quoted context omitted.

You forgot case #4: Worked at a startup where the frontend team thought it was a good idea to use lock files during development, but to do a "fresh" install of all dependecies during the deployment step. And yes, they still thought they were doing the right thing.

To be fair npm makes (made?) it weirdly hard to use lock files so a lot of people did that by mistake. And when you do use lock, it reinstalls every time so a retagged package can just silently update.

FYI a retagged package would result in a different SHA512 integrity sum and fail the installation process. It won't "just silently update".

Anyway, the point of parent and me wasn't that it was considered to be a "mistake", but people thinking they "are doing the right thing".

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

#257

Post by uecker »

marcus_holmes wrote: post #240
duskdozer wrote: post #225

Earlier quoted context omitted.

>As an example, he put up a slide listing the 47 car brands that use curl in their products; he followed it with a slide listing the brands that contribute to curl. The second slide, needless to say, was empty. >He emphasized that he has released curl under a free license, so there is no legal problem with what these companies are doing. But, he suggested, these companies might want to think a bit more about the futu…

There is a lot of opposition in the FOSS community for restrictive/protective licenses. And to be fair, this comes from a consistent and entirely logical worldview. There's a bunch of problems with getting companies to pay for this, too - that sense of entitlement (or even contractual obligation), the ability to control the project with cash, etc. I don't have any answers or solutions. But I don't think we can hand-w…

The problem is that they get away too easily with bugs in their products they ship to customers. If this would come with some penalties, there would be some incentive to invest in security and this would probably often flow back to upstream projects.

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

#258

Post by kaelyx »

mastermage wrote: post #249

I think what we have to start accepting even security experts is that our world is incredibly fragile. I think people realy understimate this. And I do not mean just the IT world but the entire world is built on many incredibly fragile balances. Security Exploits will always exist. Not just in software but in real life. Heck someone managed to Sneak into a Security Conference. And that guy was a random youtuber. Gran…

I remember there was a trend with some UK Influencers using some "Ladder and a High-vis" tricks to enter places for a while to show how rough physical security is [0]. I believe its the youtuber, Max Fosh, who managed to do it back to back at the International Security Expo, first in the UK [1] and then in the US [2], with the fake names 'Rob Banks' and 'Nick Everything'.

I've studied security culture before and in most cases everything comes down to a sliding scale with security on one side and convenience/accessibility on the other, the more secure something is, the less accessible it is and vice versa.

[0] https://www.youtube.com/watch?v=LTI0SeyhAPA

[1] https://www.youtube.com/watch?v=qM3imMiERdU

[2] https://www.youtube.com/watch?v=NmgLwxK8TvA

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

#259

Post by mike_hearn »

josephg wrote: post #99
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'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" b…

Capabilities have a lot of serious design problems which is why no mainstream language has them. Because this comes up so often on HN I wrote an essay explaining the issues here:

https://blog.plan99.net/why-not-capability-languages-a8e6cbd...

But as pointed out by others, this particular exploit wouldn't be stopped by capabilities. Nor would it be stopped by micro-kernels. The filesystem is a trusted entity on any OS design I'm familiar with as it's what holds the core metadata about what components have what permissions. If you can exploit the filesystem code, you can trivially obtain any permission. That the code runs outside of the CPU's supervisor mode means nothing.

The only techniques we have to stop bugs like this are garbage collection or use of something like Rust's affine type system. You could in principle write a kernel in a language like C#, Java or Kotlin and it would be immune to these sorts of bugs.

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

#260

Post by KronisLV »

dataflow wrote: post #219
YZF wrote: post #191

Earlier quoted context omitted.

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…

> Everyone seems to think they are doing the right thing I like to think people would agree more on the appropriate method if they saw the risk as large enough. If you could convince everyone that a nuclear bomb would get dropped on their heads (or a comparably devastating event) if a vulnerability gets in, I highly doubt a company like #2 would still believe they're doing things optimally, for example.

> if they saw the risk as large enough.

If you expose people to the true risks instead of allowing them to be ignorant, the conclusion that they might come to is that they shouldn’t develop software at all.

Post reply on HN