4 ms·

I don't get your point, what are you trying to say? > What Tedbleed, as your article calls it, demonstrates is a bug similar to Heartbleed Similar but very di

by Trufa 12y ago

I don't get your point, what are you trying to say? > What Tedbleed, as your article calls it, demonstrates is a bug similar to Heartbleed Similar but very different in the severity. > but I would suggest that thinking that memory safety ends all security issues is a not good plan. Nobody said that. > The key is Unless you venture into the (explicitly demarcated) unsafe portion of Rust, you will not see memory exposure vulnerabilities like Heartbleed: the language does not prevent this. Sure, if you want to break it, you'll probably can, but you'll have all kinds of warnings before and the few lines where you actually do that, can be proofread the most times. There's nothing preventing you from writing common bugs the generate vulnerability either, but that's simply not possible. > Perhaps your post will stimulate Ted to go further with his example and write an erroneous complete TLS stack in Rust, showing how it too can do Heartbleed. Perhaps you agree that this can be done. Well, Rust may have a memory leak at some point in the future, no software is perfect, but that is one language, that will be review constantly, that is mainly memory safe, the other is one language that is not memory safe where thousands of developers are constantly writing code, inserting lots of heartbleed/memory kind of bugs. > Among the scariest mass vulnerabilities relating to total information disclosure, the Padding Oracle Attack, the BEAST attack, the compression flaw CRIME, none have to do with memory safety of languages. Rust there would not have helped one whit. That's not the point of the article, ted tries to say that hearbleed would be possible, author contradicts this as it shows how the vulnerability would be of different severity.

tedunangst 12y ago
The fixation on private keys puzzles me. While they were extractable in some cases, it was difficult. Stealing passwords and cookies was trivial however. And how does one use a stolen key? You have to intercept the traffic first. I can abuse a stolen password from anywhere in the world by using it to log in. Then I can read all your (email, etc.) and don't even need the private key. To differentiate these as "very different in severity" is I think quite misleading.
- e12e 12y ago
  > The fixation on private keys puzzles me. Really? The private key in asymmetric cryptography should never/is assumed to never be known to anyone other than the key-holder. Session keys are understood to be shared, and so are by definition not secure (equivalently, I can log my part of the "conversation" with a server, even if over TLS with PFS). So session keys, session cookies, transmitted data -- is always known by more than one party, a secret key should never be known by more than one party. It is true that most TLS server deployments don't enforce this -- they don't do the asymmetric operations in a trusted computing module, smart card etc -- but they should. They shouldn't store the key in ram, but they currently do. If you get the secret key, you can do many more things than merely intercept traffic. You can impersonate and fake traffic (fake evidence). In addition to all this, being able to read arbitrary memory controlled by the same process is also worse than being able to read stuff that is already being transmitted. This isn't strictly a Rust/other language issue (I imagine, but do not know, that one eg could sanely (if foolishly) share buffers across thread pools, and so potentially leak information across clients -- this would probably be a design error wrt. trust boundaries etc ... but no-one is arguing that any language can prevent design errors). As mentioned in other comments, privilege separation (a la openssh etc) is a great way to help leverage the os/kernel in order to enforce assumptions about the security primitives used. But that's a little beside the point.
  - tedunangst 12y ago
    In a general sense, yes. It would suck to lose your private PGP key and have someone send fake messages. Probably more so than losing any one (or few) encrypted messages. HTTPS is a little different. You need to verify you're talking to the real paypal.com, but that's so you know you're not sending your password to a stranger. paypal doesn't send signed emails, for instance. (maybe they should, but not with the website key, for sure). Stealing passwords and cookies is pretty much the end game for https private key theft. Is anyone willing to say that a bug which only leaks passwords and cookies is a minor issue? wrt heartbleed, there seems to be a gap between the "could happen" and "did happen" consequences. Besides the one test server pummeled with millions of requests, were any private keys actually compromised? On the other hand, we know yahoo passwords were compromised because people were doing it within hours of the heartbleed announcement. I'm more concerned with the latter. Yes, if I'm writing a sort function for vulnerabilities, "read arbitrary memory" is worse than "read some memory", but there should be some accounting for degree of difficulty as well.

by Trufa 12y ago

tedunangst 12y ago

The fixation on private keys puzzles me. While they were extractable in some cases, it was difficult. Stealing passwords and cookies was trivial however. And how does one use a stolen key? You have to intercept the traffic first. I can abuse a stolen password from anywhere in the world by using it to log in. Then I can read all your (email, etc.) and don't even need the private key. To differentiate these as "very different in severity" is I think quite misleading.

e12e 12y ago
> The fixation on private keys puzzles me. Really? The private key in asymmetric cryptography should never/is assumed to never be known to anyone other than the key-holder. Session keys are understood to be shared, and so are by definition not secure (equivalently, I can log my part of the "conversation" with a server, even if over TLS with PFS). So session keys, session cookies, transmitted data -- is always known by more than one party, a secret key should never be known by more than one party. It is true that most TLS server deployments don't enforce this -- they don't do the asymmetric operations in a trusted computing module, smart card etc -- but they should. They shouldn't store the key in ram, but they currently do. If you get the secret key, you can do many more things than merely intercept traffic. You can impersonate and fake traffic (fake evidence). In addition to all this, being able to read arbitrary memory controlled by the same process is also worse than being able to read stuff that is already being transmitted. This isn't strictly a Rust/other language issue (I imagine, but do not know, that one eg could sanely (if foolishly) share buffers across thread pools, and so potentially leak information across clients -- this would probably be a design error wrt. trust boundaries etc ... but no-one is arguing that any language can prevent design errors). As mentioned in other comments, privilege separation (a la openssh etc) is a great way to help leverage the os/kernel in order to enforce assumptions about the security primitives used. But that's a little beside the point.
- tedunangst 12y ago
  In a general sense, yes. It would suck to lose your private PGP key and have someone send fake messages. Probably more so than losing any one (or few) encrypted messages. HTTPS is a little different. You need to verify you're talking to the real paypal.com, but that's so you know you're not sending your password to a stranger. paypal doesn't send signed emails, for instance. (maybe they should, but not with the website key, for sure). Stealing passwords and cookies is pretty much the end game for https private key theft. Is anyone willing to say that a bug which only leaks passwords and cookies is a minor issue? wrt heartbleed, there seems to be a gap between the "could happen" and "did happen" consequences. Besides the one test server pummeled with millions of requests, were any private keys actually compromised? On the other hand, we know yahoo passwords were compromised because people were doing it within hours of the heartbleed announcement. I'm more concerned with the latter. Yes, if I'm writing a sort function for vulnerabilities, "read arbitrary memory" is worse than "read some memory", but there should be some accounting for degree of difficulty as well.