Live data from Hacker News

The Insecurity Industry

edwardsnowden.substack.com

161–170 of 386 posts

Re: The Insecurity Industry

#161

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…

As a professional software engineer I'm not sure the idea of "safe" or "unsafe" programming languages is a coherent idea, or if it is then all languages are unsafe in my eyes. Yes C/C++ have more footguns than Java but there's no "hard line" in the safety differences and there are real and important things that need doing that it's not always clear can be reasonably done in another language. If you haven't, I'd encou…

The line is far less blurry than you suggest. The stats from the article say 70% of vulnerabilities come from [insert list of a few memory-wrangling mistakes here]. I'd consider any language that enables the top 70% of vulnerabilities to happen to be unsafe.

Maybe a safety ranking is in order? How many CVEs from [year], weighed by severity, are impossible to happen in [language]. Obviously this idea has serious problems, but you see my point: C would get a straight up zero, as it should! (well, not completely zero, as many vulns come from dependencies and C's complete lack of a package and dependency system is actually an advantage here)

Re: The Insecurity Industry

#162
post #124

Earlier quoted context omitted.

That paper has many problems. For example: > There is no particular need to rewrite existing C code, provided the same benefit can be obtained more cheaply by alternative implementations of C To be clear, those "alternative implementations" do not exist , and no-one actually working on C compilers or tools to make C code safer has been able to produce one, or even come up with a credible plan for producing one.

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 projects I also consider failures, such as CCured.

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

Re: The Insecurity Industry

#163

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…

Even if we could clearly differentiate between "safe" and "unsafe" languages, what use cases and devices go on the list?

Would phones really be that high up given that in environments with high security standards usually people are not allowed to carry them? What about home appliances? Could a state actor hack a bunch of stoves and burn the houses down?

I can easily see some huge bureaucracy being put in place without much benefits ("Federal Programing Language Commission"?).

Most high security environments have a physical component, why not learn from there? Phones could just have a physical switch to cut off microphones and antennae for example, much easier to do than trying to police millions of lines of codes to be secure.

Re: The Insecurity Industry

#164

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

There are at least two things that could be contributing to this perception:

1. Python is (usually) an interpreted language, and it's probably true to say that interpreted languages tend to have a lower attack surface (at the cost of lowered performance).

2. While Python is very popular in certain domains (numerical computing, ML etc), there are few low-level systems that are written in Python.

Re: The Insecurity Industry

#165
post #124

Earlier quoted context omitted.

As a professional software engineer I'm not sure the idea of "safe" or "unsafe" programming languages is a coherent idea, or if it is then all languages are unsafe in my eyes. Yes C/C++ have more footguns than Java but there's no "hard line" in the safety differences and there are real and important things that need doing that it's not always clear can be reasonably done in another language. If you haven't, I'd encou…

That paper has many problems. For example: > There is no particular need to rewrite existing C code, provided the same benefit can be obtained more cheaply by alternative implementations of C To be clear, those "alternative implementations" do not exist , and no-one actually working on C compilers or tools to make C code safer has been able to produce one, or even come up with a credible plan for producing one.

Of course they exist, see eg CHERI: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

Re: The Insecurity Industry

#166
post #126
post #122

Earlier quoted context omitted.

Would you refuse to use Postgres, the Linux kernel or SQLite because they’re all written in C? Certainly C and C++ have more footguns than many other languages, but highly insecure as well as highly secure software gets written in all languages. I think coming up with better/easier avenues for digital-security-breach related lawsuits and fines is a better idea than banning specific languages.

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.

> Linux kernel rather actively embraces experimental code written in Rust

False. Which broken telephone did this come from? The Linux kernel has 0% Rust code in it and has no plans to change that.

Re: The Insecurity Industry

#167
I find Snowden's take on software engineering to be poorly reasoned and internally inconsistent.

The most important fact related to his argument is one he doesn't even bother mentioning, namely that Android is mostly written in a memory safe language (Java). The thing he's asking for already exists and is deployed on most smartphones worldwide, yet all he has to say on the topic is this:

"While iPhones are more private by default and, occasionally, better-engineered from a security perspective than Google’s Android"

You cannot claim to be a spokesman for freedom, then demand memory-safe languages be used everywhere, and then praise the one system controlled exclusively by a single American firm that's written almost entirely in (Objective) C, a memory unsafe language.

That sentence is the only mention of Android in the entire article, the word "Java" doesn't appear anywhere and he seems to think that Rust is the only memory safe language in existence. Why should I care about this guy's opinions? Java has been drastically more successful than Rust when it comes to making software memory safe. Nobody is gonna choose to write the next AirBNB in Rust other than for fashion reasons, because it'd simply be too unproductive. Developers already complain about Swift and its horrible compile times, Rust would be even worse.

If Snowden really cares about this topic, he should brush up his Java skills, download some OpenJDK early access builds and start experimenting with writing video codecs and 3D engines using the new vectorization, memory span and value types features. Java is getting the capabilities to do even higher performance work traditionally dominated by C++, but in ways that preserve memory safety. The engineering is very difficult and it's unclear if Google will ever adopt it into ART, but it's there for them if they want it.

Re: The Insecurity Industry

#168

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

If your building or structure is a public hazard, under existing legislation the government (at least in the UK) has the right to remove the hazard, up to and including demolishing your building, if you don't make it safe sufficiently fast.

I'm not a lawyer, but I don't see any language in the law that would exclude unsafe automated systems which are part of a building or structure.

Re: The Insecurity Industry

#169

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…

"Why KeyKOS is fascinating" - https://github.com/void4/notes/issues/41

Re: The Insecurity Industry

#170

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…

Would you consider assembly to be unsafe? High-level software written with low-level languages like this includes:

- Decoders and encoders for video, images, and audio - graphics libraries - Many parts of fast cryptographic libraries

This is typically for performance-related reasons.

Post reply on HN