6 ms·

Writing secure software in C is just next to impossible. Memory corruption, arbitrary pointers, deep magic. Even pure assembly is more secure, as everything is

Writing secure software in C is just next to impossible. Memory corruption, arbitrary pointers, deep magic. Even pure assembly is more secure, as everything is explicit and well-defined there. There are lots of safer languages than C, and performance is not everything.

stcredzero 11y ago
Is there a language that has powerful tools for dealing with timing attacks and can facilitate correctness proofs?
- TheMagicHorsey 11y ago
  Ocaml
  - sbierwagen 11y ago
    Isn't ocaml garbage collected? Won't the GC pauses leak timing info?
    - bmm6o 11y ago
      If you are generating different amounts of garbage depending on your secrets, that's already showing up as leaked timing information.
- nickpsecurity 11y ago
  You can deal with timing attacks using Kemmerer's Shared Resource Matrix to find those and other covert channels. Then, you just look at the bandwidth of them along with design alternatives that don't leak timing. You can sometimes make the timing predictable or non-data-driven at interface level to nullify that. An example comes from military-grade stuff way back that transmitted in fixed-length, fixed-rate packets. Markus Ottela added that to Tinfoil Chat at my recommendation. Far as correctness proofs, a combo of Ada 2012 with Design-by-Contract and SPARK is probably best at that. Far as app level, just program in a functional style with abstract state machines. Make it more concrete and detailed, replicating analysis or tests at each level. Eventually, you run the code checkers on the result and throw in some fuzz testing. No easy route, though, that I'm aware. Highly assured software and system design is a painstaking process. Avoiding risky stuff, defining all success/fail traces, failing safe, and static analysis to preempt bugs are the strongest route. Plus source-to-object correspondence to be sure compiler didn't eliminate safety checks or introduce problems. Spark Pro supports that.
nine_k 11y ago
I heard Rust can be pretty efficient? OTOH a heavily restricted C, closer to assembly than to Rust, could still be useful: it would be close to the metal but still preserve portability. Making such a language a strict subset of C would additionally help early porting efforts.
- protomyth 11y ago
  Ada can be amazingly efficient. It just isn't cool. I've often wondered what would happen if someone pulled a reskining of the language (ala VB.NET >> C#) what would happen.
  - kevin_thibedeau 11y ago
    VB.NET is a reskin of C#.
    - protomyth 11y ago
      Yeah, but in Ada's case it would look like you're going the other way (to { }). [edit: folks really shouldn't down vote kevin_thibedeau, he is correct after all]
  - nickpsecurity 11y ago
    I considered making a variant of Go or Pascal that enforced Ada's safety properties for common operations by default without anything else in it. Turn it off on a per-module basis still with type or interface checks. Result might get a bit more uptake.
- ufo 11y ago
  If you want to have a language be a "C killer" for secure software you need to put a lot of emphasis on simplicity and portability, which are not strengths of Rust. I think that if you get rid of raw pointers and type casts, you are able to avoid most undefined behavior with dynamic checks: bounds checking, tagged unions, etc. The notable exception is concurrency bugs, which are hard to avoid without a restrictive static analyzer, but I think there is an argument to be made that perhaps the kind of code mr Bernstein wants to write is better off with "boring" sequential algorithms.
deleted 11y ago
[deleted]
Animats 11y ago
It's too bad Pascal is dead. Wirth's original recursive-descent Pascal compiler was utterly straightforward. It produced mediocre, predictable code. I have hope for Rust, but in terms of complexity, it seems to be picking up where C++ left off.
- atemerev 11y ago
  It is not dead. You can still take FreePascal and write some security conscious code with it, to be linked with other parts of your application. The compiler works. There is also Lua. And Haskell and Ocaml compilers for FP people. These languages are easily linkable with C/C++ codebases.
- kibwen 11y ago
  I'm not sure where you got the impression that "Rust is picking up where C++ left off". Rust is a far, far, far smaller language than C++, and has benefited from hindsight in its design in a way that C++ cannot without massively breaking backwards compatibility.
- nickpsecurity 11y ago
  What did you think about Modula-3? I like how it had much of what a C++ programmer might want in a cleaner, safer, faster-to-compile way. Most Modula and Oberon derived languages had little to no undefined behavior outside the Unsafe modules. All were used to write OS's & other low-level code. Optional GC where it was tolerable. IIRC, Modula-3 also had verification done on its standard modules to catch certain errors. Some of the design attributes might be worth resurrecting in another project. Minus the capitalized keywords. :)
  - Animats 11y ago
    I wrote much of an OS in Modula I. I wrote robotics code in Modula II. I didn't do much with Modula III, but I knew some of the people behind it at DEC SRL, before Compaq bought DEC and shut down research. I wish computing had gone that way, instead of C/C++. Everything would be less buggy.
IvyMike 11y ago
> Writing secure software in C is just next to impossible. This is true. And it was true when I learned C, and was told almost the same exact thing on the second day of class. In 1992. Maybe eventually we'll collectively move to something safer, but at this point I've stopped holding my breath. DJB's proposal seems pretty reasonable in the interim.
rosser 11y ago
Then how do you explain the fact that some of the most secure pieces of software ever written were written in C? (I'm thinking of, e.g., Qmail — and pretty much everything else DJB has ever written — and OpenBSD, just to name a couple off the top of my head.) I would also qualify your statement that "performance is not everything" to say that performance isn't always everything. Writing a kernel in an interpreted language probably isn't the best idea, for example.
- admax88q 11y ago
  Because C has a lot of momentum, and interoperability, thus lots of security software was written. This software isn't secure because of C but despite of it, and has had a long list of security vulnerabilities that a safer language would have protected us from.
  - mayank 11y ago
    > and has had a long list of security vulnerabilities that a safer language would have protected us from. Care to point to the "long list of security vulnerabilities" in qmail?
    - oldmanjay 11y ago
      I'm very interested to know what point you believe you are making here. I ask because it is fairly clear you aren't addressing the topic of the thread and I wonder if you believe you are.
- gherkin0 11y ago
  > Then how do you explain the fact that some of the most secure pieces of software ever written were written in C? (I'm thinking of, e.g., Qmail — and pretty much everything else DJB has ever written — and OpenBSD, just to name a couple off the top of my head.) Unusual amounts of manual effort by unusually skilled people, probably using unusually security-focused development processes?
  - 11y ago
chillingeffect 11y ago
Please don't spread unnecessary fear. ("deep magic"). C is as secure as developers take their time to implement. A fantastic amount of dangerous stuff currently runs on C. C has several substandards, such as MISRA and JSF, to aid developers in writing safe C, eliminating arguments about "well-defined." A good start is bounds checking and following MISRA. Languages like Rust make it cheaper, but security never comes for free.
- atemerev 11y ago
  Indeed, security never comes for free, but costs can vary tremendously. In case of C, there are layers of additional rulesets (not enforced by compiler), scrutiny and coding standards even for basic things. I do not subscribe to formal verification crowd claims, but some basic things can make great improvements. E.g. immutability by default.
spc476 11y ago
Please define which assembly you are talking about. Older CPUs didn't trap on undefined opcodes (I'm talking things like the 8080, Z80, 6502, 6809, etc). And even on a more modern CPU (say, the x86 line) I see that the condition flags after a DIV are all undefined (Z, C, S, O, all undefined; also, MUL also leaves the flags undefined). But yes, assembly languages tend to be more defined than C.

stcredzero 11y ago

Is there a language that has powerful tools for dealing with timing attacks and can facilitate correctness proofs?

TheMagicHorsey 11y ago
Ocaml
- sbierwagen 11y ago
  Isn't ocaml garbage collected? Won't the GC pauses leak timing info?
  - bmm6o 11y ago
    If you are generating different amounts of garbage depending on your secrets, that's already showing up as leaked timing information.
nickpsecurity 11y ago
You can deal with timing attacks using Kemmerer's Shared Resource Matrix to find those and other covert channels. Then, you just look at the bandwidth of them along with design alternatives that don't leak timing. You can sometimes make the timing predictable or non-data-driven at interface level to nullify that. An example comes from military-grade stuff way back that transmitted in fixed-length, fixed-rate packets. Markus Ottela added that to Tinfoil Chat at my recommendation. Far as correctness proofs, a combo of Ada 2012 with Design-by-Contract and SPARK is probably best at that. Far as app level, just program in a functional style with abstract state machines. Make it more concrete and detailed, replicating analysis or tests at each level. Eventually, you run the code checkers on the result and throw in some fuzz testing. No easy route, though, that I'm aware. Highly assured software and system design is a painstaking process. Avoiding risky stuff, defining all success/fail traces, failing safe, and static analysis to preempt bugs are the strongest route. Plus source-to-object correspondence to be sure compiler didn't eliminate safety checks or introduce problems. Spark Pro supports that.

nine_k 11y ago

I heard Rust can be pretty efficient? OTOH a heavily restricted C, closer to assembly than to Rust, could still be useful: it would be close to the metal but still preserve portability. Making such a language a strict subset of C would additionally help early porting efforts.

protomyth 11y ago
Ada can be amazingly efficient. It just isn't cool. I've often wondered what would happen if someone pulled a reskining of the language (ala VB.NET >> C#) what would happen.
- kevin_thibedeau 11y ago
  VB.NET is a reskin of C#.
  - protomyth 11y ago
    Yeah, but in Ada's case it would look like you're going the other way (to { }). [edit: folks really shouldn't down vote kevin_thibedeau, he is correct after all]
- nickpsecurity 11y ago
  I considered making a variant of Go or Pascal that enforced Ada's safety properties for common operations by default without anything else in it. Turn it off on a per-module basis still with type or interface checks. Result might get a bit more uptake.
ufo 11y ago
If you want to have a language be a "C killer" for secure software you need to put a lot of emphasis on simplicity and portability, which are not strengths of Rust. I think that if you get rid of raw pointers and type casts, you are able to avoid most undefined behavior with dynamic checks: bounds checking, tagged unions, etc. The notable exception is concurrency bugs, which are hard to avoid without a restrictive static analyzer, but I think there is an argument to be made that perhaps the kind of code mr Bernstein wants to write is better off with "boring" sequential algorithms.

deleted 11y ago

[deleted]

Animats 11y ago

It's too bad Pascal is dead. Wirth's original recursive-descent Pascal compiler was utterly straightforward. It produced mediocre, predictable code. I have hope for Rust, but in terms of complexity, it seems to be picking up where C++ left off.

atemerev 11y ago
It is not dead. You can still take FreePascal and write some security conscious code with it, to be linked with other parts of your application. The compiler works. There is also Lua. And Haskell and Ocaml compilers for FP people. These languages are easily linkable with C/C++ codebases.
kibwen 11y ago
I'm not sure where you got the impression that "Rust is picking up where C++ left off". Rust is a far, far, far smaller language than C++, and has benefited from hindsight in its design in a way that C++ cannot without massively breaking backwards compatibility.
nickpsecurity 11y ago
What did you think about Modula-3? I like how it had much of what a C++ programmer might want in a cleaner, safer, faster-to-compile way. Most Modula and Oberon derived languages had little to no undefined behavior outside the Unsafe modules. All were used to write OS's & other low-level code. Optional GC where it was tolerable. IIRC, Modula-3 also had verification done on its standard modules to catch certain errors. Some of the design attributes might be worth resurrecting in another project. Minus the capitalized keywords. :)
- Animats 11y ago
  I wrote much of an OS in Modula I. I wrote robotics code in Modula II. I didn't do much with Modula III, but I knew some of the people behind it at DEC SRL, before Compaq bought DEC and shut down research. I wish computing had gone that way, instead of C/C++. Everything would be less buggy.

IvyMike 11y ago

> Writing secure software in C is just next to impossible. This is true. And it was true when I learned C, and was told almost the same exact thing on the second day of class. In 1992. Maybe eventually we'll collectively move to something safer, but at this point I've stopped holding my breath. DJB's proposal seems pretty reasonable in the interim.

rosser 11y ago

Then how do you explain the fact that some of the most secure pieces of software ever written were written in C? (I'm thinking of, e.g., Qmail — and pretty much everything else DJB has ever written — and OpenBSD, just to name a couple off the top of my head.) I would also qualify your statement that "performance is not everything" to say that performance isn't always everything. Writing a kernel in an interpreted language probably isn't the best idea, for example.

admax88q 11y ago
Because C has a lot of momentum, and interoperability, thus lots of security software was written. This software isn't secure because of C but despite of it, and has had a long list of security vulnerabilities that a safer language would have protected us from.
- mayank 11y ago
  > and has had a long list of security vulnerabilities that a safer language would have protected us from. Care to point to the "long list of security vulnerabilities" in qmail?
  - oldmanjay 11y ago
    I'm very interested to know what point you believe you are making here. I ask because it is fairly clear you aren't addressing the topic of the thread and I wonder if you believe you are.
gherkin0 11y ago
> Then how do you explain the fact that some of the most secure pieces of software ever written were written in C? (I'm thinking of, e.g., Qmail — and pretty much everything else DJB has ever written — and OpenBSD, just to name a couple off the top of my head.) Unusual amounts of manual effort by unusually skilled people, probably using unusually security-focused development processes?
- 11y ago

chillingeffect 11y ago

Please don't spread unnecessary fear. ("deep magic"). C is as secure as developers take their time to implement. A fantastic amount of dangerous stuff currently runs on C. C has several substandards, such as MISRA and JSF, to aid developers in writing safe C, eliminating arguments about "well-defined." A good start is bounds checking and following MISRA. Languages like Rust make it cheaper, but security never comes for free.

atemerev 11y ago
Indeed, security never comes for free, but costs can vary tremendously. In case of C, there are layers of additional rulesets (not enforced by compiler), scrutiny and coding standards even for basic things. I do not subscribe to formal verification crowd claims, but some basic things can make great improvements. E.g. immutability by default.

spc476 11y ago

Please define which assembly you are talking about. Older CPUs didn't trap on undefined opcodes (I'm talking things like the 8080, Z80, 6502, 6809, etc). And even on a more modern CPU (say, the x86 line) I see that the condition flags after a DIV are all undefined (Z, C, S, O, all undefined; also, MUL also leaves the flags undefined). But yes, assembly languages tend to be more defined than C.