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

461–470 of 497 posts

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

#461

Post by bigiain »

seba_dos1 wrote: post #229
bigiain wrote: post #192

Earlier quoted context omitted.

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

One. "Copy Fail 2" and "Dirty Frag" are the same thing.

Are you sure? I'd really like that to be true, I felt bad finishing up work on Friday evening having applied the Dirty Frag mitigation to all our instances, but knowing (thinking?) the Copy Fail 2 vulnerability was still exploitable.

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

#462

Post by bigiain »

Brian_K_White wrote: post #313
bigiain wrote: post #198

Earlier quoted context omitted.

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

Well this argument was certainly inventive. What a weird impression to have about these things. Who exactly is the innocent little Ukraine supposed to be that the big bad open source is supposed to be attacking to, what? take their land and make the OSS leader look powerful and successful at acheiving goals to distract from their fundamental awfulness? And who are the North Korean canon fodder purchased by OSS while…

I guess I should have realised that comment could be so easily interpreted in ways I hadn't intended - given the political nature of that war.

I wasn't intending to pass judgement on which side is the "innocent little" and which is the "big bad", but I (and the downvoters) clearly see the it obviously reads one specific way.

I wish I'd chosen a less contentious example of a unarguably good army that's 50 or 100 years old and is still using tactics and equipment from the 70s and earlier, fighting against a somewhat less clearly "good" army using new tools that barely existed 5 years ago and new tactics that the older army (and everybody else) has never seem before with the capability to create new weapons and adjust tactics at speeds previously thought impossible. But that war doesn't exist (at least not outside of blindly loyal Russia supporters).

For the record, I believe Russia is clearly on the side of evil and Ukraine is clearly on the side of good in this conflict.

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

#463

Post by jason_oster »

mike_hearn wrote: post #360
josephg wrote: post #341

Earlier quoted context omitted.

> I wrote an essay explaining the issues here This essay only addresses my second point - capabilities within a program. It doesn't address OS level capabilities at all. But even in the space of programming languages, I find this essay extremely unconvincing. Like, you raise points like this: > Here are some problems you’ll have to solve in order to sandbox libraries: What is your threat model? How do you stop compon…

The article talks about OS capabilities in the second part when it discusses Mojo, which is based on IPC. > The solution is to design a language such that if I import leftpad, then call it, my computer can't get hacked. That requirement may seem clear right now, but the moment you talk to other people about your language you'll find there's no agreement on what "get hacked" means. Some people will consider calling ex…

> If you can confuse or buffer overflow the FS process by sending it messages, you can then edit state inside that process you weren't supposed to be able to access, and as that process controls the security system for everything it's game over.

The assumption here is that the FS is the root of trust for the kernel. (A claim I consider dubious, but what do I know about knowing things?) It's another way to say that if you don't harden your root of trust, you're SOL. Which, ok, fair enough. But that's frankly irrelevant because hardening the root of trust is table stakes. The system cannot be secured without it, regardless of the threat model.

All of the concerns about a definition of "getting hacked" falls out of ignoring the hardening of the root of trust. I don't wish to put words in your mouth, but my interpretation of the argument is essentially, "we can't have nice things because the root of trust cannot be hardened sufficiently to prevent all intrusions."

Iff the FS is the root of trust, and it is not possible to confuse the FS by sending it messages, then there is no game over. You have a root of trust that cannot be broken.

> Microkernels have no way to stop this, which is one reason very few operating systems move the core FS out into a separate process.

My reading of the history reaches a very different conclusion. First, the primary reason that very few operating systems in practice use a microkernel design is because Linus Torvalds believed it was too slow for early 90's hardware [1]. And everyone else just does whatever Linux is doing.

Second, security through surface area reduction (and more broadly, defense-in-depth) was always the point of the microkernel design [2]. Trivially, the principle of least privilege is how one arrives at a secure system. Monolithic kernels, to this very day, continue to prove that they cannot be secured in any practical manner. I can only assume we need things to get worse before kernel developers will tighten up and take security seriously.

> So you might as well just run it in-kernel and reap the performance benefits.

There's that same mentality. Apparently "speed at all costs" is the willful trading of security for performance. That position is just as flawed as trading essential liberty for temporary safety [3]. It doesn't matter how fast the thing is when the slightest bump always causes it to explode, killing everyone on board.

[1]: https://web.archive.org/web/20040210002251/http://people.flu...

[2]: https://www.cosy.sbg.ac.at/~clausen/PVSE2006/linus-rebuttal....

[3]: https://old.reddit.com/r/todayilearned/comments/k0c8o6/til_b...

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

#464

Post by pseudohadamard »

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…

It's interesting how standards have changed. 25 years ago people screamed about ActiveX despite Microsoft's various attempts to lock it down. Today people use something that pulls a package from a Github repo that was abandoned eight years ago that pulls a package from an FTP server in Denmark that pulls a package from a Raspberry Pi in someone's basement in New Mexico and it's all good practice.

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

#465

Post by jpollock »

i_think_so wrote: post #422
jpollock wrote: post #102

Earlier quoted context omitted.

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?

Is it really a constant rate? Or is it a Law of Large Numbers kind of thing, where past a certain scale the randomness gets smoothed out and looks constant? Or something else? (Obviously some developers are better or worse than others, so I presume your observation is assuming developer skill as a constant.)

Well, I think there are two things at play here.

1) As org size grows, it's the team's average quality that matters (so yes, large numbers).

2) Even with a single team, the velocity will increase to match the acceptable level of quality.

Management will push the accelerator until they get too many bugs, then it will be "we need fewer outages".

So, in an team+environment, you end up with a constant (in time) detection rate, which basically means a constant in time injection rate.

If the teams' velocity increases without increasing quality, the bug injection rate (and detection rate) will increase.

AKA if the AI is slightly worse, but 10x faster, stop carrying the pager. :)

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

#466

Post by pseudohadamard »

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.

Another example of this is Python and its awful externally-managed-environment handling, for which the procedure for anyone who doesn't use Python every day boils down to:

1. Get instructions from somewhere, a web page, HOWTO, whatever, telling you to "pip install thing".

2. "× This environment is externally managed"

3. Spend awhile Googling how to get past this and just make the damn thing work while swearing.

This is from observing users in practice. Google "This environment is externally managed" and you'll get nothing but hits on (a) people asking what this means and how to make it go away and (b) various unsafe methods to make it so.

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

#468

Post by seba_dos1 »

bigiain wrote: post #461
seba_dos1 wrote: post #229

Earlier quoted context omitted.

One. "Copy Fail 2" and "Dirty Frag" are the same thing.

Are you sure? I'd really like that to be true, I felt bad finishing up work on Friday evening having applied the Dirty Frag mitigation to all our instances, but knowing (thinking?) the Copy Fail 2 vulnerability was still exploitable.

Technically there are two things that need to be fixed in the kernel indeed (and one of them was fixed already), but they're both under the "Dirty Frag" umbrella and the proposed mitigation to not allow the affected modules to load applies to them both.

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

#469

Post by bulbar »

bigiain wrote: post #462
Brian_K_White wrote: post #313

Earlier quoted context omitted.

Well this argument was certainly inventive. What a weird impression to have about these things. Who exactly is the innocent little Ukraine supposed to be that the big bad open source is supposed to be attacking to, what? take their land and make the OSS leader look powerful and successful at acheiving goals to distract from their fundamental awfulness? And who are the North Korean canon fodder purchased by OSS while…

I guess I should have realised that comment could be so easily interpreted in ways I hadn't intended - given the political nature of that war. I wasn't intending to pass judgement on which side is the "innocent little" and which is the "big bad", but I (and the downvoters) clearly see the it obviously reads one specific way. I wish I'd chosen a less contentious example of a unarguably good army that's 50 or 100 years…

The problem with the metaphor is that you switched the attacker and defender role.

Russia is the aggressor, but in your metaphor they are the defenders.

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

#470

Post by mike_hearn »

jason_oster wrote: post #463
mike_hearn wrote: post #360

Earlier quoted context omitted.

The article talks about OS capabilities in the second part when it discusses Mojo, which is based on IPC. > The solution is to design a language such that if I import leftpad, then call it, my computer can't get hacked. That requirement may seem clear right now, but the moment you talk to other people about your language you'll find there's no agreement on what "get hacked" means. Some people will consider calling ex…

> If you can confuse or buffer overflow the FS process by sending it messages, you can then edit state inside that process you weren't supposed to be able to access, and as that process controls the security system for everything it's game over. The assumption here is that the FS is the root of trust for the kernel. (A claim I consider dubious, but what do I know about knowing things?) It's another way to say that if…

Ah, I'm not saying we can't have nice things or build more secure software. I think we can build more secure software! But the argument I'm responding to is one that I've seen many times over the years on HN and elsewhere, which is some form of "capability based programming languages fix everything". It's always posited as obvious and easy, as if merely saying "capability based language" is the only explanation required and somehow the entire software industry just missed the memo. Sometimes microkernels often come along for the ride, but not always.

You're completely right that the root of trust has to be secured. I argue that the core filesystem is indeed a part of the ROT, which is why e.g. Apple has put so much effort into making it immutable and fully tied to a cryptographic root hash that's checked by the secure boot process. Moving the FS out of the core kernel wouldn't change much though - if you have a bug in your FS code at runtime then you're just SOL even if everything is arranged in a Merkle tree.

The argument being made by josephg in the sibling comment is that in SEL4 or similar the page cache would be separated from the crypto code. And maybe he's right, but the better way to get the same outcome is to not have IPsec in the kernel rather than not have the core FS - as the latter is a ROT and IPsec isn't.

I disagree that the question of what "getting hacked" means is a reformulation of trust roots. A threat model isn't the same thing as a root of trust. The argument over what appears to be minor semantics is important because it scopes your goals and effort. One of the most common failure modes I've seen in security projects is not defining a threat model up front, often leading to an automatic fallback to "the threat model contains everything" followed by despondency and failure when it turns out to be impossible.

I don't think Apple or Microsoft care much about Linus' opinions tbh. Both NeXT/macOS and Windows NT started out as microkernel designs and all of them have oscillated back and forth over the years. The original concept was indeed far too slow and a lot of functionality went back to monolithic. Then over time some functionality got lifted back out e.g. the GUI subsystem on Windows. Core FS remains though in any OS as the cost/benefit ratio of moving it is so poor.

Post reply on HN