7 ms·

> Of course that leaves a share of problems that could’ve been avoided if we used another language. Buffer overflows, double frees and out of boundary reads etc

> Of course that leaves a share of problems that could’ve been avoided if we used another language. Buffer overflows, double frees and out of boundary reads etc, but the bulk of our security problems has not happened due to curl being written in C. He addressed all of those points in the second short paragraph. None of those are C vulnerabilities, they were mistakes made on the part of the developers, not the language. Avoidance of problems in a safer language doesn't mean when things happen, it's the language's fault.

pjmlp 10y ago
These are surely C vulnerabilities and contradict the statement regarding zero policy static analysis errors. #55 -> OOB write via unchecked multiplication #54 -> Double free in curl_maprintf #53 -> Double free in krb5 code #52 -> glob parser write/read out of bound
- mikulas_florek 10y ago
  Double free is not necessary a C issue, but it can be also a program logic issue - I expect to have an object, but it's already deleted. So it's one of 1. object should not exist and the second free is incorrect 2. object should exist and the first free is incorrect 3. object existance is uncertain and the second free must somehow check that Although I can double-free only in unsafe languages, the wrong logic behind it can be the same in safe languages. It just have different consequences.
  - caconym_ 10y ago
    I don't want to jump on the "Rust fixes everything" train, but lifetimes, scope-based destructors and reference counted pointers seem like they help with this sort of thing beyond just preventing literal accesses of freed memory; they can make sure objects are around when you need them and that they're destroyed automatically when you don't anymore. Of course, you don't get it all for free; you have to wrestle with mutability and lifetimes, which can get hairy.
  - xorblurb 10y ago
    Of course it is a C issue, in the same sense that ALL logic errors are in the case you describe -- so either C issues do not exist or you did not manage to find the correct definition: for ex OOB access is caused by faulty program logic, and the consequences are dramatic in unsafe languages. That is an issue of the language, despite you being able to compute OOB indexes in any language. Same thing for double free; the language issue is that the result is catastrophic, not that you can write for ex faulty logic attempting a liberation too early, or an extra one. (Because in safe languages, the result is not as catastrophic as in unsafe languages). That is the whole concept of safety.
    - mikulas_florek 10y ago
      Let's take some safe language, e.g. c# 1. object should not exist and the second free is incorrect In C# I can have to variables pointing to the same object, I null only one of them. The second should be nulled too, but it's not. That's a logic error. So in C# I end up with some object that should not be there, but it is. Which is better - doube-free or undestroyed object - depends on use case.
      - pjmlp 10y ago
        The big difference that you are overlooking is that double free leads to memory corruption, with undefined behavior of program execution. It can crash right away, in a few seconds, minutes, hours later, or never and just keep generating corrupt data. Having a reference that the GC doesn't collect doesn't lead to memory corruption, just more being used than it should be.
        mikulas_florek 10y ago
        > Having a reference that the GC doesn't collect Using such object is/can be as dangerous. In fact I find double-free safer because it usually crashes (and in my code I do checks so it almost certainly crashes), while in C# I can happily use such object without knowing it. But as I said, it depends on specific use case.
- the_why_of_y 10y ago
  > These are surely C vulnerabilities Yes ... > and contradict the statement regarding zero policy static analysis errors. Not necessarily - I've found that static analysis tools (Coverity etc.) have limitations, and I'd expect them to find less than half of these kind of bugs - serious fuzzing tends to find more. The static analysis tool has to work with the type system of the language, and C's type system isn't particularly helpful, so the tool has to find a balance between flagging almost every pointer dereference as "potentially a problem", most of them being false positives, and flagging only the small percentage of actual problems that can be unambiguously proven to be problems with the context available inside a single function definition. (Just stating generalities, haven't looked at the fixes for these bugs.)
masklinn 10y ago
> He addressed all of those points in the second short paragraph. None of those are C vulnerabilities, they were mistakes made on the part of the developers, not the language. They are absolutely the fault of the language, given other languages would have made these bugs impossible. Errare humanum est is hardly a new concept, blaming humans for not being computers is inane, and in fact qualifies for in errare perseverare diabolicum as out of misplaced pride you persevere in the core original error of using C.
- simias 10y ago
  I agree with the gist of your comment but I think it's a bit harsh to say that using C for curl was an error. If I can trust wikipedia the original release of the library was in 1997, at the time it was a perfectly reasonable choice IMO. I doubt the library would have reached its current adoption levels if it had been written in any other language (and I presume an other C library would've taken its place).
  - galdosdi 10y ago
    You're speaking past each other. You're talking about "blame" in a moralistic sense, but the other posters just mean simple causation -- "would this fault have occurred if a safer language was used?" The former sense would be useful... if you want to sue someone or something I guess? But the latter is more useful in real life, so that's what we're discussing
  - renox 10y ago
    Maybe, maybe not: from Wikipedia the first official validation of GNAT (the Free Ada compiler) was done in 1995. So there were already safer languages available.
wamaral 10y ago
If the language does not prevent these mistakes from happening where it would be possible to do so, isn't the language at fault?
- zeusk 10y ago
  But you can't have your cake and eat it too. The language does not implement those checks because perhaps they're not so trivially implementable in the language. Sure, rust is "safer" than C, but is it a better language? that's arguable.
  - Aaargh20318 10y ago
    > Sure, rust is "safer" than C, but is it a better language? that's arguable. Obviously there are more aspects to a language than safety, so I'll give you that, but yes Rust is a better language than C in this aspect. Don't forget that programming languages are meant for humans, not for computers. One of the primary goals of a programming language is to prevent humans from making dumb mistakes.
    - macintux 10y ago
      > One of the primary goals of a programming language is to prevent humans from making dumb mistakes. That clearly wasn't the case when C was designed.
      - anp 10y ago
        I'd wager that using C prevents large classes of errors that would be common place in assembly. That said, colloquial history seems to say that there were plenty of languages which did a better job at that than C.
deleted 10y ago
[deleted]
alkonaut 10y ago
> None of those are C vulnerabilities, they were mistakes made on the part of the developers, not the language. The point of type system features e.g. Option types instead of nulls, or linear/affine types avoiding use-after-free is to make programmer mistakes turn into compiler errors. Nothing more. There is no point in talking about whether or not something is the "languages fault" or not. We know C is like juggling knives. It's a tool. It has drawbacks and benefits. Being widespread and fast are the benefits. Not turning many forms of programmer errors into compiler errors is the drawback. That means the programmer can't make mistakes because they will be shipped. But programmers invariably make mistakes. The grandparent argued that for the sample of issues he looked at, a lot would in fact be avoided by the type system of e.g. Rust - contradicting the argument in the blog post (could be because of the small sample though). I think it's perhaps less important to focus on the number of issues of each kind, and instead look at the severity of them. If the kinds of issues avoided by better type systems are typically trivial issues, but the kind of issues coming from logic errors are severe security issues - then perhaps the case for stronger type systems isn't so strong after all. But I doubt that's the case.
- 321983120931 10y ago
  You can write Standard ML in C if you so desire and only use tagged unions (which ARE the option types of C). It is not even that laborious, it just requires some discipline.
  - Chinjut 10y ago
    Discipline is precisely the thing which shouldn't be required to avoid disaster, if a language is to be well-designed (this is a feature of good design in general).
deleted 10y ago
[deleted]
pdpi 10y ago
> None of those are C vulnerabilities, they were mistakes made on the part of the developers, not the language. Would you ever declare a bug to be the language's fault, other than compiler bugs?
- trav4225 10y ago
  Personally, I certainly wouldn't.
  - irishsultan 10y ago
    A compiler bug isn't the fault of the language though (edit: although on rereading you may not have intended to agree with that part).
    - pdpi 10y ago
      Yeah, even I only put that in there as a way to handle cases (like Rust) where there is a single implementation of the language, which makes "implementation bugs" and "language bugs" one and the same.
    - trav4225 10y ago
      yeah, agreed.
fiedzia 10y ago
> Avoidance of problems in a safer language doesn't mean when things happen, it's the language's fault. My definition of fault is "what should be changed to prevent such error". And you are not going to change developers.
_ph_ 10y ago
Catching these kind of programmers mistakes is exactly what distinguishes a language as "safer". Be it because they are ruled out by the type system, memory system, or at least the run-time checks.
coldtea 10y ago
>Avoidance of problems in a safer language doesn't mean when things happen, it's the language's fault. Actually that's exactly what it means. That's the only way people mean "It's because of C". That a safer language would have prevented those classes of errors" That's regardless whether a more careful programmer would also have prevented them in C too.
staticassertion 10y ago
" ... a programming language designer should be responsible for the mistakes that are made by the programmers using the language. [...] It's very easy to persuade the customers of your language that everything that goes wrong is their fault and not yours. I rejected that..." - Tony Hoar I think this is a particularly solid point by Tony Hoare (made during his talk on 'the billion dollar mistake', null). We find it very easy to blame developers for mistakes that really shouldn't have been possible to make ta all.
- flogic 10y ago
  I think there needs to be a grain of salt with the billion dollar mistake thing. The really dangerous part isn't dereferencing the null so much as what happens afterwards. If you dereference a null and the program terminates, that sucks. But, you debug it and life moves on. If "something" happens that's a whole different much bigger issue. Rust doesn't have null but you can ".unwrap()" an option type. Which may terminate the program and force you to debug. If memory serves, Haskell doesn't enforce exhaustive patterns. So once again, the program terminates and you're stuck debugging. That's really just life. Now, I do in general prefer languages "without" null as they generally have more warning about when you can actually encounter null. Though my personal experience says that in sensibly written programs dealing with null isn't that big a deal. Is it a billion dollar mistake? I would have little trouble believing that. However, that would likely make dynamic typing an order of magnitude or two larger in the mistake dept.
  - staticassertion 10y ago
    The quote wasn't really about null - that's just the talk he was giving. It was about checked array indexing. I would also say there really is no comparison between null, which escapes typechecking, and unwrap, which does not. But that's not my point, nor is it Hoare's. It's that we blame people for problems that are better solved by languages.

pjmlp 10y ago

These are surely C vulnerabilities and contradict the statement regarding zero policy static analysis errors. #55 -> OOB write via unchecked multiplication #54 -> Double free in curl_maprintf #53 -> Double free in krb5 code #52 -> glob parser write/read out of bound

mikulas_florek 10y ago
Double free is not necessary a C issue, but it can be also a program logic issue - I expect to have an object, but it's already deleted. So it's one of 1. object should not exist and the second free is incorrect 2. object should exist and the first free is incorrect 3. object existance is uncertain and the second free must somehow check that Although I can double-free only in unsafe languages, the wrong logic behind it can be the same in safe languages. It just have different consequences.
- caconym_ 10y ago
  I don't want to jump on the "Rust fixes everything" train, but lifetimes, scope-based destructors and reference counted pointers seem like they help with this sort of thing beyond just preventing literal accesses of freed memory; they can make sure objects are around when you need them and that they're destroyed automatically when you don't anymore. Of course, you don't get it all for free; you have to wrestle with mutability and lifetimes, which can get hairy.
- xorblurb 10y ago
  Of course it is a C issue, in the same sense that ALL logic errors are in the case you describe -- so either C issues do not exist or you did not manage to find the correct definition: for ex OOB access is caused by faulty program logic, and the consequences are dramatic in unsafe languages. That is an issue of the language, despite you being able to compute OOB indexes in any language. Same thing for double free; the language issue is that the result is catastrophic, not that you can write for ex faulty logic attempting a liberation too early, or an extra one. (Because in safe languages, the result is not as catastrophic as in unsafe languages). That is the whole concept of safety.
  - mikulas_florek 10y ago
    Let's take some safe language, e.g. c# 1. object should not exist and the second free is incorrect In C# I can have to variables pointing to the same object, I null only one of them. The second should be nulled too, but it's not. That's a logic error. So in C# I end up with some object that should not be there, but it is. Which is better - doube-free or undestroyed object - depends on use case.
    - pjmlp 10y ago
      The big difference that you are overlooking is that double free leads to memory corruption, with undefined behavior of program execution. It can crash right away, in a few seconds, minutes, hours later, or never and just keep generating corrupt data. Having a reference that the GC doesn't collect doesn't lead to memory corruption, just more being used than it should be.
      - mikulas_florek 10y ago
        > Having a reference that the GC doesn't collect Using such object is/can be as dangerous. In fact I find double-free safer because it usually crashes (and in my code I do checks so it almost certainly crashes), while in C# I can happily use such object without knowing it. But as I said, it depends on specific use case.
the_why_of_y 10y ago
> These are surely C vulnerabilities Yes ... > and contradict the statement regarding zero policy static analysis errors. Not necessarily - I've found that static analysis tools (Coverity etc.) have limitations, and I'd expect them to find less than half of these kind of bugs - serious fuzzing tends to find more. The static analysis tool has to work with the type system of the language, and C's type system isn't particularly helpful, so the tool has to find a balance between flagging almost every pointer dereference as "potentially a problem", most of them being false positives, and flagging only the small percentage of actual problems that can be unambiguously proven to be problems with the context available inside a single function definition. (Just stating generalities, haven't looked at the fixes for these bugs.)

masklinn 10y ago

> He addressed all of those points in the second short paragraph. None of those are C vulnerabilities, they were mistakes made on the part of the developers, not the language. They are absolutely the fault of the language, given other languages would have made these bugs impossible. Errare humanum est is hardly a new concept, blaming humans for not being computers is inane, and in fact qualifies for in errare perseverare diabolicum as out of misplaced pride you persevere in the core original error of using C.

simias 10y ago
I agree with the gist of your comment but I think it's a bit harsh to say that using C for curl was an error. If I can trust wikipedia the original release of the library was in 1997, at the time it was a perfectly reasonable choice IMO. I doubt the library would have reached its current adoption levels if it had been written in any other language (and I presume an other C library would've taken its place).
- galdosdi 10y ago
  You're speaking past each other. You're talking about "blame" in a moralistic sense, but the other posters just mean simple causation -- "would this fault have occurred if a safer language was used?" The former sense would be useful... if you want to sue someone or something I guess? But the latter is more useful in real life, so that's what we're discussing
- renox 10y ago
  Maybe, maybe not: from Wikipedia the first official validation of GNAT (the Free Ada compiler) was done in 1995. So there were already safer languages available.

wamaral 10y ago

If the language does not prevent these mistakes from happening where it would be possible to do so, isn't the language at fault?

zeusk 10y ago
But you can't have your cake and eat it too. The language does not implement those checks because perhaps they're not so trivially implementable in the language. Sure, rust is "safer" than C, but is it a better language? that's arguable.
- Aaargh20318 10y ago
  > Sure, rust is "safer" than C, but is it a better language? that's arguable. Obviously there are more aspects to a language than safety, so I'll give you that, but yes Rust is a better language than C in this aspect. Don't forget that programming languages are meant for humans, not for computers. One of the primary goals of a programming language is to prevent humans from making dumb mistakes.
  - macintux 10y ago
    > One of the primary goals of a programming language is to prevent humans from making dumb mistakes. That clearly wasn't the case when C was designed.
    - anp 10y ago
      I'd wager that using C prevents large classes of errors that would be common place in assembly. That said, colloquial history seems to say that there were plenty of languages which did a better job at that than C.

deleted 10y ago

[deleted]

alkonaut 10y ago

> None of those are C vulnerabilities, they were mistakes made on the part of the developers, not the language. The point of type system features e.g. Option types instead of nulls, or linear/affine types avoiding use-after-free is to make programmer mistakes turn into compiler errors. Nothing more. There is no point in talking about whether or not something is the "languages fault" or not. We know C is like juggling knives. It's a tool. It has drawbacks and benefits. Being widespread and fast are the benefits. Not turning many forms of programmer errors into compiler errors is the drawback. That means the programmer can't make mistakes because they will be shipped. But programmers invariably make mistakes. The grandparent argued that for the sample of issues he looked at, a lot would in fact be avoided by the type system of e.g. Rust - contradicting the argument in the blog post (could be because of the small sample though). I think it's perhaps less important to focus on the number of issues of each kind, and instead look at the severity of them. If the kinds of issues avoided by better type systems are typically trivial issues, but the kind of issues coming from logic errors are severe security issues - then perhaps the case for stronger type systems isn't so strong after all. But I doubt that's the case.

321983120931 10y ago
You can write Standard ML in C if you so desire and only use tagged unions (which ARE the option types of C). It is not even that laborious, it just requires some discipline.
- Chinjut 10y ago
  Discipline is precisely the thing which shouldn't be required to avoid disaster, if a language is to be well-designed (this is a feature of good design in general).

deleted 10y ago

[deleted]

pdpi 10y ago

> None of those are C vulnerabilities, they were mistakes made on the part of the developers, not the language. Would you ever declare a bug to be the language's fault, other than compiler bugs?

trav4225 10y ago
Personally, I certainly wouldn't.
- irishsultan 10y ago
  A compiler bug isn't the fault of the language though (edit: although on rereading you may not have intended to agree with that part).
  - pdpi 10y ago
    Yeah, even I only put that in there as a way to handle cases (like Rust) where there is a single implementation of the language, which makes "implementation bugs" and "language bugs" one and the same.
  - trav4225 10y ago
    yeah, agreed.

fiedzia 10y ago

> Avoidance of problems in a safer language doesn't mean when things happen, it's the language's fault. My definition of fault is "what should be changed to prevent such error". And you are not going to change developers.

_ph_ 10y ago

Catching these kind of programmers mistakes is exactly what distinguishes a language as "safer". Be it because they are ruled out by the type system, memory system, or at least the run-time checks.

coldtea 10y ago

>Avoidance of problems in a safer language doesn't mean when things happen, it's the language's fault. Actually that's exactly what it means. That's the only way people mean "It's because of C". That a safer language would have prevented those classes of errors" That's regardless whether a more careful programmer would also have prevented them in C too.

staticassertion 10y ago

" ... a programming language designer should be responsible for the mistakes that are made by the programmers using the language. [...] It's very easy to persuade the customers of your language that everything that goes wrong is their fault and not yours. I rejected that..." - Tony Hoar I think this is a particularly solid point by Tony Hoare (made during his talk on 'the billion dollar mistake', null). We find it very easy to blame developers for mistakes that really shouldn't have been possible to make ta all.

flogic 10y ago
I think there needs to be a grain of salt with the billion dollar mistake thing. The really dangerous part isn't dereferencing the null so much as what happens afterwards. If you dereference a null and the program terminates, that sucks. But, you debug it and life moves on. If "something" happens that's a whole different much bigger issue. Rust doesn't have null but you can ".unwrap()" an option type. Which may terminate the program and force you to debug. If memory serves, Haskell doesn't enforce exhaustive patterns. So once again, the program terminates and you're stuck debugging. That's really just life. Now, I do in general prefer languages "without" null as they generally have more warning about when you can actually encounter null. Though my personal experience says that in sensibly written programs dealing with null isn't that big a deal. Is it a billion dollar mistake? I would have little trouble believing that. However, that would likely make dynamic typing an order of magnitude or two larger in the mistake dept.
- staticassertion 10y ago
  The quote wasn't really about null - that's just the talk he was giving. It was about checked array indexing. I would also say there really is no comparison between null, which escapes typechecking, and unwrap, which does not. But that's not my point, nor is it Hoare's. It's that we blame people for problems that are better solved by languages.