Comment by armitron | Hacker News Reader

Comment by armitron | Hacker News Reader

It boggles the mind how utterly misguided the "let's rewrite everything in Rust!" people are when it comes to understanding security and its implications.

Let me begin by introducing my premise: Rust will do NOTHING for security, it is not an improvement in any way, and at least as far as security is concerned, it will lead to at best colossal time waste, at worst actively damage the cause by misdirection, making ppl feel warm and fuzzy, providing illusion of security.

What??? B-b-but memory safety, I hear you say. How can this even be possible I hear you cry.

Memory safety (assuming that Rust completely solves it, which it absolutely DOES NOT) is but one (small) piece of the entire puzzle. In the same way that the skilled craftsman knows that he can't build a castle on top of sand, the skilled (and security conscious) software engineer should realize that memory corruption (and race conditions in the same unit/process) are not the foundation of the security chain. I dare say that a lot of the bugs exploited out there today (but not necessarily made public), are pure LOGIC bugs (that include race conditions) that stem from the interactions between extremely complex autonomous subsystems. Rust is simply operating at a too high-level abstraction layer to deal with any of these issues. This is the logical progression of Sergey Bratus's weird machines taken to the next level.

Some examples:

The Linux kernel. Any UNIX operating system taken as a whole. Any Windows taken as a whole. Any OSX system.

Anything built on top any of the above. Anything built on combinations of any of the above. Weird machines are not limited to isolated units, you know, they very well exhibit EMERGENT behavior.

Are you starting to get the picture now?

And then of course we still have the bugs that stem from unsafe languages, as long as there's a path that cuts through all the intermediate layers of "safe" code. Graphics drivers and webgl anyone? Truetype in the kernel?

Rust has plenty of things in its favor but to position it as a cure for issues that it doesn't even know how to address is a colossal mistake. We have given rise to a beast that threatens to consume us all. It's one thing to despair due to the immense complexity of the domain and quite another to step into an imaginary realm and solve illusionary problems that we create just to feel "safe".

There were about 36 000 traffic fatalities in the US in 2015. This is inherent to the trillions of miles traveled in affordable machines operated by drivers of variable competence, and nobody has a solution to fix the problem today. Maybe one will emerge, but between now and that day we're going to keep driving and keep killing each other.

Should engineers, admittedly lacking an absolute solution to traffic fatalities, forego seeking designs and materials that reduce the frequency and consequences of failure?

Rust delivers a higher degree of memory safety. It is a better tool in the tool box and arguing that engineers should ignore it because their efforts are inherently flawed won't work, any more than arguing that a new headlamp or traffic light design is futile.

Also, you should understand now what you're up against. The legacy stack is riddled with flaws; every day we face a deluge of security notices, some large fraction of which are caused by memory safety problems. In other words, your opponents in this debate have an endless supply of ammunition.

Good luck with that.

> here were about 36 000 traffic fatalities in the US in 2015

> nobody has a solution to fix the problem today.

You're entire premise revolves around 0.01% of the population. That's not a good basis.

There's about 34,000 automobile related deaths annually in the US[1]. There's about 323,000,000 people in the US.[2]

The point I'm making, is let's not get carried away with exaggerating how "bad" a "problem" is. According to the CDC, more people die annually from accidental poisoning (about 39,000) than automobile related accidents - but I don't hear all the calls to "solve" that problem.

Will things be "safer" written in Rust? Maybe. Does Rust solve everything? Absolutely not. Yes, a lot of bugs are "unsafe" memory access issues, but a lot of bugs are not. Re-writing everything in a pet language that happens to be popular today in 2016 is not a good call. Rust is fairly new, and nobody has any idea if it will stand the test of time. C has, clearly.

Instead of getting out our pitchforks, we should rally to guarantee these critical projects are fully funded and staffed with full time developers. That alone, will yield far greater results than some lofty goal of completely re-writing 100's of thousands of lines of code which have been working, tested, and matured for almost 3 decades.

[1] http://www.cdc.gov/nchs/fastats/accidental-injury.htm

[2] http://www.census.gov/popclock/

"Poisoning" in the CDC statistics includes alcohol poisoning and drug overdoses [1, table 18, also see definitions of codes X40-49 and X60-69]. There've been plenty of public health initiatives against this, notably: Prohibition, the War on Drugs, DARE, child-proof pill bottles, pharmacist licensing, the [poison control] OneBox on Google, etc.

I think that's pretty good evidence of the grandparent's point: no, you're never going to make anything completely safe, but society can and does put a lot of effort toward harm reduction.

[1] http://www.cdc.gov/nchs/data/nvsr/nvsr64/nvsr64_02.pdf

You're entire premise revolves around 0.01% of the population. That's not a good basis.

Mine is the basis of billions of dollars of engineering and untold amounts of legislative and regulatory efforts around the planet. A lot of people seem to think it's a pretty important basis.

let's not get carried away with exaggerating how "bad" a "problem" is

On one hand you ask others not to exaggerate, next you're talking about pitchforks. The story we're discussing is about someone reimplementing one little 300 line procedure. I made no more of Rust than to call it a better tool in the toolbox. Calm yourself; these pitchfork wielding exaggerators you speak of are fictions inside your head.

stand the test of time. C has, clearly

The buffer overflows, dangling pointers, double frees, use after frees and leaks recorded daily as CVEs is the most demonstrative thing time has revealed about C et al. If C had past the test of time Rust wouldn't exist.

> Yes, a lot of bugs are "unsafe" memory access issues, but a lot of bugs are not.

A huge number are. For example: https://www.cvedetails.com/vulnerability-list/vendor_id-72/p...

> That alone, will yield far greater results than some lofty goal of completely re-writing 100's of thousands of lines of code which have been working, tested, and matured for almost 3 decades.

Windows, the popular Web browser engines, and antivirus software are all examples of systems software that are very well funded. But they still regularly fall to memory safety problems. The converse is also interesting to look at: djbdns and qmail are examples of poorly funded software, but they have had very few memory safety problems.

I agree with the general principle that funding helps security overall, though.

I have trouble understanding what you try to say - but a library like glibc must not have memory corruption problems to start with. Clearly, it seems that currently it has those problems. Either you can find maintainers for the C code which will never create a memory corruption problem, or use a tool which assists the maintainers with this. Also, more modern languages than C would in general make the code more maintainable, again helping with weeding out security problems, be they coming from memory corruption or any other cause.

> Memory safety (assuming that Rust completely solves it, which it absolutely DOES NOT) is but one (small) piece of the entire puzzle.

Visit https://www.cvedetails.com/vulnerability-list/vendor_id-72/p.... Count the number of memory safety issues. The first five, for example, are all memory safety problems.

Viewing Rust as a panacea for security issues is certainly misguided. However, people should at least attempt to use a more memory safe language to write this stuff. If it proves to be worse code, then we're not forced to use it - we already have getaddrinfo to fall back on.

It boggles the mind how people think the only benefit of Rust is memory safety. Rust has novel features for solving concurrency issues, what you call "pure LOGIC bugs (that include race conditions)".

Of course memory safety is one small piece of the entire puzzle. That's why Rust has features besides just being a memory-safe version of C.

Read my post again cause you obviously didn't understand anything of what I wrote.

You can have 2 components written in 100% safe language with no memory corruption and no race conditions.

You can have security critical race conditions that arise out of the interaction of same components.

How is Rust or whatever solving this? It doesn't.

Rust isn't just a safe language. It has other features. For instance, it's a much more strongly-typed language. You can use strong type systems to solve that exact problem.

If you give me a more concrete example, besides "you can have race conditions," I can give you a more concrete way Rust fixes it, besides "you can use types."

You still don't get it (this exchange is a great example of how hard it is for ordinary technically-minded people to shift into the proper mindset and begin to understand what the real issues are).

The race conditions I refer to DO NOT EXIST in the static pieces of code written in Rust or whatever ivory tower language. They are EMERGENT pieces of DYNAMIC behavior that only manifest at RUNTIME due to subsystem interactions.

And by subsystem I don't just mean pieces of code...

Can you give a concrete example of a recent major security issue caused by the sort of dynamically emergent interaction you're referring to? Anecdotally, the hair-on-fire security issues in fundamental components that keep coming up always seem to involve unsafe memory usage.

Buffer overflows seem to be a pretty recurring theme in these security issues, yep.

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

Rowhammer is a very good point. Hrm.

Rowhammer is basically mitigated if you don't let untrusted processes run CLFLUSH, right? That's sort of orthogonal to your choice of programming language (which might be your point, but then, I'm not sure I believe that Erlang or unikernels solves this either). It requires a world in which you've got something Native Client-like wrapping all userspace processes, which definitely seems like a good goal to work towards, and also seems easier to implement reliably in Rust than in C.

Row_hammer

You're citing a hardware flaw as a reason not to pursue programming tools and techniques that produce fewer software defects? That's a false dichotomy; we don't forego researching cancer treatments just because some of the people that are saved will end up getting shot.

Earlier you wrote "Security is all or nothing".

That's another amazingly bad point of view. There is no "all." Nothing is absolutely secure. There is only raising the bar. Important things are provided more protection than less important things. That is the best that can ever be achieved. Since your premise relies on a fiction your conclusions about the value of Rust are meaningless.

I agree that they are emergent behaviors between multiple systems. I am claiming that these individual components can capture knowledge of other components via strong type systems, and thereby eliminate race conditions. Can you explain why this is untrue?

I am trying to shift my thinking, but all I'm hearing is "No it can't." Can you explain why it can't?

This reminds me of a post I once read arguing that type-safe languages weren't actually helpful, because they (generally) still let you write programs that could violate type safety. I thought that argument was silly, and I think yours is too. Yes, I'm quite confident that Rust isn't a panacea, anymore than functional programming will be, or object oriented programming has been, or type safety is. The point is that each of those techniques helps you to avoid certain classes of bugs. And so far as I can tell, Rust genuinely does have features that make writing certain kinds of bugs much less likely. Yes, Rust doesn't help you prevent every kind of bug. (Shocker!) But I don't get the point of insisting that decreasing an attacker's surface space isn't worthwhile.

Security is all or nothing. There are no in-between states. If there's something to get from all my posts, is that we need to learn to operate with the assumption of compromise in mind, plan for failures and learn to rebuild, rapidly. Rust simply solves the wrong problems.

For a language that certainly has the mindset, look at Erlang. Unikernels and Erlang will do more for actual security than a million monkeys cranking out perfectly safe Rust code.

"Decreasing an attacker's surface" is pragmatically, bullshit. No competent attacker (and that doesn't include just nation states these days) will be deterred by a decreased attack surface.

Practically, I think it's wrong to say "Security is all or nothing", with no in-between states. Most attacks and/or security bugs are built on a combination of problems. Anytime you fix one of those problems, you make it less likely that someone will find a chain of problems that ultimately allows them through. If you take the example of the Heartbleed bug (a classic buffer overflow), it would still be possible to have written it in Rust, but it would have been more difficult, and hence less likely. That's a worthwhile trait for a language to have.

I'm sorry, but this line of argument is not even wrong as it relates to the entire modern infosec field, which is founded on the fact that there is no such thing as "100% security"; that is why concepts such as "threat models" and "defense in depth" exist.

Also, proving a program "correct" (for some definition of correctness that presumably includes "secure") is undecidable, ergo there cannot be such a thing as a "100% secure language". No, not even Erlang, nor Haskell, nor anything which is remotely close to Turing-complete. So all we can do is, in fact, decrease the attack surface.

> No, not even Erlang, nor Haskell, nor anything which is remotely close to Turing-complete. So all we can do is, in fact, decrease the attack surface.

You often don't even need Turing completeness.

"How is Rust or whatever solving this? It doesn't."

Actually, yes, it does. The borrow checker composes. Two correct Rust components for race conditions and memory safety will indeed compose together correctly. That's a great deal of the point of the whole thing, after all.

I don't think you've been keeping up with the state of the art in the last few years. Maybe less yelling and more listening is called for here.

One of my personal internet observations is that any post containing the formulation "b-b-but" is a bad one. Usually betrays a sort of sarcastic know-it-all attitude.

I see you've used it. I think it sets a bad tone for an argument.

My rule for internet observations is, any post containing "you" is argumentative and off topic. The topic is never the other commenter. Using "you" is often received as a personal affront, derailing the conversation. It betrays a me-vs-you superior attitude?

Not a bad rule, I have to admit (and true in my case, my post was certainly off topic). As a general rule it's a bit broad though, I think. If one wants to address another's points directly, it can be hard to avoid the second person pronoun.

It takes practice. Addressing the points as points instead of something 'you' said is about all there is to it. But we're so used to conversational modes, its easy to fall back.

Reply on news.ycombinator.com