5 ms·

A thoughtful programmer can avoid these problems by using proper process separation. For example, openSSH works this way. In this setup, compromising the untr

by cmccabe 13y ago

A thoughtful programmer can avoid these problems by using proper process separation. For example, openSSH works this way. In this setup, compromising the untrusted part of the application does not give you full control. If you can keep the trusted part small, you can avoid a lot of problems. X11 violates this principle big-time. Basically, it's a giant application that runs entirely as root. For most of its lifetime on Linux, it included a huge chunk of what we would normally expect to be video driver code that lives in the kernel. It's always had a lot of trivial denial-of-service attacks, keystroke grabbing attacks, and so on. X11 was a great system, especially for the time, but let's not pretend that it was "the very best secure programmers in the world, building C (and C++) codebases from scratch... specifically for security." We are building better systems, like Wayland, the Android stack, and so on, and it's not taking "billions of dollars." Maybe millions.

jessedhillon 13y ago
Do you have any data, or even theoretical reasons you can give as to why Wayland, Android or anything else will be engineered in a more secure way?
- bjourne 13y ago
  Developers are much more security aware these days. Wayland will not require root privileges which means a buffer overflow isn't as critical. It also will not be network transparent which reduces the attack surface enormously. Then remember it was created because xorg had accumulated so much cruft over the years because of its obligation to support dozens of outdated X11 extensions nothing (except for emacs :)) uses. Hopefully that means Wayland's devs will keep it lean and clean and easy to secure.
  - tptacek 13y ago
    Two things. (1) Developers tend to be more aware of secure programming issues than they were in the 1990s, when you could coerce a shell out of a lot of SUID programs and network daemons with a well-placed pipe filter or semicolon character. But that doesn't make them better at implementing more securely. Case in point: Nginx, a codebase that was designed from the start for modern C secure programming, had an integer overflow just a couple days ago; a couple years back, our team found another serious Nginx bug (that time, an info leak) stemming from their attempts to be extra-cautious. So simply being aware of secure programming issues isn't an assurance that code is actually more secure. (2) More importantly: it doesn't matter so much if there are fewer memory corruption vulnerabilities in C programs. Like I said before: what matters is if there are any of them, or at least any that can be discovered in a reasonable amount of time. In (say) C# or Java serverside code that doesn't call out to C code, we can say with some assurance that there aren't any such flaws; we don't have to stare at the same 10,000 lines of code for a month to prove that to ourselves. You simply can't say that about C codebases. There could be a memory corruption flaw in Dovecot right now, or in Postfix, or (less likely, but still...) tinydns.
    - cmccabe 13y ago
      Well, we're going to have to agree to disagree. I do think security has improved since the 1990s. I think that this kind of "we're all doomed, it doesn't matter what you know" attitude that you are displaying is exactly the problem. It does matter what you know and how you architect the system. Security has improved a lot, even on platforms like Windows that are heavily C/C++ based. Garbage collected languages are nice, but they're really just an extension of the general principle of minimizing the trusted code base. They are not a silver bullet (witness the recent Java, Ruby, etc exploits). I am all in favor of these languages, and especially Golang, which shows a lot of promise. What I'm not in favor of is using a really crappy program written in language X as a stick to beat the language designers with, regardless of what value of X we're talking about.
      - tptacek 13y ago
        I gave specific examples of modern C codebases for which lots of attention had been paid to security that subsequently suffered vulnerabilities stemming from memory corruption. You respond with "garbage collected languages are nice but they're really just an extension of the general principle of minimizing the trusted codebase", which is nonresponsive to my point. We agree: we disagree. I don't think it's negligent to write things in C. I like C, a lot; it's my first language. But stop kidding yourself that with just a couple modern development practices you'll produce code in C that is comparably secure to Python or serverside Java. You won't.
        cmccabe 13y ago
        In some ways, C is more secure than Python because it doesn't support eval. Things like pickle can easily be abused. Also, I notice you completely snipped the point about using process separation. Sigh. Mistakes of the past, doomed to repeat, and all that.
        tptacek 13y ago
        C does support eval. C calls it "trying to copy strings".

by cmccabe 13y ago

jessedhillon 13y ago

Do you have any data, or even theoretical reasons you can give as to why Wayland, Android or anything else will be engineered in a more secure way?

bjourne 13y ago
Developers are much more security aware these days. Wayland will not require root privileges which means a buffer overflow isn't as critical. It also will not be network transparent which reduces the attack surface enormously. Then remember it was created because xorg had accumulated so much cruft over the years because of its obligation to support dozens of outdated X11 extensions nothing (except for emacs :)) uses. Hopefully that means Wayland's devs will keep it lean and clean and easy to secure.
- tptacek 13y ago
  Two things. (1) Developers tend to be more aware of secure programming issues than they were in the 1990s, when you could coerce a shell out of a lot of SUID programs and network daemons with a well-placed pipe filter or semicolon character. But that doesn't make them better at implementing more securely. Case in point: Nginx, a codebase that was designed from the start for modern C secure programming, had an integer overflow just a couple days ago; a couple years back, our team found another serious Nginx bug (that time, an info leak) stemming from their attempts to be extra-cautious. So simply being aware of secure programming issues isn't an assurance that code is actually more secure. (2) More importantly: it doesn't matter so much if there are fewer memory corruption vulnerabilities in C programs. Like I said before: what matters is if there are any of them, or at least any that can be discovered in a reasonable amount of time. In (say) C# or Java serverside code that doesn't call out to C code, we can say with some assurance that there aren't any such flaws; we don't have to stare at the same 10,000 lines of code for a month to prove that to ourselves. You simply can't say that about C codebases. There could be a memory corruption flaw in Dovecot right now, or in Postfix, or (less likely, but still...) tinydns.
  - cmccabe 13y ago
    Well, we're going to have to agree to disagree. I do think security has improved since the 1990s. I think that this kind of "we're all doomed, it doesn't matter what you know" attitude that you are displaying is exactly the problem. It does matter what you know and how you architect the system. Security has improved a lot, even on platforms like Windows that are heavily C/C++ based. Garbage collected languages are nice, but they're really just an extension of the general principle of minimizing the trusted code base. They are not a silver bullet (witness the recent Java, Ruby, etc exploits). I am all in favor of these languages, and especially Golang, which shows a lot of promise. What I'm not in favor of is using a really crappy program written in language X as a stick to beat the language designers with, regardless of what value of X we're talking about.
    - tptacek 13y ago
      I gave specific examples of modern C codebases for which lots of attention had been paid to security that subsequently suffered vulnerabilities stemming from memory corruption. You respond with "garbage collected languages are nice but they're really just an extension of the general principle of minimizing the trusted codebase", which is nonresponsive to my point. We agree: we disagree. I don't think it's negligent to write things in C. I like C, a lot; it's my first language. But stop kidding yourself that with just a couple modern development practices you'll produce code in C that is comparably secure to Python or serverside Java. You won't.
      - cmccabe 13y ago
        In some ways, C is more secure than Python because it doesn't support eval. Things like pickle can easily be abused. Also, I notice you completely snipped the point about using process separation. Sigh. Mistakes of the past, doomed to repeat, and all that.
        tptacek 13y ago
        C does support eval. C calls it "trying to copy strings".