Computer Science Canada

C is scary....
Author:  mirhagk [ Sun Sep 30, 2012 9:04 pm ]
Post subject:  C is scary....
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.
Author:  Tony [ Sun Sep 30, 2012 9:51 pm ]
Post subject:  RE:C is scary....
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.
Author:  DemonWasp [ Mon Oct 01, 2012 1:05 am ]
Post subject:  RE:C is scary....
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?
Author:  wtd [ Wed Oct 03, 2012 12:08 am ]
Post subject:  RE:C is scary....
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.
Author:  btiffin [ Wed Oct 03, 2012 3:18 am ]
Post subject:  Re: C is scary....
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. Wink

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
Author:  2goto1 [ Wed Oct 03, 2012 7:29 am ]
Post subject:  RE:C is scary....
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.
Author:  Insectoid [ Wed Oct 03, 2012 9:57 am ]
Post subject:  RE:C is scary....
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.
Author:  mirhagk [ Wed Oct 03, 2012 11:08 am ]
Post subject:  RE:C is scary....
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.
Author:  Tony [ Wed Oct 03, 2012 11:22 am ]
Post subject:  Re: RE:C is scary....
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.
Author:  mirhagk [ Wed Oct 03, 2012 12:29 pm ]
Post subject:  RE:C is scary....
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*
Author:  2goto1 [ Wed Oct 03, 2012 12:30 pm ]
Post subject:  RE:C is scary....
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?
Author:  mirhagk [ Wed Oct 03, 2012 1:20 pm ]
Post subject:  RE:C is scary....
@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.
Author:  Insectoid [ Wed Oct 03, 2012 3:23 pm ]
Post subject:  RE:C is scary....
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.
Author:  mirhagk [ Wed Oct 03, 2012 3:45 pm ]
Post subject:  RE:C is scary....
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)
Author:  2goto1 [ Wed Oct 03, 2012 3:52 pm ]
Post subject:  RE:C is scary....
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.
Author:  mirhagk [ Wed Oct 03, 2012 5:01 pm ]
Post subject:  RE:C is scary....
Yes reflection is a dangerous tool, and anon functions could cause some wierd things in the hands of a stupid person. But at least you don't have the potential to overwrite memory used by something else, or worse your code.

If you have a problem with reflection, it's a library that you can easily do a CTRL+SHIFT+F to find all the occurrences where you use it, and make sure you're using it right. I also don't think reflection should be used except when it really is genuinely useful, or if you're making a compiler. I can only think of 1 scenario in my 4 years of C# code where reflection was remotely a good idea, and that was because of integration with SQL, if the other code was in C# as well it'd be easily avoided. Anon functions will usually mess things up locally, and leave a relatively fine stack trace.

Incorrect memory references can be created numerous ways, and the problems they create can pop-up in totally separate locations, with a totally different stack trace. You could be looking in the wrong place, or worse, not know where to look at all because it's impossible to reproduce the bug exactly.

And again 2goto1 just because there are others issues doesn't matter you can't try to solve one issue. It's mathematically impossible for compilers to completely check your code for everything (even with infinite time and space) but that doesn't mean you shouldn't check your code for anything with the compiler.
Author:  btiffin [ Sat Oct 06, 2012 9:20 am ]
Post subject:  Re: RE:C is scary....
2goto1 @ Wed Oct 03, 2012 3:52 pm wrote:
... idiots can do stupid things with just about anything.


I use COBOL to fill that need, http://opencobol.add1tocobol.com/

Wink

Cheers
Author:  mirhagk [ Sat Oct 06, 2012 7:54 pm ]
Post subject:  RE:C is scary....
What do you mean by you use COBOL to fill that need?
Author:  bl0ckeduser [ Sun Oct 07, 2012 9:48 am ]
Post subject:  Re: C is scary....
This quote seems to give some insight on why C can be scary:

Quote:

The philosophy of BCPL can be summarised by quoting from the book BCPL, the language and its compiler:
Quote:

The philosophy of BCPL is not one of the tyrant who thinks he knows best and lays down the law on what is and what is not allowed; rather, BCPL acts more as a servant offering his services to the best of his ability without complaint, even when confronted with apparent nonsense. The programmer is always assumed to know what he is doing and is not hemmed in by petty restrictions.

The design, and philosophy, of BCPL strongly influenced B, which in turn influenced C.

(Source: http://en.wikipedia.org/wiki/BCPL)
Author:  mirhagk [ Sun Oct 07, 2012 12:46 pm ]
Post subject:  RE:C is scary....
Exactly. I don't think we're ever gonna cure this industry of idiots, and I think the next best thing is to take away the power those idiots have. Those with true understanding can wield the power, for low level systems, compilers, drivers etc, but for the typical application, where morons abound, I think C may not be the best choice.

One nice thing about a higher level language developed using a VM style memory managed system, is that things the developers don't think of are automatically included. I hate in video games when the game crashes without so much as an error message. Ideally logs should be used, but failing that a generic error message is helpful. I understand some companies don't want clients seeing the stack trace, but that is amazingly useful for figuring out what is causing the game to crash (is it only when I open empty chests? Or when I go through this door, etc..). This is something many developers forget to do, and I understand not having a stack trace, but at least a semi-non-generic message would be amazing. ("The game failed while doing this. This has been logged, you can send the log to [email] for help"). Higher level languages do this kinda stuff by default so the code lazy/dumb programmers doesn't cause the rest of us pain.
Author:  btiffin [ Sun Oct 07, 2012 12:58 pm ]
Post subject:  Re: RE:C is scary....
mirhagk @ Sat Oct 06, 2012 7:54 pm wrote:
What do you mean by you use COBOL to fill that need?


COBOL is where I get to play idiot (yeah, play, it's all pretend) and do stupid things. I urge everyone to find a place to try stupid things, and try them.

Cheers
Author:  mirhagk [ Sun Oct 07, 2012 2:14 pm ]
Post subject:  RE:C is scary....
Oh lol, I get what you mean. I do like to play around with things (my recent favourite is .NET assembly, protect myself from doing things I don't understand all that well, while also being satisfyingly low level.

:


You can syndicate this boards posts using the file backend.php or view the topic map using sitemap.php.

Terms of Use | Privacy Policy