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

141–150 of 386 posts

Re: The Insecurity Industry

#141

Post by jchook »

imwillofficial wrote: post #131
wly_cdgr wrote: post #102

I doubt "real" engineering is better. It's just that attacking its artifacts doesn't scale, so it looks more secure. In fact, the average bridge or skyscraper is probably absolutely riddled with serious design and manufacturing flaws

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

Not necessarily agreeing but reminded of the Harvard Bridge in Boston.

I heard that though it was often called the MIT bridge (because it connects MIT campus to Boston), they felt fine with the name “Harvard” after learning it was structurally unsound.

https://en.wikipedia.org/wiki/Harvard_Bridge

Re: The Insecurity Industry

#142

Post by staticassertion »

wly_cdgr wrote: post #102

I doubt "real" engineering is better. It's just that attacking its artifacts doesn't scale, so it looks more secure. In fact, the average bridge or skyscraper is probably absolutely riddled with serious design and manufacturing flaws

I'm not a civic engineer, but I know some, and that doesn't ring true. I know, for example, that with regards to the NYC subway post-9/11 there was rigorous work to plan and implement safety measures against various terrorist threats. That included modeling the impact of various types of bombs in different parts of NYC's subway tunnels, etc.

This work was mandated for projects that were, in aggregate, likely billions of dollars.

Re: The Insecurity Industry

#143

Post by littlestymaar »

platinumrad wrote: post #127
3pt14159 wrote: post #35

I'm not going to comment on Snowden's view of what liberal western states do when it comes to surveillance. I have my own opinion, but he's been right about stuff I'd disagreed with him in the past before so I'm gun shy about confronting his ideas again. On the topic of unsafe language though, he's absolutely right. We don't have to put up with this. We could pass a law and ban new code in unsafe languages from natio…

You have an awfully rosy view of how regulation of programming languages would play out. What will happen (and this is already de facto the case in many "safety-critical" industries) is that Rust is banned and everyone is forced to write straightjacketed C89 and C++03. There's already a congressman on the record complaining about a "native Nigerian" committing code to Rust.

> There's already a congressman on the record complaining about a "native Nigerian" committing code to Rust.

Wow. It comes from the Libra hearing I guess? By any chance, do you have an link to the exact quote?

Edit: as hsod answered below (I don't really get why this answer was flagged) the congressman isn't really “complaining” and it's not about a Nigerian committing to Rust, but to Libra itself.

Re: The Insecurity Industry

#144

Post by staticassertion »

novok wrote: post #30
zozbot234 wrote: post #17

Earlier quoted context omitted.

Go is not safe for concurrent code, unfortunately. Specifically, it does not protect against data races on non-atomic types, which can lead to torn writes and break invariants that are required for safety.

Can you do a security exploit with a concurrency bug although in golang? You may corrupt data, but can you cause remote code execution with it?

To be clear, yes. The issue is with how Go's "interface{}"s (and some other types - like slices, etc) work - it's two pointers that can't be written to atomically, which means you can get into a situation where your objects are invalid.

https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

Here you can find a POC.

You could argue that this is contrived, but it's also not going to be fixed. This is in contrast to Rust, where there may be implementation flaws leading to unsafety in safe code, but the language retains the right to fix those, even if it breaks code.

Still, I think there's really no question that Go is a major step up over C and C++.

Re: The Insecurity Industry

#145

Post by littlestymaar »

conradev wrote: post #134
nine_k wrote: post #126

Earlier quoted context omitted.

Funny that you ask: Linux kernel rather actively embraces experimental code written in Rust. And yes, for a really critical system I might consider taking something much simpler and potentially slower but formally proven correct, like seL4. Google is working on Fuchsia as a new phone / chromebook OS, and it's very much focused on bulletproof security.

While Fuschsia's microkernel architecture has a lot of security benefits, the microkernel (Zircon) is still written in C++

Related:

> Our kernel, Zircon, [is not in Rust](https://twitter.com/cpuGoogle/status/1397265884251525122). Not yet anyway. But it is in [a nice, lean subset of C++](https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/...) which I consider a vast improvement over C.

https://blog.cr0.org/2021/06/a-few-thoughts-on-fuchsia-secur...

Re: The Insecurity Industry

#146

Post by staticassertion »

MichaelMoser123 wrote: post #128
3pt14159 wrote: post #35

I'm not going to comment on Snowden's view of what liberal western states do when it comes to surveillance. I have my own opinion, but he's been right about stuff I'd disagreed with him in the past before so I'm gun shy about confronting his ideas again. On the topic of unsafe language though, he's absolutely right. We don't have to put up with this. We could pass a law and ban new code in unsafe languages from natio…

Where is your legislation supposed to draw the line? In Rust you need to have occasional unsafe code - you can't even have a double linked list or bidirectional graph without unsafe code. Would you also outlaw jni calls in java?

The way this would likely end up being handled is the same as any other compliance.

You define the threat model for your application and then justify why you're safe. In this case we'd be adding an explicit point to ensure that there are controls for attackers who can exploit memory safety issues.

You could end up with controls like:

1. We sandbox our code, so even though it's C we feel that we're safe

2. We use a memory safe language to reduce the risk of memory safety issues

3. We sanitizer inputs before providing them to the program

etc etc

What ends up being accepted as legitimate would be up to the auditors/ generally a matter of consensus.

Re: The Insecurity Industry

#147

Post by cf499 »

ramraj07 wrote: post #89
rognjen wrote: post #82

While his message is undoubtedly important I find his writing style is overly condescending and detracts from the message.

He probably has earned the right to be condescending as much as say Linus has. Dude risked it all to expose what he thought was wrong, and only someone as smart as him could have managed to stay alive and out of jail (albeit barely) facing off the most powerful country in the world.

"He probably has earned the right to be condescending as much as say Linus has."

It's not about rights, it's about desires and personal insecurities. People who derive pleasure from condescension are just telling you that they're vulnerable to manipulation via flattery. It's bad opsec! :P

Re: The Insecurity Industry

#148

Post by FractalHQ »

MichaelMoser123 wrote: post #128
3pt14159 wrote: post #35

I'm not going to comment on Snowden's view of what liberal western states do when it comes to surveillance. I have my own opinion, but he's been right about stuff I'd disagreed with him in the past before so I'm gun shy about confronting his ideas again. On the topic of unsafe language though, he's absolutely right. We don't have to put up with this. We could pass a law and ban new code in unsafe languages from natio…

Where is your legislation supposed to draw the line? In Rust you need to have occasional unsafe code - you can't even have a double linked list or bidirectional graph without unsafe code. Would you also outlaw jni calls in java?

Can’t unsafe Rust (when properly isolated) exist within a larger codebase that, as a whole, can still be considered safe?

Re: The Insecurity Industry

#149

Post by staticassertion »

jonas21 wrote: post #105
lifeisstillgood wrote: post #40

I tend to bang on about software not as engineering but as literacy. It makes some sense even here - that bad code is as common as bad law - and often for the same reasons, politics, money, and hard questions "Engineering" is a wide subject - the big stuff is carefully built and highly regulated - bridges and buildings. But as we go down the scale we see engineering give way to the problems of politics and money - to…

Also, traditional engineers design things to withstand conditions that they would reasonably face in ordinary use, with some additional safety factor. They don't design them to withstand deliberate attacks by nation-level actors like we're seeing here. If a car explodes because it got hit by an artillery shell, would anyone hold the automotive engineers responsible? If a building collapses because a bomb was dropped…

I hope it's clear that there's a major difference between a car being hit by an artillery shell (extremely rare) and a nation state attacker exploiting software (extremely common).

Re: The Insecurity Industry

#150

Post by littlestymaar »

ManuelKiessling wrote: post #139
dcow wrote: post #108

Earlier quoted context omitted.

Substack replies are paid? Hmm. Thinking about this right now: annoying sure but why do you consider this pattern dark? I bet it reduces spam and trolling by orders of magnitude unlike say confusing cookie dialogs designed to make you surrender all your private info.

The dark pattern is that you don’t know it beforehand, not the paywall itself.

You know before typing your comment though. The real dark pattern would be if it had let you type and then ask for money to submit your comment.
Post reply on HN