5 ms·

I don't understand why people still consider it acceptable to write security critical software in languages like C.

sarciszewski 11y ago
> I don't understand why people still consider it acceptable to write security critical software in languages like C. What would you rather it be written in, a language that is itself written in C?
- reasonishy 11y ago
  How many memory corruption / buffer overflow exploits have there been say in the JVM? Using something like Java does cut out a whole class of memory exploits...
  - rudolf0 11y ago
    >How many memory corruption / buffer overflow exploits have there been say in the JVM? There have actually been quite a lot. But they're generally not things that could be exploited in a typical Java network/web application. They're mostly an issue for sandbox escapes; e.g. Java applets in the browser.
- bch 11y ago
  The good thing about something like this (in the abstract) is that you've potentially got many users hammering the facilities in many ways, and it becomes battle-hardened as a result. To this end, Colin hisself is sort of doing this w/ libcperciva[0] to a degree. One library of common code shared among many projects. [0] https://news.ycombinator.com/item?id=10099294 https://news.ycombinator.com/item?id=10099294
  - nickpsecurity 11y ago
    That's a true benefit of using C. The more people know the language, the more people who can comprehend and improve the software. Goes for more than just security in terms of what's improved. Now, will this happen for a given project? Different issue entirely which might justify using an inherently, safer language.
- geofft 11y ago
  Most languages I can think of that would be better than C have solid non-C implementations. Ada has GNAT, a free software compiler that is itself written in Ada. Rust's compiler is in Rust (and, years ago, OCaml), though it uses LLVM, which is C++, for code generation. Go's reference implementation is I believe fully Go, although parts are mechanically translated from C. OCaml is mostly written in OCaml. etc. Besides, the problem is not that C is malware, it's that it's a bad language to write in. Once code exists in C, you can make it solid (https://sel4.systems https://sel4.systems is the logical extreme of that). So using a C-language compiler but doing actual development in not-C gives you way more defense-in-depth than doing day-to-day work in C.
  - vvanders 11y ago
    As much as I love Rust, I think it's a bit early to be using it in heavy production.
- nickpsecurity 11y ago
  PL/0 (MULTICS), PL/S (z/OS), ALGOL (MCP), LISP/Scheme (dozens), Fortran (PRIMOS), Pascal (UCSD p-system), BASIC (Apple II), Modula2/Oberon (Lilith & Oberon systems), and Ada (Army ASOS, i432 mainframe) are/were written in C? Actually, the answer is no and they implemented these OS's/runtimes without it. They vary in pro's and con's [with Fortran OS hilarious] but not being C-like was a good quality they share in common. Actually, MULTICS team specifically chose PL/0 over C's predecessor because they thought PL/0's design choices would lead to less security problems. They were right [1]. Using C for a project makes sense for numerous reasons that plenty others have elaborated elsewhere. Very talented people such as Tarsnap team can even use it robustly. However, it's inferior to many other system languages in productivity, robustness, maintenance, or some combo of these. And you can build fast, reliable systems (even OS's) without it. Its widespread use is a legacy/network effect caused by targeting cheap hardware, UNIX using it, key FOSS using it, resulting labor, and resulting libraries/tools for it. So, use it or not, but let's be honest about what it is and the why. [1] https://www.acsac.org/2002/papers/classic-multics.pdf https://www.acsac.org/2002/papers/classic-multics.pdf
derekp7 11y ago
I see this opinion expressed quite frequently. Avoiding C avoids only a limited number of potential bugs, and bugs can occur no matter what language you use. Also, when programming in a higher level language, chances are that if you need to do anything interesting, you are more likely to be using someone else's library module which in turn is written in C. Also, the higher level you go, the more framework is sitting underneath your code -- framework that you must understand 100% in order to avoid misusing it (not to mention flaws in that framework). Case in point -- how many web sites have been hacked that are written in PHP? or Wordpress? Avoiding C does not avoid bugs.
- geofft 11y ago
  > I see this opinion expressed quite frequently. Avoiding C avoids only a limited number of potential bugs, and bugs can occur no matter what language you use. That's not a useful comparison, since you're distilling the question of how many bugs there are to whether there are bugs. If a language gets you two security-critical bugs in a 10-year-long project, that's not a reason to say "Eh, might as well have used C". > Case in point -- how many web sites have been hacked that are written in PHP? or Wordpress? Avoiding C does not avoid bugs. Sure, don't write security-critical software in PHP either. There are other languages in the world; some of them are specifically designed for writing security-critical software (e.g., Ada and Rust), some happen to be much better than C due to other parts of their design (e.g., Go, Haskell, idiomatic C++11, Vala), and some happen to be not significantly better than C (e.g., PHP, Python, Perl, bash, etc. etc.).
  - glass- 11y ago
    > Rust So instead of using C we should write our security-critical software in a language that was released 3 months ago and has no major deployments.
    - geofft 11y ago
      Yes, agreed. We should choose languages based on their suitability for the job, not how long they've been free to ruin the world. That said, if you have some sort of external constraint about using a language merely because other people are using it, there's Ada, which is over three decades old and has numerous major deployments.
feld 11y ago
ah, yes, we should use java.
- AgentME 11y ago
  Non-malicious Java applications almost never have remotely-exploitable buffer overflow or memory corruption bugs. Java's issues are nearly entirely sandbox escape issues that stop malware that's chosen to be run from being sandboxed completely.
vezzy-fnord 11y ago
Control over memory layout and timing. [1] [1] https://cryptocoding.net/index.php/Coding_rules https://cryptocoding.net/index.php/Coding_rules
jrockway 11y ago
Security problems aren't just buffer overflows. Using another language gives you another set of problems. And of course, the underlying problem is the computation model employed by all modern computers, so using a higher-level language doesn't necessarily protect you from buffer overflows. I'd say the biggest trap for young players is the C standard library, rather than anything about C the language. Null-terminated strings are very space efficient, but hard to work with. If you're willing to use something like bstrings, then you're setting yourself up for a higher likelihood of success. But most people choose what's built in, either for compatibility with other libraries, inertia, or not wanting yet another dependency, and then mess something up.
- munin 11y ago
  > Using another language gives you another set of problems No, you have those problems in C too. Using another language gives you the problems you had before and takes away the memory safety problems.

> I don't understand why people still consider it acceptable to write security critical software in languages like C. What would you rather it be written in, a language that is itself written in C?

reasonishy 11y ago
How many memory corruption / buffer overflow exploits have there been say in the JVM? Using something like Java does cut out a whole class of memory exploits...
- rudolf0 11y ago
  >How many memory corruption / buffer overflow exploits have there been say in the JVM? There have actually been quite a lot. But they're generally not things that could be exploited in a typical Java network/web application. They're mostly an issue for sandbox escapes; e.g. Java applets in the browser.
bch 11y ago
The good thing about something like this (in the abstract) is that you've potentially got many users hammering the facilities in many ways, and it becomes battle-hardened as a result. To this end, Colin hisself is sort of doing this w/ libcperciva[0] to a degree. One library of common code shared among many projects. [0] https://news.ycombinator.com/item?id=10099294 https://news.ycombinator.com/item?id=10099294
- nickpsecurity 11y ago
  That's a true benefit of using C. The more people know the language, the more people who can comprehend and improve the software. Goes for more than just security in terms of what's improved. Now, will this happen for a given project? Different issue entirely which might justify using an inherently, safer language.
geofft 11y ago
Most languages I can think of that would be better than C have solid non-C implementations. Ada has GNAT, a free software compiler that is itself written in Ada. Rust's compiler is in Rust (and, years ago, OCaml), though it uses LLVM, which is C++, for code generation. Go's reference implementation is I believe fully Go, although parts are mechanically translated from C. OCaml is mostly written in OCaml. etc. Besides, the problem is not that C is malware, it's that it's a bad language to write in. Once code exists in C, you can make it solid (https://sel4.systems https://sel4.systems is the logical extreme of that). So using a C-language compiler but doing actual development in not-C gives you way more defense-in-depth than doing day-to-day work in C.
- vvanders 11y ago
  As much as I love Rust, I think it's a bit early to be using it in heavy production.
nickpsecurity 11y ago
PL/0 (MULTICS), PL/S (z/OS), ALGOL (MCP), LISP/Scheme (dozens), Fortran (PRIMOS), Pascal (UCSD p-system), BASIC (Apple II), Modula2/Oberon (Lilith & Oberon systems), and Ada (Army ASOS, i432 mainframe) are/were written in C? Actually, the answer is no and they implemented these OS's/runtimes without it. They vary in pro's and con's [with Fortran OS hilarious] but not being C-like was a good quality they share in common. Actually, MULTICS team specifically chose PL/0 over C's predecessor because they thought PL/0's design choices would lead to less security problems. They were right [1]. Using C for a project makes sense for numerous reasons that plenty others have elaborated elsewhere. Very talented people such as Tarsnap team can even use it robustly. However, it's inferior to many other system languages in productivity, robustness, maintenance, or some combo of these. And you can build fast, reliable systems (even OS's) without it. Its widespread use is a legacy/network effect caused by targeting cheap hardware, UNIX using it, key FOSS using it, resulting labor, and resulting libraries/tools for it. So, use it or not, but let's be honest about what it is and the why. [1] https://www.acsac.org/2002/papers/classic-multics.pdf https://www.acsac.org/2002/papers/classic-multics.pdf

derekp7 11y ago

I see this opinion expressed quite frequently. Avoiding C avoids only a limited number of potential bugs, and bugs can occur no matter what language you use. Also, when programming in a higher level language, chances are that if you need to do anything interesting, you are more likely to be using someone else's library module which in turn is written in C. Also, the higher level you go, the more framework is sitting underneath your code -- framework that you must understand 100% in order to avoid misusing it (not to mention flaws in that framework). Case in point -- how many web sites have been hacked that are written in PHP? or Wordpress? Avoiding C does not avoid bugs.

geofft 11y ago
> I see this opinion expressed quite frequently. Avoiding C avoids only a limited number of potential bugs, and bugs can occur no matter what language you use. That's not a useful comparison, since you're distilling the question of how many bugs there are to whether there are bugs. If a language gets you two security-critical bugs in a 10-year-long project, that's not a reason to say "Eh, might as well have used C". > Case in point -- how many web sites have been hacked that are written in PHP? or Wordpress? Avoiding C does not avoid bugs. Sure, don't write security-critical software in PHP either. There are other languages in the world; some of them are specifically designed for writing security-critical software (e.g., Ada and Rust), some happen to be much better than C due to other parts of their design (e.g., Go, Haskell, idiomatic C++11, Vala), and some happen to be not significantly better than C (e.g., PHP, Python, Perl, bash, etc. etc.).
- glass- 11y ago
  > Rust So instead of using C we should write our security-critical software in a language that was released 3 months ago and has no major deployments.
  - geofft 11y ago
    Yes, agreed. We should choose languages based on their suitability for the job, not how long they've been free to ruin the world. That said, if you have some sort of external constraint about using a language merely because other people are using it, there's Ada, which is over three decades old and has numerous major deployments.

feld 11y ago

ah, yes, we should use java.

AgentME 11y ago
Non-malicious Java applications almost never have remotely-exploitable buffer overflow or memory corruption bugs. Java's issues are nearly entirely sandbox escape issues that stop malware that's chosen to be run from being sandboxed completely.

vezzy-fnord 11y ago

Control over memory layout and timing. [1] [1] https://cryptocoding.net/index.php/Coding_rules https://cryptocoding.net/index.php/Coding_rules

jrockway 11y ago

Security problems aren't just buffer overflows. Using another language gives you another set of problems. And of course, the underlying problem is the computation model employed by all modern computers, so using a higher-level language doesn't necessarily protect you from buffer overflows. I'd say the biggest trap for young players is the C standard library, rather than anything about C the language. Null-terminated strings are very space efficient, but hard to work with. If you're willing to use something like bstrings, then you're setting yourself up for a higher likelihood of success. But most people choose what's built in, either for compatibility with other libraries, inertia, or not wanting yet another dependency, and then mess something up.

munin 11y ago
> Using another language gives you another set of problems No, you have those problems in C too. Using another language gives you the problems you had before and takes away the memory safety problems.