The Insecurity Industry • Hacker News Board

Re: The Insecurity Industry

#341

Post by pjmlp » Tue, Jul 27, 2021, 4:05 PM UTC

LargoLasskhyfv wrote: post #329

pjmlp wrote: post #196

Earlier quoted context omitted.

Unisys still sells Burroughs to customers that care about top level security. https://en.wikipedia.org/wiki/Burroughs_large_systems ESPOL/NEWP were the very first system programming languages to have UNSAFE code blocks, 10 years before C was even an idea. Before that there was JOVIAL as well, https://en.wikipedia.org/wiki/JOVIAL

Hasn't that morphed into some sort of emulation nowadays? Like almost COTS(common of the shelf) Xeon, running some hypervisor and the 'legacy' within? Similar to what Symbolics did with Genera for Alpha? edit: [1] https://microsites.unisys.com/offerings/clearpath-forward [2] https://docs.microsoft.com/en-us/azure/architecture/example-... Azure?! Err...sure...

First of all it depends on the customer deployment scenario.

Secondly, having an issue with number 2 cloud provider at world scale?

Or would you rather have AWS?

Re: The Insecurity Industry

#342

Post by pjmlp » Tue, Jul 27, 2021, 4:08 PM UTC

eurg wrote: post #249

pjmlp wrote: post #246

Earlier quoted context omitted.

That is for the law makers to decide, If someone gets run down by a bicycle that a hobby repair shop failed to fix, it doesn't matter it was done for free by a guy that learned to repair bicycles during late nights.

The hobby repair shop can only be liable for a very small number of bikes, those they worked on. You cannot restrict the number of users of free source software, and you cannot restrict the user's risk profile. Like "good enough for an offline arcade game, but nothing else". Analogies have their limits. But yes, lawmakers will decide, and given that they for instance try to de facto prohibit aftermarket OpenWRT insta…

Sure and so what?

The company selling me a car is responsible to validate the security of each piece they got from a third party, and a restaurant is responsible to take care for the quality of the food it buys from the local bazar.

Re: The Insecurity Industry

#343

Post by [deleted] » Tue, Jul 27, 2021, 4:09 PM UTC

wly_cdgr wrote: post #303

imwillofficial wrote: post #131

Earlier quoted context omitted.

The design process is pretty rigorous. Anything to back up your idea?

Challenger, Columbia (safety culture at NASA really improved after Challenger huh), Chernobyl, Three Mile Island, Fukushima, recent FL condo collapse, my average five story Brooklyn apartment building's basement and roof after a thunderstorm, Boeing's long and growing list of recent fuckups... is some stuff that comes to mind off the top of my head. Makes you wonder how many close calls, less major incidents, cracks…

[deleted]

Re: The Insecurity Industry

#344

Post by pjmlp » Tue, Jul 27, 2021, 4:09 PM UTC

raxxorrax wrote: post #322

pjmlp wrote: post #246

Earlier quoted context omitted.

That is for the law makers to decide, If someone gets run down by a bicycle that a hobby repair shop failed to fix, it doesn't matter it was done for free by a guy that learned to repair bicycles during late nights.

This is a completely unrealistic demand of software and security. I am really surprised of Snowdens arguments here. The law makers cannot make the internet safer by one bit. Technical experts can and lawyers would dream to have leverage against them. They should be denied.

Nope, it is a matter to apply the same liability process that are already in place for high integrity computing and enterprise project deliveries.

Re: The Insecurity Industry

#345

Post by smolder » Tue, Jul 27, 2021, 4:25 PM UTC

jodrellblank wrote: post #54

o8r3oFTZPE wrote: post #11

"For example, if you want to see Microsoft have a heart attack, talk about the idea of defining legal liability for bad code in a commercial product." That sort of discussion is quickly dismissed on HN. And probably elsewhere on the web/over the internet. Instead we frequently see discussion blaming users of the software, i.e., Microsoft's customers, or even suggestions to make the customer liable, or comments from "…

It is possible to build a bridge which doesn't fall down during normal use. Has any company demonstrated that it's possible to build large scale software with no security flaws in it? Microsoft haven't, Apple haven't, Google haven't, Facebook, IBM, Oracle, RedHat, Amazon, Cisco, Juniper, The Pentagon, The Whitehouse, The UK Government, the fact that we've heard of Snowden suggests the NSA haven't, banks haven't, airl…

> Not a tangent; Look at the recent discussion on HN about Windows Defender, and pretty much any security choice - it's full of people bemoaning Microsoft making decisions that are mildly inconvenient on the grounds of "how dare they think they know better than me", "I demand to be able to turn these security features off", "I want control to be able to do anything".

I think it's somewhat reasonable to complain about the approach taken to security in Windows. MS had a lot of work to do to stay on top as long as they did, but they were also extremely well resourced and dominant for a significant time, where they could have made bigger systemic changes to prevent swiss cheese getting released in the first place. They could've built their own rust-like language, maybe, built some great static analysis & fuzzing tools, or generally advanced their own internal exploit discovery to beat outsiders to the punch. That we've mostly settled for constant security updates upon exploit discovery in the wild and blindly assuming super old code is safe (until it isn't) seems like a failure to act (a failure of incentives?) and not a necessity.

Re: The Insecurity Industry

#346

Post by h_anna_h » Tue, Jul 27, 2021, 4:33 PM UTC

roca wrote: post #162

h_anna_h wrote: post #152

Earlier quoted context omitted.

This is false. There are multiple safe C implementations. compcert and https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html are two such.

Compcert is a verified compiler. It guarantees that the generated code does what the source code requires. It doesn't turn unsafe C programs into safe ones. "Fail-Safe C" is a research project that has been dead for ten years. Note: > Some benchmark results show that the execution time are around 3 to 5 times of the original, natively-compiled programs, in avarage That overhead is actually a lot higher than similar p…

The CompCert C reference interpreter aborts execution on undefined behavior.

> To be clear, when we talk about "an alternative implementation of C", it needs to give similar performance and other properties (e.g. function and data interop) to other C compilers. You can't impose a 3-5x slowdown and say "look, C is safe".

Pretty much every language (except rust) which claims to be "C but safe" has the same issue, except you have to rewrite your program in it.

Re: The Insecurity Industry

#347

Post by LargoLasskhyfv » Tue, Jul 27, 2021, 4:44 PM UTC

pjmlp wrote: post #341

LargoLasskhyfv wrote: post #329

Earlier quoted context omitted.

Hasn't that morphed into some sort of emulation nowadays? Like almost COTS(common of the shelf) Xeon, running some hypervisor and the 'legacy' within? Similar to what Symbolics did with Genera for Alpha? edit: [1] https://microsites.unisys.com/offerings/clearpath-forward [2] https://docs.microsoft.com/en-us/azure/architecture/example-... Azure?! Err...sure...

First of all it depends on the customer deployment scenario. Secondly, having an issue with number 2 cloud provider at world scale? Or would you rather have AWS?

That's not what I meant to say. It doesn't matter which cloud provider at all, if the product running on it is an emulation. All the assurances you spoke of regarding early Burroughs Large Systems resulted from hardware/software co-design. The hardware does not exist anymore. They ported some abstraction layer by whichever means to contemporary platforms, and now top that by making it available to the cloud, saying: 'Diz iz good! We king of the mainframe hill, Ugga Ugga!'

I wouldn't trust that. The same way I wouldn't trust that from another, very established competing vendor, saying the same things, having the same nimbus of security and reliability.

Because sometimes there are blips on my radar, wherein some conference talk pops up, and people looked under the rugs of these systems, not even hard, just casually, and discovered some oopsies.

So it seems like that nimbus of security and reliability is more a result of very careful isolation from public networks on one hand, and inacessability for the bored and curious pranksters of the world on the other. But it is no absolute.

Especially if it's running in emulation on contemporary COTS hardware. (In the EFFING cloud!)

Just my not so humble opinion, though.

Re: The Insecurity Industry

#348

Post by abecedarius » Tue, Jul 27, 2021, 4:45 PM UTC

7373737373 wrote: post #175

pyuser583 wrote: post #151

Is Python a safe language? It doesn’t seem to have the sorts of problems other languages do. Why is that?

Absolutely not, unfortunately. One of the architectural issues plaguing even comparatively memory-safe languages is the fact that there is a global scope that's accessible from anywhere. In some Python versions even numbers or truth values could be redefined. [0] This makes it impossible to sandbox functions or imported modules, because they can communicate arbitrarily. But communication/access security is not the on…

CPython is not even memory-safe. The compiled bytecode is accessible to ordinary Python code able to replace it with 'incorrect' bytecode that causes out-of-bounds memory access by the C interpreter.

(Presumably an unusual thing to do -- I've seen libraries doing bytecode hacks but I'm not sure how popular any of them are.)

Re: The Insecurity Industry

#349

Post by mikepurvis » Tue, Jul 27, 2021, 4:52 PM UTC

dylan604 wrote: post #339

mikepurvis wrote: post #337

Earlier quoted context omitted.

I'm not doubting that it might happen and may even actually happen in some cases. I'm asserting that society and government is built on compromises and a principle of taking the path of least harm. We shouldn't avoid a 90% solution because we can imagine possible flaws in it, particularly if we have close analogues already deployed in the real world and those flaws don't largely seem to manifest. I don't know that bo…

>the regulation provided by the FAA isn't perfect, so it shouldn't exist This is far from what I'm suggesting. I'm just saying that if it is a gov't regulated anything, those regulations will incur wacky decision making due to the influence of outside money. Nobody likes to be regulated against, and if they are in the position to do so, they will use any mechanism available to them to keep the status quo. I'm also su…

But despite your cynicism about "any gov't regulation body", you would agree that professional associations have by and large been a success in protecting the public in areas like construction trades, engineering, law, and medicine?

Re: The Insecurity Industry

#350

Post by bob1029 » Tue, Jul 27, 2021, 4:58 PM UTC

ncmncm wrote: post #312

bob1029 wrote: post #306

> The greatest danger to national security has become the companies that claim to protect it No. The greatest danger is lack of software supply chain management followed by near-universal disrespect for formal complexity management methods. The only way I have found to win at this "are we actually secure" game is to minimize the number of parties you have to trust. The smaller you get this figure, the easier it becom…

There is no supply-chain accountability without liability. When adding a dependency, knowing it exposes you to prosecution if it becomes a vector for security violation would give pause. A premium on attested-secure components might develop. If Facebook depended on Zst being secure to be able to stay in business, we might be more inclined to use Zst than e.g. unmaintained Zlib.

> A premium on attested-secure components might develop

Isn't this effectively the Microsoft/IBM/Oracle ecosystem play?