4 ms·

Heartbleed isn't a memory safety issue though, which is what kicked this off. You're right in your original reply to me that if you want to go reuse buffers wit

Heartbleed isn't a memory safety issue though, which is what kicked this off. You're right in your original reply to me that if you want to go reuse buffers with leftover data, you can do that in any language. If you want to create a byte array in Java, fill it with private key material, then reuse the same byte array for an output buffer... what can stop that? But more to my point: in C, I could end up executing arbitrary code by misparsing a network packet. In Rust, the worst I'll do is parse it wrong send invalid data onwards. That's just a massive reduction in scope. I suppose if you have a tool that writes to arbitrary, attacker-supplied file locations, that could have a severe impact. Or it could pass an attacker-controlled value to the shell without escaping. But things like the cpio[1] bug mentioned in the lessopen issue. Or the numerous compression libraries that require trusted inputs. Image manipulation code. And on and on. How many of them become simple crashes with a memory safe language? Cause from my unscientific (and flawed as this entire article is about) review, it seems like the great majority are these memory safety issues. Perhaps 90%? For widespread code, am I that far off the mark? (I understand that most intranet or custom software might just eval() every querystring given to it.) 1: http://seclists.org/fulldisclosure/2014/Nov/74 http://seclists.org/fulldisclosure/2014/Nov/74

AnthonyMouse 12y ago
> Heartbleed isn't a memory safety issue though, which is what kicked this off. It kind of is. It's just not of the type that "memory safe" languages fix for you, which is basically the point. If you define the scope of the problem in terms of what the proposed solution fixes then it tautologically fixes the entire problem, but it's still very important for people to understand that that doesn't mean it fixes every problem in that class. > in C, I could end up executing arbitrary code by misparsing a network packet. In Rust, the worst I'll do is parse it wrong send invalid data onwards. This is essentially what I'm talking about. It's still possible to execute arbitrary code in Rust, it's just not as easy. An obvious example is if your parsing bug is in the code that validates attacker-provided input before doing something sensitive with it. Or allows the attacker to flip a bit which is equivalent to remote code execution, like giving the attacker's account admin rights. And even if "the worst" you do is parse it wrong and send invalid data, that's Heartbleed. The "invalid" data could be secrets. The question you have to ask is, for all those memory corruption bugs in C, what does "memory safe" turn them into? They're still bugs, they're just not the same bugs. For example, a common way you get RCE in C is an integer overflow that leads to a heap overflow when the overflowed integer is used to allocate a buffer. But take away the heap overflow and the integer overflow is still there. Exploiting an integer overflow is highly context-dependent, but it's commonly possible regardless of whether it leads to a heap overflow. Being able to truncate the amount of Bitcoin being debited from the attacker's account or convert "username=rootxxxx" into "username=root" is arguably better than straight RCE, but not by very much.

AnthonyMouse 12y ago

> Heartbleed isn't a memory safety issue though, which is what kicked this off. It kind of is. It's just not of the type that "memory safe" languages fix for you, which is basically the point. If you define the scope of the problem in terms of what the proposed solution fixes then it tautologically fixes the entire problem, but it's still very important for people to understand that that doesn't mean it fixes every problem in that class. > in C, I could end up executing arbitrary code by misparsing a network packet. In Rust, the worst I'll do is parse it wrong send invalid data onwards. This is essentially what I'm talking about. It's still possible to execute arbitrary code in Rust, it's just not as easy. An obvious example is if your parsing bug is in the code that validates attacker-provided input before doing something sensitive with it. Or allows the attacker to flip a bit which is equivalent to remote code execution, like giving the attacker's account admin rights. And even if "the worst" you do is parse it wrong and send invalid data, that's Heartbleed. The "invalid" data could be secrets. The question you have to ask is, for all those memory corruption bugs in C, what does "memory safe" turn them into? They're still bugs, they're just not the same bugs. For example, a common way you get RCE in C is an integer overflow that leads to a heap overflow when the overflowed integer is used to allocate a buffer. But take away the heap overflow and the integer overflow is still there. Exploiting an integer overflow is highly context-dependent, but it's commonly possible regardless of whether it leads to a heap overflow. Being able to truncate the amount of Bitcoin being debited from the attacker's account or convert "username=rootxxxx" into "username=root" is arguably better than straight RCE, but not by very much.