I have no idea why you're being downvoted. Probably by a bunch of people who think they can write C and C++ without writing any security bugs. Which, unless they belong to a vanishingly small group of security experts who write code in an organization with the same discipline, budget and glacial schedule of the team writing software for the Space Shuttle, they can't.
Memory safety can't guarantee security or correctness. If you guys want to have a better discussion, you need to be even handed about the complexity of security. Languages can solve some classes of security problems.
Agreed. But memory safety is really such low-hanging fruit right now. Given that memory bugs still produce massive quantities of severe vulnerabilities, it seems appropriate to hammer on that aspect of languages.
If memory safety ever becomes a practically solved problem (e.g. somebody's running an OpenBSD-style count of how many days since a new memory bug popped up and it gets past, I don't know, hate to be greedy, how about 3?), then I'll be merrily banging away on the other aspects.
except that literally every piece of software you have ever written or used goes through some level of C, and lets face it, most of the C projects out there are actually pretty well tested.
and it's not like higher level languages are significantly better in this regard.
It's not like higher level languages are significantly better? Seriously?
The last time I accidentally executed injected code due to a free error or buggy bounds check in the non-C parts of Python, or Ruby, or Lisp, or Erlang was ... well, never.
And no, the fact that C underlies all these languages isn't a testimony to the adequacy of its security features.
That's so clearly false that it hardly deserves a response. I'm spending more time wondering if you are trolling that why you are wrong. But in case you aren't trolling:
1) A lot of "Python" security vulnerabilities are caused by "C"-problems (overflow errors, etc). [1] and [2] are a couple from this year.
2) You'd expect interpreting python to be more secure than C because the interpreter acts as a filter over input reducing the attack surface, meaning that potentially vulnerable paths are minimised are better tested than if an entire program was in C.
No, because writing a VM constitutes a reduction in attack surface. Implement a bytecode instruction properly once, and it's good everywhere it's used. Implement a correct garbage collector, and you don't have to worry about use-after-free anywhere in your Python code. You still have to worry about it in your C, though, and you have to make sure it's done correctly Every Single Place you do it. And if you think programmers are up to that task, go browse the CVEs for a while.
Look, I know lots of people like you think that C isn't that hard to get secure code from. But if you were correct, we wouldn't be living in the security cesspool of memory bugs we are now.
Technically you are correct: "C is not insecure". In the same way as "English is not offensive"
However programs written in C may or may not be insecure.
Of those programs you would expect a compiler or interpreter, that has been tested in the wild on millions of programs, and so you are more likely to find the security bugs. Also we hope these programs are written by very talented engineers.
On the other hand Joe Enterprise hacking up a greenfield web service for the first time in C ... more likely to have security bugs.
If Joe Enterprise moves from C to Java. Less likely to have security bugs.
Historical accident. People choose C, because nowadays it happens to be everywhere, which eases porting but there are lots of languages that could be used instead, if people valued safety.
Distressingly true. I despair that 20 years from now, absent an utterly wrenching change, we will all still be playing whack-a-mole with a seemingly infinite number of security bugs, many of monumental severity, all because we are unable to move away from our memory unsafe foundations.
And the endless supply of ignorant C/C++ programmers (of which I am not suggesting Damien is a member) who profess to management that they can easily write secure code does not help.
I beg your pardon? I've used valgrind for this purpose on large scientific codes running with MPI on supercomputers. And that works fine. The PETSc team at Argonne National Lab, who write perhaps the most used high-performance parallell linear algebra library in existence in C use valgrind for debugging. Surely those count as non-trivial applications?
HPC code is trivially 'easy' to write from this perspective. You mainly 'only' have to worry about memory leaks, dead locks or overflows on valid or accidentally miss-formated data. It's not like an army of world class hackers are pouring over your code looking for vulnerabilities to exploit. Nor that someone will intentionally try to craft input that will crash your application.
"If you ran valgrind (and mudflap) then any error that might be detected by a compiler with range checking will be detected."
Only if you can be sure you have touched all the interesting portions of input-space. Ideally your tests are doing this, but wherever your tests miss aren't covered by valgrind or mudflap but are covered by a change of language. That's a part of what's meant by safe. It's not that it's impossible to write correct code in an unsafe language. It's that it's difficult to impossible to verify that you have written correct code. I'm very willing to include available tools in that calculation, but valgrind and mudflap (while tremendously useful) cannot give guarantees.
Strictly, "... or that you can run your tests on an OS that does, and your code does not behave meaningfully differently between OSes." Either way, it may or may not be a strong assumption, depending on domain...
I think the parent was trying to say "no one has managed to use C safely in a non-trivial application", not "no one has managed to use mudflap or valgind on a nontrivial application".
I didn't say anything about whether either was correct. I simply was trying to help people avoid talking past each other, because the parent seems to be addressing something the grandparent didn't say.
People have unquestionably used Valgrind to find errors, in trivial and nontrivial applications. The question here is whether the result is "safe code". It may be, but the parent does not seem to be speaking to that question, hence my attempt at clarification.
I understood you, I was replying to the thread in general.
> ... the result is "safe code". It may be, but the parent does not seem to be speaking to that question ...
Here we differ. The ability to successfully run valgrind (and presumably remove all errors) does actually speak to the question, and it answers that the result is in fact safe code.
It is not necessary for the compiler to assure safe code, it's perfectly possible to do it with an external tool. And as a result C is a safe language as long as you use both tools.
If we presume "... and remove all errors" (and this can be done reliably), then yes that is speaking directly to the question and you have safe code. I would be surprised if the comment I replied to had intended to be asserting that, though. If that is what they intended, it would have been good for them to be more explicit about what amounts to the strongest claim made in the comment.
He kinda did. He writes that they changed from Erlang to C because of problems in Erlang. He wanted some safety or tools to help him find problems easier (actually problems in the language or libraries they used). They might develop slightly faster now in C than they did before in Erlang but I doubt it and the rewrite took time that probably cost them 2 months of inproductivity compared to not rewriting it. As for running speed they of course want that. Can't remember if they actually thought that low speed was problem with the earlier Couchbase.
Which is filled with security bugs. Consider the conventional sysadmin wisdom that if someone gets a shell on your box, it's as good as owned, due to a no doubt fertile field of privilege escalation vulnerabilities in the kernel.
Don't get me wrong -- the Linux kernel is a magnificent piece of engineering, and an excellent choice for hosting a mainstream server, I run a number of such myself -- but let's not kid ourselves about its security limitations.
Drivers in (everything, possibly Ocaml/Lua/Common Lisp/C++)
Os in everything.
The Linux kernel is not written in C but in a DSL that there is not yet a compiler to generate C. This is the same like Enlightment Object System and GObject.
moreover drivers should be written in a DSl language (Termite-like) that supports concurrency and provided by spec writters as an appendix.
The driver is two parts. The OS adaptation Layer and a Formal description of modus Operandis.
Consider USB, normally the spec provides an implementtion i a DSL that "compiles" to the prose.
One can mechanically check for invariants and properties and
compile to an OS package.
I think it is possible. Packages for example could describe transports
e.g. module BT uses an Ocaml-like interface for transport that can have various implementations like USB transport.
But all could be written in the same DSL.
Of course Kernel developers are allergic to memory management. Rust/Ocaml/D are the anti-histamine.
i'm sorry, but proof by convention or consensus is not a proof. you have an idea of the linux kernel, and it's not entirely unwarranted. but whilst there have obviously been security issues, it would be a mistake to suggest that they are the fault of C.
Let's just say that it's not C's fault. It's just that C is particularly well suited for creating security problems. The base semantics is dangerous, the undefined behaviors are lurking everywhere, and the compilers writers don't care ("it's the user fault if they go in undefined behavior that we put everywhere, and they'd better says thank you that we didn't ring their phone while they were in the bath the last time they did an integer multiplication without checking overflow, because the spec said we could have done it").
Sometimes I think the ebola crisis is created by a GCC developer. "I'm sorry for those people, but I was entitled to it, that guy there dereferenced a wild pointer, I could have cured cancer instead, but no".
Strictly speaking, you are correct. But saying C is not at fault is like finding the trivial solution to a polynomial -- it is correct but not very useful.
No, C is not at fault. The programmers are at fault. But it is prudent to ask, when some of the world's foremost programmers produce an apparently limitless number of CVEs as they do, whether they could use some help from the language. If the answer is yes, we should recognize that such help cannot come from C.
You can attribute fault to the programmer, or you can attribute fault to the language, but for every problem there is a solution that is simple easy and wrong.
Especially since system code is the place where safety matters most.