6 ms·

Are you saying that memory safety is valuable or not? If you do think memory safety is valuable, then I don't see how you're disagreeing with the author. Nobody

Are you saying that memory safety is valuable or not? If you do think memory safety is valuable, then I don't see how you're disagreeing with the author. Nobody is claiming that memory safety eliminates all bugs.

tptacek 7y ago
Memory safety is valuable! I wouldn't want to implement anything in a memory-unsafe language if I could avoid it, and, thanks to Rust, I can virtually always avoid it now. There's ways to make bugs easier to chain and exploit, and memory unsafety is a big one. But, while I know nothing is a panacea, memory safety is especially not a panacea. We have over a decade worth of experience with software built principally in memory-safe languages; it's hard to find a modern web application --- increasingly, it's even hard to find a modern mobile application --- built in a language as bad as C. And, as you know, all these memory-safe applications are riddled with vulnerabilities. They don't have memory corruption vulnerabilities, but I'm still game-over'ing app pentests, and very unhappy with myself when I can't.
- xwowsersx 7y ago
  I'm not sure I get what you're saying here. What do you mean you're "game-over'ing app pentests"? You organize penetration tests and are usually able to expose vulnerabilities when you do this?
  - tptacek 7y ago
    Yes, I've been doing software security full-time since 2005, and was a vulnerability researcher prior to that. I speak for basically every software security person when I say that memory safe languages are a positive development, but applications remain susceptible to vulnerabilities that result in total compromise.
    - xwowsersx 7y ago
      Makes sense, thanks. I'm not sure how anyone could suggest that vulnerabilities don't exist if you use a memory safe language. That's just demonstrably/factually not true...
      - tptacek 7y ago
        I'm reacting to the actual post, not the comment thread. The post sets out to teach software developers about "software security", and its answer to that problem is "use Rust and validate user input". I mean, using Rust will at least actually help. But it's nowhere close to a synopsis of the whole problem.
        loup-vaillant 7y ago
        It's a single course. I think no one, not even the author, expect a single course to cover enough ground to ensure that students can write secure applications moving forward. For instance, the author has a "formal verification" category on their blog: http://www.pl-enthusiast.net/category/formal-verification/ http://www.pl-enthusiast.net/category/formal-verification/ But they do think (like Daniel Bernstein and Edsger Dijkstra), that the usual "pentest & patch" does not work. http://www.pl-enthusiast.net/2015/09/30/penetrate-and-patch-to-building-security-in/ http://www.pl-enthusiast.net/2015/09/30/penetrate-and-patch-...
        tptacek 7y ago
        And I'm critiquing the premises of the single course. What's your point? I've talked to more than one university professor in the last 2 years about what a first and second course in software security should look like, and if there's a theme to my feedback, it's "not like this; this is what people thought it might look like in 1998".
        loup-vaillant 7y ago
        You appear to critique the premise that most security comes from using the right programming language and observing a few patterns, like validating all inputs. I was saying this is most probably not the premise of the course. That just like you, they don't believe they're teaching a panacea, just something that will help. That assessment could be wrong, though. Unlike you, I never discussed security with university professors, and I know nothing of their misconceptions. Could you offer a gist of what they teach, and most importantly what they should be teaching instead?

tptacek 7y ago

Memory safety is valuable! I wouldn't want to implement anything in a memory-unsafe language if I could avoid it, and, thanks to Rust, I can virtually always avoid it now. There's ways to make bugs easier to chain and exploit, and memory unsafety is a big one. But, while I know nothing is a panacea, memory safety is especially not a panacea. We have over a decade worth of experience with software built principally in memory-safe languages; it's hard to find a modern web application --- increasingly, it's even hard to find a modern mobile application --- built in a language as bad as C. And, as you know, all these memory-safe applications are riddled with vulnerabilities. They don't have memory corruption vulnerabilities, but I'm still game-over'ing app pentests, and very unhappy with myself when I can't.

xwowsersx 7y ago
I'm not sure I get what you're saying here. What do you mean you're "game-over'ing app pentests"? You organize penetration tests and are usually able to expose vulnerabilities when you do this?
- tptacek 7y ago
  Yes, I've been doing software security full-time since 2005, and was a vulnerability researcher prior to that. I speak for basically every software security person when I say that memory safe languages are a positive development, but applications remain susceptible to vulnerabilities that result in total compromise.
  - xwowsersx 7y ago
    Makes sense, thanks. I'm not sure how anyone could suggest that vulnerabilities don't exist if you use a memory safe language. That's just demonstrably/factually not true...
    - tptacek 7y ago
      I'm reacting to the actual post, not the comment thread. The post sets out to teach software developers about "software security", and its answer to that problem is "use Rust and validate user input". I mean, using Rust will at least actually help. But it's nowhere close to a synopsis of the whole problem.
      - loup-vaillant 7y ago
        It's a single course. I think no one, not even the author, expect a single course to cover enough ground to ensure that students can write secure applications moving forward. For instance, the author has a "formal verification" category on their blog: http://www.pl-enthusiast.net/category/formal-verification/ http://www.pl-enthusiast.net/category/formal-verification/ But they do think (like Daniel Bernstein and Edsger Dijkstra), that the usual "pentest & patch" does not work. http://www.pl-enthusiast.net/2015/09/30/penetrate-and-patch-to-building-security-in/ http://www.pl-enthusiast.net/2015/09/30/penetrate-and-patch-...
        tptacek 7y ago
        And I'm critiquing the premises of the single course. What's your point? I've talked to more than one university professor in the last 2 years about what a first and second course in software security should look like, and if there's a theme to my feedback, it's "not like this; this is what people thought it might look like in 1998".
        loup-vaillant 7y ago
        You appear to critique the premise that most security comes from using the right programming language and observing a few patterns, like validating all inputs. I was saying this is most probably not the premise of the course. That just like you, they don't believe they're teaching a panacea, just something that will help. That assessment could be wrong, though. Unlike you, I never discussed security with university professors, and I know nothing of their misconceptions. Could you offer a gist of what they teach, and most importantly what they should be teaching instead?