6 ms·

So it's 2015 and they ship software with a trivial stack buffer overflow. They don't even bother to turn on the "mitigation" options in the compiler (not that i

So it's 2015 and they ship software with a trivial stack buffer overflow. They don't even bother to turn on the "mitigation" options in the compiler (not that it makes such mitigations less of a terrible set of hacks). Sounds fairly incompetent. Also further validates the intelligence in creating things like Rust.

pjmlp 11y ago
> Also further validates the intelligence in creating things like Rust. Yeah, but many of the Rust features are present in the branch of Algol derived languages, namely Mesa, Modula-2, Modula-3, Oberon derivatives, Ada, Pascal dialects.... Yet it was required decades of security exploits for developers start grasping the major flaw it was to adopt C.
- pcwalton 11y ago
  > Yeah, but many of the Rust features are present in the branch of Algol derived languages, namely Mesa, Modula-2, Modula-3, Oberon derivatives, Ada, Pascal dialects.... None of these have memory safety without GC (while supporting dynamic allocation and deallocation).
  - pjmlp 11y ago
    You are doing a great job with Rust, but I think you always jump to quickly to criticize Wirth languages and push for Rust. Mesa => RC with local GC for collecting cycles. Modula-2 => True, does manually memory management, but avoids all other C memory corruption errors. Modula-3 => Uses GC only for types allocated via NEW. Library contains generic RC pointers. Untraced pointers can only be used in unsafe code. Oberon derivates => Uses GC only for types allocated via NEW. Active Oberon added support for untraced pointers only in unsafe code. Ada => No GC. All memory allocation is controlled. Deallocation is only possible via regions or explicitly in unsafe code. There are generic RC libraries as well. Pascal dialects => No GC. Suffer from manual memory management, but none of the other typical exploits regarding out of bounds or pointer misuse. Yes, they may lack affine types, but had they succeed in the industry instead of C, the need of something like Rust would be greatly reduced. As such now we have to place our hopes in something like Rust, because the new generations never heard of those languages and think C was the very first systems programming language. However every time I look at Rust sample code I would like to see the same amount of _unsafe_ being used like in the those languages. Instead, many Rust users seem to sprinkle it everywhere.
    - smosher_ 11y ago
      > new generations never heard of those languages and think C was the very first systems programming language. That's just it. Rust looks enough like C++ to catch on. This was not an accident though I can't say I'm jazzed about it. Rust brings a lot to the table with its type system too. I would rather be using Rust tomorrow than having had the benefits of say Pascal derivatives for the past 45 years. I'm not saying this just for effect: after the obvious ML influence, the parts of Rust I like most are the nuances. > Instead, many Rust users seem to sprinkle it everywhere. Is that true? You will necessarily see it in bindings, or to implement certain essential features that can't be implemented otherwise. Beyond that there is the motivation to use unsafe code for speed, hopefully this is mostly restricted to modules. Are you complaining that people are using when they could reasonably avoid it or that it is too often necessary?
      - pjmlp 11y ago
        > Are you complaining that people are using when they could reasonably avoid it or that it is too often necessary? They are abusing it, specially as workarounds for constraints that cannot be expressed in the type system. While in the languages I mentioned, unsafe constructs are related any operation that might lead to memory corruption, some Rust devs are using it for anything they assume isn't logical safe. So you then get talks like the Session Types one at ICFP, that uses unsafe to control functions being called outside the protocol Traits that are being defined. Which lead to discussions like this one: https://github.com/rust-lang/rfcs/pull/1236#issuecomment-136875613 https://github.com/rust-lang/rfcs/pull/1236#issuecomment-136...
        kinghajj 11y ago
        So your objection is to how certain users (notably not the core dev team) utilize "unsafe", now with the language itself. It seems like the easiest way to mitigate this is with better documentation; surely, those other languages' equivalents of "unsafe" could also have been abused similarly, no?
        11y ago
- 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.
- notvladputin 11y ago
  What were the reasons that C was adopted over these other options? (Honestly don't know, I wasn't around in those days...)
  - alricb 11y ago
    Unix was insanely successful in its day: an indication is that when Richard M. Stallman decided to create a Free Software operating system in 1984, he chose to call it "GNU" for "GNU's Not Unix".
  - pjmlp 11y ago
    AT&T made UNIX source code available to a few American universities like Stanford, Berkeley, Carnegie... Some of those students tried their way into the recent workstation market using what they knew from their university. Sun was such case. Back in those days we payed for development tools, so everyone used to stick with what the OS vendors had, why shell out money for another language that implied the extra effort of writing bindings. So like the mobile and browser space nowadays, C as the UNIX language was the way to go. Meanwhile, those university students and professional coders with access to UNIX at the university and work, wanted to be able to take work home. So C dialects that where able to be used in the tiny home computers started to be developed and distributed over code listing in magazines, books and BBS. When UNIX eventually took over the mainframes market, C got into the same spot like JavaScript in the browser. The other languages, just like any systems programming language had their OSes, but they failed against UNIX. And as I mentioned before back then you needed a very good reason to convince someone to pay extra for compilers that weren't part of the OS SDK.
x0x0 11y ago
I have a thought and a question. First, we can only write secure parsers for single file types through enormous effort. My guess is writing secure parsers for dozens of file types is functionally impossible in C. What more secure languages besides C are easy to call from C/C++ codebases? afaik ocaml isn't, at least in the sense that I don't think you can produce a c lib without sucking in the ocaml allocator and other stuff [1]. [1] http://www.mega-nerd.com/erikd/Blog/CodeHacking/Ocaml/calling_ocaml.html http://www.mega-nerd.com/erikd/Blog/CodeHacking/Ocaml/callin...
- MichaelGG 11y ago
  This is one of the big reasons Rust is so exciting. ABI compatibility with C and no real runtime (no GC etc.). Though Kapersky would have been better off even using C++/CLI and "It Just Works" to hook into code written in, say, C#. The IJW stuff is cute, as it seamlessly brings the CLR in-process and lets you transition from native to managed without noticing. (And MSVC's C++->CLI targeting is good enough to compile MS Office except producing MSIL instead of native code, fwiw.)
  - x0x0 11y ago
    so it's easy enough and fast to have c++ calling rust, so you can spot replace pieces of an extant codebase?
    - bzbarsky 11y ago
      Yes, precisely.
    - kuschku 11y ago
      Yes. And that’s what mozilla has started to do recently.
      - MaulingMonkey 11y ago
        Any idea where I can find such commits?
gnuteller 11y ago
Wow look at the smart guy here everybody. Java had a basic arithmetic bug until what 2005? Bash shell had a serious bug until last year? The people developing these software are all 10x smarter than you.
- MichaelGG 11y ago
  No one's saying this will eliminate all problems. Just the vast majority of remote execution bugs in widely-used codebases seem to be related to memory corruption. I examined all of MS's security notices for a couple of years, and the number of critical notices that'd be eliminated with memory safety was well over 90%. Mozilla says the same is true of Firefox.
- geofft 11y ago
  Well, yes. I'm not anywhere near as smart as the people writing Java or bash. That is why I want a computer to be smart for me. If they can't get things right in an unsafe language, what hope do I have? We have powerful computers these days. Software is eating the world. Let it eat the process of writing correct software, too.
whyever 11y ago
It also validates the opinion that anti-virus software is increasing the attack surface, possibly outweighing the benefits.

pjmlp 11y ago

> Also further validates the intelligence in creating things like Rust. Yeah, but many of the Rust features are present in the branch of Algol derived languages, namely Mesa, Modula-2, Modula-3, Oberon derivatives, Ada, Pascal dialects.... Yet it was required decades of security exploits for developers start grasping the major flaw it was to adopt C.

pcwalton 11y ago
> Yeah, but many of the Rust features are present in the branch of Algol derived languages, namely Mesa, Modula-2, Modula-3, Oberon derivatives, Ada, Pascal dialects.... None of these have memory safety without GC (while supporting dynamic allocation and deallocation).
- pjmlp 11y ago
  You are doing a great job with Rust, but I think you always jump to quickly to criticize Wirth languages and push for Rust. Mesa => RC with local GC for collecting cycles. Modula-2 => True, does manually memory management, but avoids all other C memory corruption errors. Modula-3 => Uses GC only for types allocated via NEW. Library contains generic RC pointers. Untraced pointers can only be used in unsafe code. Oberon derivates => Uses GC only for types allocated via NEW. Active Oberon added support for untraced pointers only in unsafe code. Ada => No GC. All memory allocation is controlled. Deallocation is only possible via regions or explicitly in unsafe code. There are generic RC libraries as well. Pascal dialects => No GC. Suffer from manual memory management, but none of the other typical exploits regarding out of bounds or pointer misuse. Yes, they may lack affine types, but had they succeed in the industry instead of C, the need of something like Rust would be greatly reduced. As such now we have to place our hopes in something like Rust, because the new generations never heard of those languages and think C was the very first systems programming language. However every time I look at Rust sample code I would like to see the same amount of _unsafe_ being used like in the those languages. Instead, many Rust users seem to sprinkle it everywhere.
  - smosher_ 11y ago
    > new generations never heard of those languages and think C was the very first systems programming language. That's just it. Rust looks enough like C++ to catch on. This was not an accident though I can't say I'm jazzed about it. Rust brings a lot to the table with its type system too. I would rather be using Rust tomorrow than having had the benefits of say Pascal derivatives for the past 45 years. I'm not saying this just for effect: after the obvious ML influence, the parts of Rust I like most are the nuances. > Instead, many Rust users seem to sprinkle it everywhere. Is that true? You will necessarily see it in bindings, or to implement certain essential features that can't be implemented otherwise. Beyond that there is the motivation to use unsafe code for speed, hopefully this is mostly restricted to modules. Are you complaining that people are using when they could reasonably avoid it or that it is too often necessary?
    - pjmlp 11y ago
      > Are you complaining that people are using when they could reasonably avoid it or that it is too often necessary? They are abusing it, specially as workarounds for constraints that cannot be expressed in the type system. While in the languages I mentioned, unsafe constructs are related any operation that might lead to memory corruption, some Rust devs are using it for anything they assume isn't logical safe. So you then get talks like the Session Types one at ICFP, that uses unsafe to control functions being called outside the protocol Traits that are being defined. Which lead to discussions like this one: https://github.com/rust-lang/rfcs/pull/1236#issuecomment-136875613 https://github.com/rust-lang/rfcs/pull/1236#issuecomment-136...
      - kinghajj 11y ago
        So your objection is to how certain users (notably not the core dev team) utilize "unsafe", now with the language itself. It seems like the easiest way to mitigate this is with better documentation; surely, those other languages' equivalents of "unsafe" could also have been abused similarly, no?
        11y ago
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.
notvladputin 11y ago
What were the reasons that C was adopted over these other options? (Honestly don't know, I wasn't around in those days...)
- alricb 11y ago
  Unix was insanely successful in its day: an indication is that when Richard M. Stallman decided to create a Free Software operating system in 1984, he chose to call it "GNU" for "GNU's Not Unix".
- pjmlp 11y ago
  AT&T made UNIX source code available to a few American universities like Stanford, Berkeley, Carnegie... Some of those students tried their way into the recent workstation market using what they knew from their university. Sun was such case. Back in those days we payed for development tools, so everyone used to stick with what the OS vendors had, why shell out money for another language that implied the extra effort of writing bindings. So like the mobile and browser space nowadays, C as the UNIX language was the way to go. Meanwhile, those university students and professional coders with access to UNIX at the university and work, wanted to be able to take work home. So C dialects that where able to be used in the tiny home computers started to be developed and distributed over code listing in magazines, books and BBS. When UNIX eventually took over the mainframes market, C got into the same spot like JavaScript in the browser. The other languages, just like any systems programming language had their OSes, but they failed against UNIX. And as I mentioned before back then you needed a very good reason to convince someone to pay extra for compilers that weren't part of the OS SDK.

x0x0 11y ago

I have a thought and a question. First, we can only write secure parsers for single file types through enormous effort. My guess is writing secure parsers for dozens of file types is functionally impossible in C. What more secure languages besides C are easy to call from C/C++ codebases? afaik ocaml isn't, at least in the sense that I don't think you can produce a c lib without sucking in the ocaml allocator and other stuff [1]. [1] http://www.mega-nerd.com/erikd/Blog/CodeHacking/Ocaml/calling_ocaml.html http://www.mega-nerd.com/erikd/Blog/CodeHacking/Ocaml/callin...

MichaelGG 11y ago
This is one of the big reasons Rust is so exciting. ABI compatibility with C and no real runtime (no GC etc.). Though Kapersky would have been better off even using C++/CLI and "It Just Works" to hook into code written in, say, C#. The IJW stuff is cute, as it seamlessly brings the CLR in-process and lets you transition from native to managed without noticing. (And MSVC's C++->CLI targeting is good enough to compile MS Office except producing MSIL instead of native code, fwiw.)
- x0x0 11y ago
  so it's easy enough and fast to have c++ calling rust, so you can spot replace pieces of an extant codebase?
  - bzbarsky 11y ago
    Yes, precisely.
  - kuschku 11y ago
    Yes. And that’s what mozilla has started to do recently.
    - MaulingMonkey 11y ago
      Any idea where I can find such commits?

gnuteller 11y ago

Wow look at the smart guy here everybody. Java had a basic arithmetic bug until what 2005? Bash shell had a serious bug until last year? The people developing these software are all 10x smarter than you.

MichaelGG 11y ago
No one's saying this will eliminate all problems. Just the vast majority of remote execution bugs in widely-used codebases seem to be related to memory corruption. I examined all of MS's security notices for a couple of years, and the number of critical notices that'd be eliminated with memory safety was well over 90%. Mozilla says the same is true of Firefox.
geofft 11y ago
Well, yes. I'm not anywhere near as smart as the people writing Java or bash. That is why I want a computer to be smart for me. If they can't get things right in an unsafe language, what hope do I have? We have powerful computers these days. Software is eating the world. Let it eat the process of writing correct software, too.

whyever 11y ago

It also validates the opinion that anti-virus software is increasing the attack surface, possibly outweighing the benefits.