5 ms·

> 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

> 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

> 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