7 ms·

> Yet it was required decades of security exploits for developers start grasping the major flaw it was to adopt C. Can we please stop with the C bashing alread

by avian 11y ago

> Yet it was required decades of security exploits for developers start grasping the major flaw it was to adopt C. Can we please stop with the C bashing already? Each time there's a story about a buffer overflow, the top comment says how that would be impossible in Go, Rust, JavaScript or the next shiny thing. First of all, hindsight is always perfect. I'm sure adopting C made sense at the time. We didn't use to stroll down the street with a supercomputer in our pockets you know. And second, the constant stream of news about trivial SQL injections, cross-site scripting vulnerabilities and other such things should make it plenty obvious that you can write unsecure code in any language.

pjmlp 11y ago
> I'm sure adopting C made sense at the time. We didn't use to stroll down the street with a supercomputer in our pockets you know. Except Algol, PL/I, PL/M and many others already existed and pre-dated the computers used to develop C on. "A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously,they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." - C.A.R Hoare at his 1980 ACM Turing Award Lecture Algol was created in 1960 and run in computers much more humble that the PDP-11. > And second, the constant stream of news about trivial SQL injections, cross-site scripting vulnerabilities and other such things should make it plenty obvious that you can write unsecure code in any language. Those don't suffer from memory corruption issues. So there is a whole class of security exploits one doesn't need to worry about.
- pmelendez 11y ago
  > Algol, PL/I, PL/M and many others already existed and pre-dated the computers used to develop C on. True... and I bet the performance was significally slower. Also I think the portability in those languages was also limited.
  - pjmlp 11y ago
    > True... and I bet the performance was significally slower. Obvious, since those systems pre-dated PDP-11 hardware. > Also I think the portability in those languages was also limited. Have you ever coded C before ANSI C was approved? It was only portable to UNIX itself, just like those other OSes and their systems programming languages. Each C compiler outside UNIX implemented its own subset and semantics, hence why ANSI C had to adopt so much UB to avoid breaking too much code.
    - pmelendez 11y ago
      > Obvious, since those systems pre-dated PDP-11 hardware. Well, I was actually referring to the equivalent running on PDP-11 (like Algol68) > Have you ever coded C before ANSI C was approved? >It was only portable to UNIX itself, just like those other OSes and their systems programming languages. I meant machine portability. Before C, to have a lower level like performance you needed to use machine-specific assembly.
      - pjmlp 11y ago
        C compilers generated so bad code that games only started using it in home computers instead of Assembly during the mid-90's. On workstations and mainframes there was hardly any difference to other heigher level system programming languages. In fact C prevented many compiler optimizations due to its aliasing and decay of arrays into pointers.
        moomin 11y ago
        Amazing how few people remember that Fortran compilers always outperformed C compilers in the "bad old days".
MichaelGG 11y ago
I think it's late enough that it's no longer hindsight. (And note they didn't even enable stack cookies for the extra protection that'd have given them.) C gives you all those SQL injections, XSS, shellshock, etc. in addition to all memory unsafe exploits - it's a superset of vulnerabilities (actually, I'd not be surprised if C makes it worse, as the code is far, far more verbose and focused on minutia and hence higher-level logic failures are more difficult to notice.). And, going from widespread commercial software, the other issues seem to account for much less of the critical security bugs. Even so, if they had some amazing backcompat reason to stick with C, they should have been sandboxing and otherwise limiting the impact of the apparently-inevitable, trivial memory corruption issues they're sure to have created.
geofft 11y ago
> And second, the constant stream of news about trivial SQL injections, cross-site scripting vulnerabilities and other such things should make it plenty obvious that you can write unsecure code in any language. Find me an unintended trivial SQL injection or cross-site scripting vulnerability in Rust. Or Elm or Ur/Web, if you prefer more web-oriented languages. All you have done is demonstrate that there are languages other than C that one should not write in, either. But of course there are. You have not demonstrated that all languages have these problems to the same extent. It is rather like arguing that since you can get concussions in football, and you can also get concussions in ice hockey, it doesn't really matter what sport you play. While it is technically true that you can get concussions from golf or cross-country running, it takes quite a bit of skill and (un)luck to make it happen.
- tedunangst 11y ago
  > Find me an unintended trivial SQL injection or cross-site scripting vulnerability in Rust. Well, if there's no web support in rust, that's going to be kind of hard. There's no SQL injection "in C" either. For that matter, there aren't any buffer overflows in the C language. Now, if you meant "in some rando web forum written in rust", I think you'll need to wait a bit. Let's wait until there's a forum with more than a dozen users, then I'll tell you how the developers fucked up.
- Gankro 11y ago
  Sadly Rust does little to deal with these higher-level bugs. We give you tools to deal with them (tracking taint with PhantomData), but it's not clear to me that anyone's bothering to actually do that. e.g. crates.io does no such tracking, but it also just punts the problem completely to our postgres bindings and making sure to build queries separately from their args (and the postgres arg injection does escaping, presumably). But this is no static or novel guarantee. It's just Alex being a great developer and reviewing all the patches. I wouldn't be floored if crates.io was exploitable. Actually I know it is; [I've exploited it](https://github.com/rust-lang/crates.io/issues/176 https://github.com/rust-lang/crates.io/issues/176). Rust solves many interesting problems, but it is no panacea for program correctness!
ossreality 11y ago
What a weirdly defensive comment. Someone can't be bothered to learn Rust, eh?
4ad 11y ago
> Each time there's a story about a buffer overflow, the top comment says how that would be impossible in Go, Rust, JavaScript or the next shiny thing. The top comment made by the same person.
- MichaelGG 11y ago
  It's just frustrating. Same stupid shit, over and over. This seemed particularly egregious as it was buffer overflow 101 example; no fancy exploit needed. Though the comment seems to get reasonably upvoted, you're right that perhaps it's not a very high signal. Sorry.
wepple 11y ago
I agree. If/when anyone starts building programs people care about in rust/go/etc - there will be vulnerabilities. Suggesting that throwing thousands of lines worth of virtual machine behind a piece of code will solve security problems is shortsighted.

by avian 11y ago

pjmlp 11y ago

> I'm sure adopting C made sense at the time. We didn't use to stroll down the street with a supercomputer in our pockets you know. Except Algol, PL/I, PL/M and many others already existed and pre-dated the computers used to develop C on. "A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously,they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." - C.A.R Hoare at his 1980 ACM Turing Award Lecture Algol was created in 1960 and run in computers much more humble that the PDP-11. > And second, the constant stream of news about trivial SQL injections, cross-site scripting vulnerabilities and other such things should make it plenty obvious that you can write unsecure code in any language. Those don't suffer from memory corruption issues. So there is a whole class of security exploits one doesn't need to worry about.

pmelendez 11y ago
> Algol, PL/I, PL/M and many others already existed and pre-dated the computers used to develop C on. True... and I bet the performance was significally slower. Also I think the portability in those languages was also limited.
- pjmlp 11y ago
  > True... and I bet the performance was significally slower. Obvious, since those systems pre-dated PDP-11 hardware. > Also I think the portability in those languages was also limited. Have you ever coded C before ANSI C was approved? It was only portable to UNIX itself, just like those other OSes and their systems programming languages. Each C compiler outside UNIX implemented its own subset and semantics, hence why ANSI C had to adopt so much UB to avoid breaking too much code.
  - pmelendez 11y ago
    > Obvious, since those systems pre-dated PDP-11 hardware. Well, I was actually referring to the equivalent running on PDP-11 (like Algol68) > Have you ever coded C before ANSI C was approved? >It was only portable to UNIX itself, just like those other OSes and their systems programming languages. I meant machine portability. Before C, to have a lower level like performance you needed to use machine-specific assembly.
    - pjmlp 11y ago
      C compilers generated so bad code that games only started using it in home computers instead of Assembly during the mid-90's. On workstations and mainframes there was hardly any difference to other heigher level system programming languages. In fact C prevented many compiler optimizations due to its aliasing and decay of arrays into pointers.
      - moomin 11y ago
        Amazing how few people remember that Fortran compilers always outperformed C compilers in the "bad old days".

MichaelGG 11y ago

I think it's late enough that it's no longer hindsight. (And note they didn't even enable stack cookies for the extra protection that'd have given them.) C gives you all those SQL injections, XSS, shellshock, etc. in addition to all memory unsafe exploits - it's a superset of vulnerabilities (actually, I'd not be surprised if C makes it worse, as the code is far, far more verbose and focused on minutia and hence higher-level logic failures are more difficult to notice.). And, going from widespread commercial software, the other issues seem to account for much less of the critical security bugs. Even so, if they had some amazing backcompat reason to stick with C, they should have been sandboxing and otherwise limiting the impact of the apparently-inevitable, trivial memory corruption issues they're sure to have created.

geofft 11y ago

> And second, the constant stream of news about trivial SQL injections, cross-site scripting vulnerabilities and other such things should make it plenty obvious that you can write unsecure code in any language. Find me an unintended trivial SQL injection or cross-site scripting vulnerability in Rust. Or Elm or Ur/Web, if you prefer more web-oriented languages. All you have done is demonstrate that there are languages other than C that one should not write in, either. But of course there are. You have not demonstrated that all languages have these problems to the same extent. It is rather like arguing that since you can get concussions in football, and you can also get concussions in ice hockey, it doesn't really matter what sport you play. While it is technically true that you can get concussions from golf or cross-country running, it takes quite a bit of skill and (un)luck to make it happen.

tedunangst 11y ago
> Find me an unintended trivial SQL injection or cross-site scripting vulnerability in Rust. Well, if there's no web support in rust, that's going to be kind of hard. There's no SQL injection "in C" either. For that matter, there aren't any buffer overflows in the C language. Now, if you meant "in some rando web forum written in rust", I think you'll need to wait a bit. Let's wait until there's a forum with more than a dozen users, then I'll tell you how the developers fucked up.
Gankro 11y ago
Sadly Rust does little to deal with these higher-level bugs. We give you tools to deal with them (tracking taint with PhantomData), but it's not clear to me that anyone's bothering to actually do that. e.g. crates.io does no such tracking, but it also just punts the problem completely to our postgres bindings and making sure to build queries separately from their args (and the postgres arg injection does escaping, presumably). But this is no static or novel guarantee. It's just Alex being a great developer and reviewing all the patches. I wouldn't be floored if crates.io was exploitable. Actually I know it is; [I've exploited it](https://github.com/rust-lang/crates.io/issues/176 https://github.com/rust-lang/crates.io/issues/176). Rust solves many interesting problems, but it is no panacea for program correctness!

ossreality 11y ago

What a weirdly defensive comment. Someone can't be bothered to learn Rust, eh?

4ad 11y ago

> Each time there's a story about a buffer overflow, the top comment says how that would be impossible in Go, Rust, JavaScript or the next shiny thing. The top comment made by the same person.

MichaelGG 11y ago
It's just frustrating. Same stupid shit, over and over. This seemed particularly egregious as it was buffer overflow 101 example; no fancy exploit needed. Though the comment seems to get reasonably upvoted, you're right that perhaps it's not a very high signal. Sorry.

wepple 11y ago

I agree. If/when anyone starts building programs people care about in rust/go/etc - there will be vulnerabilities. Suggesting that throwing thousands of lines worth of virtual machine behind a piece of code will solve security problems is shortsighted.