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

The Insecurity Industry

edwardsnowden.substack.com

Post reply on HN
Print view View original

361–370 of 386 posts

Re: The Insecurity Industry

#361

Post by kragen »

neolog wrote: post #359
kragen wrote: post #357

Earlier quoted context omitted.

Not if publishing FOSS with bad configuration defaults makes you the defendant in a multi-million-dollar class-action privacy-invasion lawsuit.

It won't. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFT…

I just answered this: https://news.ycombinator.com/item?id=27971504

Re: The Insecurity Industry

#362

Post by the_why_of_y »

h_anna_h wrote: post #346
roca wrote: post #162

Earlier quoted context omitted.

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, excep…

> The CompCert C reference interpreter aborts execution on undefined behavior.

A C interpreter is not exactly the sort of thing that the embedded software industry has been waiting to deploy in production.

Re: The Insecurity Industry

#363

Post by 2OEH8eoCRo0 »

pseudalopex wrote: post #84
2OEH8eoCRo0 wrote: post #13

Edward Snowden is a traitor or a coward. Daniel Ellsberg gave the pentagon papers to the press after trying to give them to Congress. He then fought the govt in court and won. Ellsberg is a patriot.

John Kerry said the same thing nearly. Ellsberg called it disingenuous or simply ignorant.[1] [1] https://www.theguardian.com/commentisfree/2014/may/30/daniel...

I'm aware and I disagree with Ellsberg on this.

Re: The Insecurity Industry

#364

Post by pyuser583 »

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…

I find the idea of resource security very interesting - I haven’t heard of it before.

Isn’t that the opposite of secure? Pulling resource allocations out of the kernel and putting it into user land?

Re: The Insecurity Industry

#365

Post by pyuser583 »

abecedarius wrote: post #348
7373737373 wrote: post #175

Earlier quoted context omitted.

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

The compiled byte code in the file system is accessible and reversible, yes. But not once the interpreter has imported it.

A subsequent import could patch the Python object namespace, but that’s normal and intended.

If a program has access to the byte code files, it presumable has access to the actual .py files, and can easily change them to do whatever mayhem it wants.

Re: The Insecurity Industry

#366

Post by andrekandre »

kragen wrote: post #230
pjmlp wrote: post #208

Earlier quoted context omitted.

Nope, they only need to uphold to the same standards. The guy selling food on the street has the same liability as a restaurant.

The guy selling food on the street has liability in proportion to his profits; fifteen customers, fifteen potential food-poisoning cases. He can set his prices accordingly. Simon Tatham doesn't have any profits, but his PuTTY is installed on every developer's Windows machine. OpenSSL is installed on even more machines. How long do you think it would take your proposed regulatory regime to find that Kurt Roeckx owed s…

  Simon Tatham doesn't have any profits, but his PuTTY is installed on every developer's Windows machine.
then isnt it up to the commercial vendor who bundled the software to properly vet it?

someone taking non-commercial products and commercializing it is where the line is drawn right?

Re: The Insecurity Industry

#367

Post by collinmanderson »

raxxorrax wrote: post #318
pjmlp wrote: post #188

"If you want to see change, you need to incentivize change. 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. If you want to give Facebook nightmares, talk about the idea of making it legally liable for any and all leaks of our personal records that a jury can be persuaded were unnecessarily collected. Imagine how quick…

I disagree with Snowden here. Liability is an extremely bad approach and would not solve the problem at all. It would also fortify companies that can pay for guarantees nobody could ever give. That we have security flaws is always inevitable. Better languages might help but are no panacea. I agree with Snowden on a lot, but this doesn't solve anything. The result would be software certificates. By whom? Take a guess.…

> The problem with iMessage wouldn't be solved by liability. It is a security flaw that cannot be removed by law.

If they had financial incentives to not get hacked, it would make more financial sense to port non-memory safe c and c++ code to swift and rust. (Currently way too much effort to be worth it.) It would also incentivize better security layers like sand boxing.

Re: The Insecurity Industry

#368

Post by abecedarius »

pyuser583 wrote: post #365
abecedarius wrote: post #348

Earlier quoted context omitted.

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

The compiled byte code in the file system is accessible and reversible, yes. But not once the interpreter has imported it. A subsequent import could patch the Python object namespace, but that’s normal and intended. If a program has access to the byte code files, it presumable has access to the actual .py files, and can easily change them to do whatever mayhem it wants.

You totally can create bytecode and jump into it from Python, no .py files needed. See https://codewords.recurse.com/issues/seven/dragon-taming-wit... where types.CodeType gets invoked.

Re: The Insecurity Industry

#369

Post by jazzyjackson »

renewiltord wrote: post #60
c-cube wrote: post #59

Earlier quoted context omitted.

Maybe it's because real engineering has higher stakes than a crud app. Condos can kill, bridges can kill, Javascript forms or video game engines generally can't. If they could we'd witness a lot more deaths, despite your confidence.

I have a personal philosophy: "if you can't do it well, don't do it at all". That's because I prize my ability at what I do. I am good at it. I am a craftsman. Not like these fly-by-night characters busy dropping concrete on people's heads. Maybe I need to teach these "real engineers" something about building things haha: "If you can't do it without killing people, don't do it". Man, that's a motto for the ages. You'…

I see an awful lot of skyscrapers not falling down every day, stands to reason some engineers are good at what they do, no?

Re: The Insecurity Industry

#370

Post by eru »

kragen wrote: post #288
eru wrote: post #265

Earlier quoted context omitted.

Hmm, I think so, too. But it weakens your argument a bit. Basically, it would only convince people who are already convinced.

How would you make the argument?

Not sure, it's hard, since we seldom have randomised controlled experiments here.

Perhaps try looking for natural experiments, eg compare between countries, or between different sectors.

(Sometimes there's also silly legislation you can exploit for statistics, like the Onion Futures Act (https://en.wikipedia.org/wiki/Onion_Futures_Act) which can help to see the impact of futures trading on commodities.

Perhaps there's some corner of the pharmaceutical market that wasn't hit or was less hit by the Pure Food and Drug Act?)

Post reply on HN