C is scary....

[mirhagk]

There are many things in programming that I'd like to see dead like the ability to construct SQL queries from strings without escaping. It can WAY too easily introduce vulnerabilities in a system by a programmer who hasn't fully learned the concepts of what they are using. I have been reading some stuff and came across this.

http://bugsniffer.blogspot.ca/2007/11/infamous-software-failures.html

The 4th one on the list is what I'm most concerned with. Apparently this bug exists to this day, and it won't be removed from the standard library. And apparently it isn't the only thing in the C library that can destroy the world if used incorrectly.

http://en.wikipedia.org/wiki/Format_string_attack

Is there any other blaring vulnerabilities that could happen if someone doesn't pay full attention to the code their writing? It might be a good idea to collect all this stuff in one place for any programmer trying to get into C.

[Tony]

GCC will warn about both gets and format vulnerabilities (unless you go out of your way to not be able to determine format strings statically).

SQL strings are a problem only if the strings come from an untrusted source. Yes, it's a problem for new users; but a language needs to be able to insert those escaped arguments at some point... and _that_ step is unsafe. Otherwise it's turtles all the way down.

[DemonWasp]

If you don't want to examine every little thing, C and C++ are NOT the languages for you.

The C spec lists several cases of "undefined behaviour" and C++ adds some (as I recall). Undefined behaviour is famously quoted as "the compiler can do anything: if it makes flaming monkeys fly out of your nose, that's the spec". Most compilers try to do something reasonable, but undefined behaviour is as core a part of the language as variables are: you can't remove it without removing most of the reasons to use C or C++ in the first place.

Technically, dereferencing a null pointer is undefined behaviour. The most common behaviour is to crash, but technically it's within spec to wipe all mounted partitions, spam viruses to everyone your computer knows, post your bain details online, etc.

Buffer overflows are easy and common mistakes to make, especially in C (in C++, you shouldn't be allocating arrays for the most part). This applies to seasoned programmers too. There's a lot of methods in the C standard library that won't check bounds (mostly for speed's sake): strcat, strcmp, etc. Most of them have "bounded" versions: strncat, strncmp, etc, but that one-letter-difference is the difference between "no problem" and "massive security hole".

There are similar problems with double-free-ing allocated space: x = malloc(...); free x; free x; opens a whole can of worms: http://www.cprogramming.com/tutorial/secure.html

Then there's fun stuff in C++ like this:

code:

class C { ...etc... }; C c; // declares an instance, c, on the stack C* cp = &c; // declares a pointer to c, called cp C& cr = c; // declares a reference to c, called cr C c1; // uses no-arg constructor C c2(1); // uses one-int-arg constructor C c3(); // creates a new function, called c3, which takes no arguments and returns an instance of C. wut?

[wtd]

So, basically: sometimes people who don't really know what they're doing write code in C, therefore C is bad?

C isn't perfect, but once you start making it impossible to have buffer overflows and such, then you realize you're recreating Java, and well... that's already been done, and it wasn't much fun the first time.

[btiffin]

mirhagk;

And now that you see the holes, you have graduated to be in a position to fling code that might become part of the world's infrastructure.

I'm serious; having recognized the pitfalls, fling some C code and be aware of how different it looks, and feels and how it effects the craft.

And so's you know </sarcasm>, the infrastructure guys are pretty good at defensive programming. It's why we use their work, in the large. With enough catastrophic fail over time that things are constantly stressed to improve.

It'll all work out. Trudge forth, as I'll opine that all coders should understand C and the C Application Binary Interface (with all the cool libraries that thrive in GNU/Linux for instance). The C ABI is the glue for the internet, most languages, and on and on by Bob Loblaw, and I'll stop there. But do the C, it's good for you.

Cheers

[2goto1]

So true btiffin. Here is an interesting table of some of them - http://www.lextrait.com/Vincent/implementations.html

All of this infrastructure may not be perfect - but most of it runs rock solid and can be trusted to have significant uptime / reliability.

Craftspeople know their tools. The nice thing is that anything of significance / substance is written by a team, and that team has quality control processes, which allows neophytes to be able to contribute, and hopefully to develop their skills.

Is C the reason for the success of infrastructure software written with it? Perhaps to some extent, but perhaps process and smart, defensive-minded people are a larger reason for their success.

I wonder if hardware faults are more frequent than software infrastructure faults? I would guess yes.

[Insectoid]

Heh. I remember doing an assignment a couple of years ago with gets(). Dan told me not to do it, so now my code is full of fgets() to stdin. It's an easy problem to solve (don't use gets()) and you should encounter it fairly early in your education. There's a few standard C functions that don't validate the input.

[mirhagk]

Yes all these security problems are very easy to fix, but anything that must be 100% understood in order to be used scares me. I'm fine with it, because I like knowing what it's doing (I bought a book annotating the CLI .NET framework so I know exactly what my C# is doing), but after working in the field, and seeing how little understanding many of the programmers have of what they do, it scares me.

If you think that big system programmers always know what they are doing, I'd tell you to look again. Take the first link I mentioned for example. There are many things that can VERY easily slip by quality control.

Take for instance the instance where developer A is new, and makes a very innocent function using gets(). This code of course gets code reviewed as per standards. Now let's pretend for a second that this senior developer had a late night last night, and hasn't had his morning coffee. Now he gets given this large section of code to review. It's very easy for him/her to miss the fact that gets() is used instead of fgets(). Most systems don't do extensive security checks, and when they do, it's usually only for past vulnerabilities. It's impossible to test for every security flaw, even if they are all known. So this bug gets through the development, the code review and the final testing (since it's not really wrong, just a security flaw).

I think that's the number 1 argument for a system like .NET. Rather than allow developers to have full control, take away some of the menial trivial tasks that can easily go wrong, and get the computer to do it. I'd rather trust a system made a large corporation, in use by many people to not memory leak then I'd trust some random grad student who got into the field to make money. I thought this worked well for the C library as well, but I quickly realize that is NOT true.

[Tony]

mirhagk @ Wed Oct 03, 2012 11:08 am wrote:

It's very easy for him/her to miss the fact that gets() is used instead of fgets().

as I've already mentioned, this should be checked for via compiler / static-analysis, not a person.

[mirhagk]

Yes it should, however I don't believe every compiler does (like I don't think VS does). It just seems silly to me that they'd keep it in the language regardless. And there are other perfectly valid things that can go horribly wrong, like pointer arithmetic, passing pointers to the wrong object.

I'm not personally afraid of the power of C, I just am afraid of others having that power lol, especially after seeing what some programmers are (or rather aren't) capable of. There was a submarine that became dead in the water just because the program didn't check the input correctly (it had a division by 0). If an error that simple was deployed in a submarine, imagine what can be done with pointers *shudder*

[2goto1]

A programmer can cause disastrous results on any platform, but blaming the programming language is irresponsible. Education usually helps to remedy that particular issue.

An application built on the bestest platform in the whole wide world - .NET per mirhagk - can still have an issue that brings down an entire website, causes data loss, or performs an incorrect financial transaction, or allows SQL injection attacks, XSS, XSRF attacks, CSRF attacks, session id vulnerabilities, etc.

Those issues are higher level, but they are still issues that result from faulty source. As a higher level language, why does ASP.NET, ASP.NET MVC., etc. not automatically safeguard against these common type of issues and completely prevent developers from being able to circumvent them? Shouldn't a higher level language safeguard you from higher level issues that you will always run into?

The common lower level source-code issues are identified by virtually every compiler. Shall we blame the language / platform for everything that we claim it should be responsible for?

[mirhagk]

@2goto1 I don't think .NET is the best platform in the whole wide world lol, never said that. I said that idiot programmers are a valid argument to have a system that handles certain things like garbage collection automatically.

Having no memory errors in your code automatically is a pretty nice thing, even if that's all it added. Sure you could just make sure yourself, but at some point you'll probably forget.

Also just because the compiler can't check every possible problem you could ever had doesn't mean it shouldn't check at all. That's a very terrible argument, probably one of the worst I've ever heard. OS's check to make sure you don't access memory outside of your program space, is that also bad and shouldn't be done? More checks is not a bad thing, and if you can do them without sacrifice, why not?

I do believe that compilers should advance. If they keep adding more things the compiler checks, is that not a good thing? Looking at a specific example (SQL injection) would it be a bad thing if the compiler at least warned when non-constants were used in SQL statements? Yes it would be non-trivial for the compiler to check, but just because something is hard to do doesn't mean you shouldn't ever do it.

Here's a good counter-example:
Should cryptography methods not exist because we can rely on programmers to roll their own?
Of course not. You should never roll your own unless you are a cryptography doctorate that is creating a new cryptography library. There's just too many things that could go wrong, and it's better to rely on tried and true things to do it. Even if you could make it faster, you should let the computer do the work, not you. You can screw up easily, library functions have been tested.

[Insectoid]

Quote:

Rather than allow developers to have full control, take away some of the menial trivial tasks that can easily go wrong, and get the computer to do it. I'd rather trust a system made a large corporation, in use by many people to not memory leak then I'd trust some random grad student who got into the field to make money.

It is your responsibility to make sure the software you install is safe. You know how you always check to make sure there's no malware hidden away in your program? You should also be checking for bugs. Consider critical bugs accidental malware.

Quote:

Rather than allow developers to have full control, take away some of the menial trivial tasks that can easily go wrong

This part really, really bugs me. Take away the trivial tasks that can go wrong and give them a solution that if it goes wrong, they can't fix. I want more control, not less. By all means, give me those libraries, but don't you dare take away my fine control.

Quote:

Also just because the compiler can't check every possible problem you could ever had doesn't mean it shouldn't check at all. That's a very terrible argument, probably one of the worst I've ever heard.

Yeah, that's a pretty terrible argument all right. Too bad nobody ever actually said that.

Quote:

I said that idiot programmers are a valid argument to have a system that handles certain things like garbage collection automatically.

Quote:

Having no memory errors in your code automatically is a pretty nice thing, even if that's all it added

Agreed. But garbage collectors are slow. Even the fast ones have a significant impact on performance.

It's about using the right tool for the job.

[mirhagk]

Exactly. .NET is bad for certain application, but the safety it gives you ins't a bad thing.

Also 2goto1 did do try to argue by extending the compiler checking errors to an extreme and then said

Quote:

Shall we blame the language / platform for everything that we claim it should be responsible for?

Quote:

This part really, really bugs me. Take away the trivial tasks that can go wrong and give them a solution that if it goes wrong, they can't fix. I want more control, not less. By all means, give me those libraries, but don't you dare take away my fine control.

as long as a language is turing complete, it's equally expressive. I'm saying take away things like pointer arithmetic, so that the compiler can verify your code is memory safe (notice the compiler isn't doing anything to you program, just checking it). Of course you should still check it as well, but your safer from idiots who do stupid things with pointers. You don't need pointers, you can do everything you can do with pointers with other things (anon functions, reflection, and type safe references avoid the need for pointers). I don't think taking away things like I/O access are good for developers (I hate developing on mobile platforms btw) because it takes away your ability to do things, or makes you rely on potential buggy code. But if you take something away without relying on something else, that's fine. (Like ability to modify variables in haskell)

[2goto1]

Reflection isn't itself without many issues - stability, security, memory, etc. Anon functions can be similar as well....idiots can do stupid things with just about anything.