5 ms·

To be fair, most of the vulnerabilities found in C codebases are preventable with static analysis, bound checking, etc. If you are ok with it getting as slow as

by zzzcpan 11y ago

To be fair, most of the vulnerabilities found in C codebases are preventable with static analysis, bound checking, etc. If you are ok with it getting as slow as Go, you can get similar safety guarantees as well.

nickpsecurity 11y ago
You can get complete spatial and temporal safety with Softbound + CETS: http://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/ http://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/ They and Cambridge CHERI team have hardware modifications, too, if you want to run C apps on FPGA CPU with inherent safety. Software-only, though, has significant performance penalties.
lmm 11y ago
> To be fair, most of the vulnerabilities found in C codebases are preventable with static analysis, bound checking, etc. You can work in an ad-hoc dialect of C based on particular tools that will be a bit safer than standard C, sure (though probably still not as safe as an actually memory-safe language). But at that point most of the advantages of C no longer apply: you don't have a huge library ecosystem, you don't have a supply of experienced developers, you don't have a bunch of standard automated tools that work with your dialect. > If you are ok with it getting as slow as Go, you can get similar safety guarantees as well. There is no native/standard/supported-by-tools way to do tagged unions, so whatever you do C will always be less safe than languages that have native tagged unions.
- jjnoakes 11y ago
  I don't think "most of the advantages of C no longer apply [if you use static analysis or bounds checking]" is fair. Even if your claims about losing libraries, experienced developers, or automated tools was true (which think is false), you still get portability, close-to-the-metal code, full control of your processes, direct access to the native ABI, full access to the platform facilities, fast compilation, small executables, standalone libraries, memory layout control, ...
  - lmm 11y ago
    C code is less portable than most of the alternatives. In the rare cases where the things you list are hard requirements there are still safer options e.g. Ada.
    - jjnoakes 11y ago
      C code is less portable than which alternatives? As far as I know, most/all? alternatives are implemented in C or C++.
      - lmm 11y ago
        Plenty of alternatives are self-hosting, but that's neither here nor there. Even if it's a major effort to port e.g. the Python interpreter to a new platform (particularly the first new platform - once you have a C codebase that enforces portability over many platforms it's much easier to add a new one). But that major effort has by and large been done for even relatively obscure languages and relatively obscure platforms. Whereas if you write in C you get to do that major effort for yourself for each program.
        jjnoakes 11y ago
        More portable means "can be ported to new platforms more easily", not "has been ported to new platforms by someone else". A C program (in general) is more portable than anything written on top of C because to port, say, Python to a new platform, one has to have C there first. It has nothing to do with whether the work has been done by you or someone else. Of course, one can write code in either language which is not portable, but that is also beside the point.
        lmm 11y ago
        > A C program (in general) is more portable than anything written on top of C because to port, say, Python to a new platform, one has to have C there first. Port C compiler -> port your C program vs port C compiler -> port Python interpreter -> port your Python program. The latter can still end up a lot easier and cheaper, because the Python interpreter is already multi-platform and Python programs tend not to have much if any platform-specific code by the nature of the language. > It has nothing to do with whether the work has been done by you or someone else. It has everything to do with that. Ultimately via Turing equivalence it's possible to port anything to anywhere, so when we're talking about "portability" we must be talking about how much it costs to port a program to a new or existing architecture. > Of course, one can write code in either language which is not portable, but that is also beside the point. Again, it's very much the point, because it can't possibly be a yes-or-no thing. How costly is typical/idiomatic C code to port? How costly is typical/idiomatic Python code? Those are the questions that matter when we talk about language portability.
vog 11y ago
> If you are ok with it getting as slow as Go, you can get similar safety guarantees as well. FWIW, Rust can make these guarantees without performance penalties.
- seangrogg 11y ago
  There are penalties, they are just relatively marginal.
  - kibwen 11y ago
    Specifically, Rust does runtime bounds checking when you index into an array. LLVM is theoretically capable of optimizing these checks out if they're unnecessary, but it's far from guaranteed. It would take a dependent type system to perform compile-time bounds checking, and Rust isn't that sophisticated. However, indexing is far, far less prevalent in Rust than it is in C, due to the existence of iterators. I've asked the Servo team on multiple occasions whether the cost of bounds checking shows up in performance profiles, and they never have, likely because they just aren't doing very much indexing to begin with.
  - pcwalton 11y ago
    > There are penalties, they are just relatively marginal. What are the penalties, specifically?
- geodel 11y ago
  Since Rust does not provide sec-libs in standard distribution nor they are available in larger ecosystem, Rust benefits seems theoretical to me. As with other things in theory C/C++ code could also avoid memory/security issues.
  - bluejekyll 11y ago
    They do exist in the larger ecosystem, they are just very young. Also, we devs have had "don't build your own crypto" beaten into our heads so often lately that I think people are generally wary of starting new, or using new, projects that haven't already been battle hardened. I've looked at the OpenSSL code, and I have to say that it's not well documented in many cases and easy to make mistakes in it's usage. The rules on when locks are needed vs. not are not always clear, and then the ownership of memory is as confusing as it's always been in C. This is where something like Rust would shine just by cleaning up these interfaces. The Rust OpenSSL bindings, http://sfackler.github.io/rust-openssl/doc/v0.7.10/openssl/ http://sfackler.github.io/rust-openssl/doc/v0.7.10/openssl/ , for example are very sane, and it's difficult to screw up the usage.
konceptz 11y ago
I'd only go so far as to agree that vulnerabilities which are bug related maybe _detected_ by static analysis. Preventing vulnerabilities is an entirely larger problem not addressed by static analysis alone. Architectural security flaws are outside of the scope for static analysis. I'm not trying to nitpick semantics but in this case I think it's important to understand that, in this context, prevention and fixes as well as bugs and flaws need to be differentiated.
ashitlerferad 11y ago
Exploitation of some of those issues can be prevented using the new RAP GCC plugin by grsecurity. Unfortunately, it is only available to paying customers. https://grsecurity.net/rap_announce.php https://grsecurity.net/rap_announce.php https://grsecurity.net/rap_faq.php https://grsecurity.net/rap_faq.php https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.p...
- dfc 11y ago
  Does anyone know how much it costs to be a "paying customer" at the individual level? Im not OVH with a sea of rack mounts, I am just interested in covering a handful of machines.
  - ashitlerferad 11y ago
    Zero idea, but if you get an answer, please put it here and or post the GPL code publicly.

by zzzcpan 11y ago

nickpsecurity 11y ago

You can get complete spatial and temporal safety with Softbound + CETS: http://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/ http://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/ They and Cambridge CHERI team have hardware modifications, too, if you want to run C apps on FPGA CPU with inherent safety. Software-only, though, has significant performance penalties.

lmm 11y ago

> To be fair, most of the vulnerabilities found in C codebases are preventable with static analysis, bound checking, etc. You can work in an ad-hoc dialect of C based on particular tools that will be a bit safer than standard C, sure (though probably still not as safe as an actually memory-safe language). But at that point most of the advantages of C no longer apply: you don't have a huge library ecosystem, you don't have a supply of experienced developers, you don't have a bunch of standard automated tools that work with your dialect. > If you are ok with it getting as slow as Go, you can get similar safety guarantees as well. There is no native/standard/supported-by-tools way to do tagged unions, so whatever you do C will always be less safe than languages that have native tagged unions.

jjnoakes 11y ago
I don't think "most of the advantages of C no longer apply [if you use static analysis or bounds checking]" is fair. Even if your claims about losing libraries, experienced developers, or automated tools was true (which think is false), you still get portability, close-to-the-metal code, full control of your processes, direct access to the native ABI, full access to the platform facilities, fast compilation, small executables, standalone libraries, memory layout control, ...
- lmm 11y ago
  C code is less portable than most of the alternatives. In the rare cases where the things you list are hard requirements there are still safer options e.g. Ada.
  - jjnoakes 11y ago
    C code is less portable than which alternatives? As far as I know, most/all? alternatives are implemented in C or C++.
    - lmm 11y ago
      Plenty of alternatives are self-hosting, but that's neither here nor there. Even if it's a major effort to port e.g. the Python interpreter to a new platform (particularly the first new platform - once you have a C codebase that enforces portability over many platforms it's much easier to add a new one). But that major effort has by and large been done for even relatively obscure languages and relatively obscure platforms. Whereas if you write in C you get to do that major effort for yourself for each program.
      - jjnoakes 11y ago
        More portable means "can be ported to new platforms more easily", not "has been ported to new platforms by someone else". A C program (in general) is more portable than anything written on top of C because to port, say, Python to a new platform, one has to have C there first. It has nothing to do with whether the work has been done by you or someone else. Of course, one can write code in either language which is not portable, but that is also beside the point.
        lmm 11y ago
        > A C program (in general) is more portable than anything written on top of C because to port, say, Python to a new platform, one has to have C there first. Port C compiler -> port your C program vs port C compiler -> port Python interpreter -> port your Python program. The latter can still end up a lot easier and cheaper, because the Python interpreter is already multi-platform and Python programs tend not to have much if any platform-specific code by the nature of the language. > It has nothing to do with whether the work has been done by you or someone else. It has everything to do with that. Ultimately via Turing equivalence it's possible to port anything to anywhere, so when we're talking about "portability" we must be talking about how much it costs to port a program to a new or existing architecture. > Of course, one can write code in either language which is not portable, but that is also beside the point. Again, it's very much the point, because it can't possibly be a yes-or-no thing. How costly is typical/idiomatic C code to port? How costly is typical/idiomatic Python code? Those are the questions that matter when we talk about language portability.

vog 11y ago

> If you are ok with it getting as slow as Go, you can get similar safety guarantees as well. FWIW, Rust can make these guarantees without performance penalties.

seangrogg 11y ago
There are penalties, they are just relatively marginal.
- kibwen 11y ago
  Specifically, Rust does runtime bounds checking when you index into an array. LLVM is theoretically capable of optimizing these checks out if they're unnecessary, but it's far from guaranteed. It would take a dependent type system to perform compile-time bounds checking, and Rust isn't that sophisticated. However, indexing is far, far less prevalent in Rust than it is in C, due to the existence of iterators. I've asked the Servo team on multiple occasions whether the cost of bounds checking shows up in performance profiles, and they never have, likely because they just aren't doing very much indexing to begin with.
- pcwalton 11y ago
  > There are penalties, they are just relatively marginal. What are the penalties, specifically?
geodel 11y ago
Since Rust does not provide sec-libs in standard distribution nor they are available in larger ecosystem, Rust benefits seems theoretical to me. As with other things in theory C/C++ code could also avoid memory/security issues.
- bluejekyll 11y ago
  They do exist in the larger ecosystem, they are just very young. Also, we devs have had "don't build your own crypto" beaten into our heads so often lately that I think people are generally wary of starting new, or using new, projects that haven't already been battle hardened. I've looked at the OpenSSL code, and I have to say that it's not well documented in many cases and easy to make mistakes in it's usage. The rules on when locks are needed vs. not are not always clear, and then the ownership of memory is as confusing as it's always been in C. This is where something like Rust would shine just by cleaning up these interfaces. The Rust OpenSSL bindings, http://sfackler.github.io/rust-openssl/doc/v0.7.10/openssl/ http://sfackler.github.io/rust-openssl/doc/v0.7.10/openssl/ , for example are very sane, and it's difficult to screw up the usage.

konceptz 11y ago

I'd only go so far as to agree that vulnerabilities which are bug related maybe _detected_ by static analysis. Preventing vulnerabilities is an entirely larger problem not addressed by static analysis alone. Architectural security flaws are outside of the scope for static analysis. I'm not trying to nitpick semantics but in this case I think it's important to understand that, in this context, prevention and fixes as well as bugs and flaws need to be differentiated.

ashitlerferad 11y ago

Exploitation of some of those issues can be prevented using the new RAP GCC plugin by grsecurity. Unfortunately, it is only available to paying customers. https://grsecurity.net/rap_announce.php https://grsecurity.net/rap_announce.php https://grsecurity.net/rap_faq.php https://grsecurity.net/rap_faq.php https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.p...

dfc 11y ago
Does anyone know how much it costs to be a "paying customer" at the individual level? Im not OVH with a sea of rack mounts, I am just interested in covering a handful of machines.
- ashitlerferad 11y ago
  Zero idea, but if you get an answer, please put it here and or post the GPL code publicly.