Hacker News Reader

Comment by Someone1234 | Hacker News Reader

I too love C.

I'd almost go so far as to say you need to do a security review before you write one line of code. You need to evaluate if C is a requirement or a preference, and if the security of the project can withstand being written in C (e.g. edge code that may be attacked).

The argument that C (and C++) can be written well or flawlessly is tiresome. "Perfect code" is a fallacy that has been proven over and over again to be untrue and dangerously untrue. You should assume the code quality is less than optimal as your starting point.

I am not promoting any specific alternative (Rust, Java, Go, etc) I am just saying that C/C++ are insecure by design and should be avoided unless they're a project requirement.

View on HN

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.

You can get complete spatial and temporal safety with Softbound + CETS:

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.

> 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.

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, ...

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.

C code is less portable than which alternatives?

As far as I know, most/all? alternatives are implemented in C or C++.

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.

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.

> 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.

By definition, the C language is more portable than the Python language, because in order to run Python on a system, C must run there first.

Unless you are talking about a Python not implemented in C, or a C compiler that was created to only compile the Python interpreter (and not all of the C language), then there is no other way around this simple fact.

A standard-conforming program should be part of the topic here, not "typical/idiomatic" non-objective software. Just because most people may not write portable C code doesn't make the language itself more or less portable. It just makes those particular programs less portable.

Plenty of C code is highly portable. Plenty is not. Same can be said of Python. It is moot. The language is under discussion here, not any set of specific programs written in the language.

Also, beside that simple logical conclusion, it is 2-3 orders of magnitude easier for me to port a C program I wrote to a new platform than it is for me to port the Python interpreter just to support my Python program on a new platform. Nevermind all of the features I would have to port (or neuter) inside Python which my program may not even use.

> By definition, the C language is more portable than the Python language, because in order to run Python on a system, C must run there first.

What definition are you using, and what practical use is your definition? You seem to be defining "portable" in some absurd, irrelevant way so that your preferred language "wins", regardless of what that actually means.

> A standard-conforming program should be part of the topic here, not "typical/idiomatic" non-objective software. Just because most people may not write portable C code doesn't make the language itself more or less portable. It just makes those particular programs less portable. > Plenty of C code is highly portable. Plenty is not. Same can be said of Python. It is moot. The language is under discussion here, not any set of specific programs written in the language.

The standard is just some words on a page. The programs and tools are what give it meaning. If 90%+ of the things we call "C programs" don't conform to the standard, it's not reasonable to treat the standard as the definition of a "C program". And for any practical, real-world decision like "should I write my program in C or Python", the typical/idiomatic is the question that matters.

> it is 2-3 orders of magnitude easier for me to port a C program I wrote to a new platform than it is for me to port the Python interpreter just to support my Python program on a new platform. Nevermind all of the features I would have to port (or neuter) inside Python which my program may not even use.

How often do you port things to a platform on which the Python interpreter doesn't already build? And how large are these programs for the 2-3 orders of magnitude? (I guess small in any case if you're talking about writing a program yourself rather than in a team). The Python interpreter is actually pretty small.

Are you being obtuse on purpose?

There are C compilers for N platforms. There are Python interpreters for M platforms. Since the Python interpreter is written in C, N >= M.

The programs I have ported are more than a million lines. Not the largest, sure, but not trivial. And they run on platforms where Python does not.

The size of the C code or the Python interpreter code does not matter. What does matter is what subsystems are required. Python is general purpose and has a wide set of requirements (networking, file systems, process manipulation, dynamic loading, the list is quite long). Oh, and the Python list includes compiling C programs (for extensions). A second reason backing my absurd definition.

The C programming language requirements placed on the hosting environment are much smaller. So the language is more portable for that reason as well. It is beneficial to only port what you use, instead of having to port a monolithic interpreter, including the parts you don't need (which may not even run on the target platform easily or at all).

> There are C compilers for N platforms. There are Python interpreters for M platforms. Since the Python interpreter is written in C, N >= M.

Sure, but existence of a compiler is only a small piece of portability. As a FreeBSD user I'm very used to downloading a random program and finding it won't run on my platform. Happens a lot more often when the program's written in C than when it's written in Python.

So? The existence of a conforming C compiler is all it takes for the C language to have been ported to that platform.

Or do you think C isn't ported to a platform unless every random C program you download from the internet compiles and runs?

I think portability is best understood as a measure of how difficult/expensive it is to port a typical program in that language to a new platform, because that's the question which is likely to be relevant in practice.

That doesn't define the portability of the language though, that only discusses typical programs. They aren't the same thing at all.

The portability of a language is best understood as how difficult/expensive it is to port a conforming program written in the language in question.

It's easy to confuse the two. But a discussion based on that confusion is not very useful, as you are discovering.

> The portability of a language is best understood as how difficult/expensive it is to port a conforming program written in the language in question.

What proportion of the things that are referred to in ordinary, everyday language as "C programs" would you estimate are conforming? Maybe 0.01%? If I'd meant "conforming C code" I would've said "conforming C code".

Writing conforming C is not a realistic choice for most use cases. E.g. there are very few experienced conforming C developers available.

I don't think any of your assertions are true at all.

There are lots of conforming C programs (just look at the huge list of software which compiles on a huge list of platforms).

There are tons of experienced C developers. Who do you think writes all of that conforming software?

And none of this is related to the topic at all.

If you really can't get your head around the simple idea that the portability of the language is different than the portability of some arbitrary program written in the language, then just look at it this way: If you want to write a program in a language, and you pick C, your program will run on more platforms than if you pick Python.

This is true, regardless of any other argument you might raise, simply because Python won't run on a platform until C runs on that platform (since Python is written in C).

We've been over this. Ad nauseum. Please stop trolling.

> There are lots of conforming C programs (just look at the huge list of software which compiles on a huge list of platforms).

And look at how much of that list breaks when a new version of GCC introduces a minor improvement in optimization.

> just look at it this way: If you want to write a program in a language, and you pick C, your program will run on more platforms than if you pick Python.

That is the question to ask. And your answer simply isn't true. It will (in the overwhelmingly likely case) run on more platforms if you pick Python. Certainly if you hold costs constant, which is surely the only way to compare. If you're willing to spend unlimited time and effort on portability then your C program will run everywhere, but so will your Python program (since you can just port the Python interpreter).

> This is true, regardless of any other argument you might raise, simply because Python won't run on a platform until C runs on that platform (since Python is written in C).

Not actually true (Jython exists and could run on platforms that don't run C), but it doesn't matter. It is overwhelmingly likely that the Python interpreter will run on more platforms than your C program will.

> We've been over this. Ad nauseum. Please stop trolling.

I'm not trolling. Maybe you are?

> 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.

There are penalties, they are just relatively marginal.

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.

> There are penalties, they are just relatively marginal.

What are the penalties, specifically?

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.

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/ , for example are very sane, and it's difficult to screw up the usage.

Do you mean Rust-openssl bindings will not require patching openssl for Rust apps in case vulnerabilty? In that case Rust surely helps applications written in it.

What are "sec-libs"? From the other reply it seems "sec-libs" are the hip mounted pouches of enchanted crypto dust so you can sprinkle it around and get "security".

I don't see any other way to read this other than "there's no point in rewriting security code in Rust because security code in Rust hasn't been written yet". That, obviously, doesn't make sense to me.

You do not see any other way to read because you are looking to argue over innocuous statement which is not even false. Security code in Rust could be great and I will be happy if and when it is available for general use.

I agree with pcwalton, that's how I read it too. The context of this thread is security vulnerabilities in OpenSSL, so it's quite reasonable to read your parent comment exactly as pcwalton did.

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.

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_faq.php https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.p...

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.

Zero idea, but if you get an answer, please put it here and or post the GPL code publicly.

C++ is vastly different animal than C in this case. Most of the problems with C you are implying here are non issues in modern C++.

The key being modern C++.

A lot of C++ projects aren't written in modern C++ and out of the few that are, even then, programmers will mix in older less secure C++ because they lack experience with modern C++. So habits can actually hurt security.

Ultimately when you have a language which mixes secure and insecure practises and lets the programmer decide, as an outside observer you have to assume the worst unless shown otherwise. C++ can be written very well, but C++ can also be written no better than C, it is project by project for which is which.

Other languages don't have this issue. If you see a Rust, Go, Java, C#, etc block of code you can make certain assumptions about what classes of security issues it won't have.

You're saying exactly the same thing.

"This environment can shoot me in the foot, but not if I do it right."

MISRA C with copious static analysis and a talented QA team is safe, too!

Web browsers use modern C++ and still have security issues. It's a step forward, but not a panacea.

to what extent? i imagine the codebases are quite...mature. and gigantic.

Everywhere. We have been using smart pointers for a long time.

Modern C++ doesn't add any memory safety protection beyond that which was already available with custom smart pointers in earlier versions of C++. In fact, I think modern C++ is less safe than earlier versions, due to new classes of potential bugs like use-after-move and the ease with which closed-over variable references in lambdas can become dangling.

> Most of the problems with C you are implying here are non issues in modern C++.

No, they aren't. Use after free is just as exploitable and is a severe concern in C++. In fact, it's worse in C++ than in C, due to the ubiquity of vtables.

This sounds like a witch hunt. Java has horrible security bugs even today.

Bugs can be found in code written in all languages.

Java removed certain classes of errors (memory management). It introduced other (providing an insecure sandbox for applets).

I think code execution by insecure deserialization is the big Java security problem now, though I'm neither a security guy nor a Java guy.

It's not like C applets are safer.

If we consider NaCl to be "C applets"... yes, it actually is safer.

Right. And certain languages remove entire classes of bugs.

No disputing that bugs can be written in any language. But by avoiding C/C++ you're excluding a specific class of bugs which have historically proved harmful.

You can write exploitable code in Java. But you'd actually have to try if you wanted Java to be able to write arbitrary memory or execute arbitrary code.

Essentially any bug that can be written in Java/Go/Rust/etc can be written in C/C++. But some C/C++ bugs are extremely uncommon in other languages, or you have to actually TRY to introduce them.

Intent doesn't matter; results do. This is a heatmap problem - there's simply more 'C'/C++ code out there.

I'm pretty sure there is more (and a greater variety of) net facing Java code than C/C++ code.

You may be right. I'm just thinking that everything( has an O/S and it's probably written largely in 'C'. So much will depend on how you measure it.

I tend to ignore the web as much as possible.

> But you'd actually have to try if you wanted Java to be able to write arbitrary memory or execute arbitrary code.

Depends on your definition of arbitrary. Higher level languages have higher level exploits. While injecting x86 shellcode into a java process is probably hard, many java applications have been vulnerable to serialization bugs which result in the execution of arbitrary bytecode.

Source: http://www.darkreading.com/informationweek-home/why-the-java...

Nobody is saying RCE is impossible in memory safe languages, just much less likely.

And this needs to be said more "RCE is possible in Rust", because sometimes it is portrayed in almost unassailable terms.

It also needs to be said that this is generally not a reasonable reason to pick C over Rust. Memory-safe languages are effective defenses against these flaws.

>Bugs can be found in code written in all languages.

But not all languages frequently produce security vulnerabilities as a result of common types of bugs that are due to error-prone humans having to do things that should be done for us automatically in the year of our Lord 2016

To be clear, are you referring to security bugs in the Java standard library (written almost completely in Java), or those in the JVM itself or the browser plugins (written almost entirely in C++), or in Java code bases?

The vast majority of the high profile Java security bugs have been in the second, which would be more of a ding against C++ than Java the language, wouldn't it?

I think it would be against Java in sense Java does not support writing high performance code like Java runtime / security code etc. Now it may not have errors as much as openssl but that argument will be about implementation quality not against C/C++.

Most the horrible security bugs in Java show up in the sandbox, where attackers can supply arbitrary code for you to run.

In contrast, Java as a server language has an excellent security record IME. The last public patch panic I can remember was in 2011 with the denial of service bug regarding parsing of floating points. There has been other security bugs regarding cryptography etc, I'm sure, but in general you can feel very secure running Java on your servers.

It is a shame that security bugs for both are bundled together, making every sandbox compromise a "Remote exploitable" vulnerability. The "applet" use case should probably just die, there is no indication that Java sandboxing will ever be secure, the design is unsound.

Oracle is deprecating the Java browser plugin in JDK 9, ie. the applet use case. There will still be support for Java Web Start though.

I've always wondered why nobody sandboxes Java applets in a LXC/Docker container or in a chrome sandbox the same way flash is contained.

Java as a server language has a record of nasty serialization-related RCE vulnerabilities. Of course, they're in popular Java libraries used on the server rather than the language itself, just like this bug was in a popular C library rather than the language itself - but Java makes it very easy to accidentally write that kind of vulnerability. In fact, just loading two unrelated libraries that are individually safe sometimes create an exploitable RCE condition in Java. That's worse than even C.

Not sure what 'horrible security bugs' in Java you are referring too.

If those you refer too, and there are many, are exploits in browser plugins, sandboxes or the JVM, these are written in C(++).

Java applets have security issues today. That's a situation where you are allowing random websites to execute arbitrary code on your computer. Flash has the same issues. So don't do that.

Don't confuse Java applets (and the lack of security thereof) with the JVM as a development platform. I'd bet on the security of a Java application over that of a C/C++ application any day.

> Java has horrible security bugs even today.

Example?

> Bugs can be found in code written in all languages.

And there's no difference between a bug every week and a bug every 10 years?

Here's a list of Java CVEs: https://www.cvedetails.com/vulnerability-list/vendor_id-93/p...

To be clear, I am not a security researcher, and I haven't verified the severity of these issues. But in 2016 alone there are 16 CVEs which is 4 per month.

Those are vulnerabilities in the JVM itself - and I'd bet a fair bit the majority will be in the C/C++ parts, not the Java parts.

> Bugs can be found in code written in all languages.

This is like saying "there's no point building bridges because sometimes they collapse".

Memory safety bugs are found far, far less often in memory-safe languages.

It may be tiresome, but it happens to be true. That something isn't done is not evidence than it cannot be done.

I think 'C'/C++ is the scapegoat for a massive cultural failing and have thought that for going on 25 years now.

Yeah, it's possible to write flawless code. The problem is that it doesn't happen in practice. You know, where people are actually relying on this code that "could be flawless but isn't" so they can run businesses, maintain privacy, etc.

I'd say C is more of a symptom and exacerbating factor of the cultural failing. C makes it easy to achieve performance and time-consuming to achieve correctness.

When the people funding the work (and this includes people donating their own time) can see performance issues but not correctness issues, guess which ones get fixed?

There is absolutely no doubt in that. But people also join the Marines, so....

I'll speak this heresy - I think "people donating their time" has a bunch of problems, not least of which losing the data/information that would be gained from pricing that labor.

printf("bull crap"); short programs can be secure.

Reply on news.ycombinator.com