Is it the language or is it the programmer?

[GnuVince]

http://www.securityfocus.com/columnists/150

The author here argues that languages like C and C++ are a direct cause of all the security problems in software. Most of the anonymous commenters flame saying "It's not the language, it's the programmer". What do you guys think?

For me, I think both are the problem, but that we can help reduce the influence of one: languages. An application written in C/C++ is (from what I hear, because I truly have no experience) longer to write and is more prone to bugs and insecurities. With the processing power we now have, and high-level languages (such as Ada, O'Caml, some Lisp implementations, or even interpreted lanugages such as Python, etc.) with compilers that can produce code almost as efficient as C, should user applications (IRC clients, email clients, etc.) be written in higher level languages? I think so. For instance, doing input in O'Caml is easier and safer IMO:


try
print_string "Enter your name: "; flush stdout;
let name = read_line () in
print_string "Enter your age: "; flush stdout;
let age = read_int () in
if age < 18 then
print_endline "You are not an adult"
else
print_endline "You are an adult, let's go have a Boddingtons!"
with
| Failure "int_of_string" ->
print_endline "You did not enter an integer"


Thanks to the strict typing in O'Caml, and to the exception mecanism, it was quite easy to catch errors. I haven't tested this code, so I can't confirm that it will compile, but most of the time, if it compiles, it works and works right. Also, I don't fear buffer overflows, because the memory will be automatically allocated by the garbage collector. I'm not sure how to write the following code in C or C++, but I'm sure that to have an equally safe version, you need to write more lines and do some maollc()'s.

I say that most user applications should be written in high-level, safe languages.

[inkedmn]

/me wonders if the above post was created after hearing that he's now learning C++ :)

[GnuVince]

Originally posted by inkedmn
/me wonders if the above post was created after hearing that he's now learning C++ :)

No.

[file13]

i agree that if not for C/C++ we wouldn't have as many secuirty holes simply because you can't write public enemy #1 (buffer overflows) in a language like Ada. you would still have other security holes--like race issues and OS depenedent mistakes--but these are far less common then buffer overruns.

as for the argument, "it's the programmers fault", that's a lame excuse. of course it is! but technology is here to make our lives easier. if a programming language can't help you minimize your mistakes then IMHO there's something wrong with it. even if you're an expert C hacker you're still human and you will still **** up. it's just that in C geneerally a tiny mistake can be made into a mountain of work. the problem as i see it is hackers LIKE the challenge and love the danger! native code compilers (esp the C compilers of today) produce fast code if written with the right algorithms and it's a "small language" (in relation to say Java). but more importantly it DOSEN'T tell you when you make mistakes. hackers don't like to be told we're wrong. this i think is the real problem and it's a hacker problem. hackers like C because it let's them write in high-level portable asm. asm is fun because it's challenging and there's something fascinating about writing something that the machine can understand (so what if it's short hand and not binary!). however it's not practical. C makes it practical by making it portable, but still let's them express their hacker desire to challenge themselves by writing as close to the machine as possible.

when i first used Ada it pissed me off that it wanted everything explicit. but once i got used to it i realized i spent WAY less time debugging and more time drinking beer. :beer: the difference is, your average hacker LIKES to sit in front of the debugger....

[sicarius]

I would say that it is around 50/50 (do not reduce to 1). The language can only be blamed in so far as it allows one to write a particular program insecurely. It is ultimately up to the programmer to decide how and what to write.
One thing that has remained constant in computer programming, and computers in general, is that a computer does exactly what it is told to do. If a program crashes people get pissed...I say hey, that is what somebody told it to do, don't hate the computer for it.
The fact that libraries are such an important part of programming is also a big security concern. I can write what I and others believe to be completly secure code, but if some library routine at whatever level is compromised, then my code might be compromised too.
The problem of insecure library routines is compounded even more if the insecurity lies in some core library that is part of the operating system.

I say don't blame the language, it is just a pencil and has no bearing on what is drawn with it. I can pick up a pencil and write an encrypted message, and I can pick up that same pencil and write an unecrypted message. Which is more secure? Well at first you might say the encrypted message. What, however, happens when the cipher is cracked? Perhaps my plaintext message is never found by a "bad guy" and was the safer way after all, or perhaps I used a one time pad and only God knows what I wrote.

I appologize for the book...but my point is that human error is always the cause of computer malfunction/insecurity. You can go back so far to say that the computer wasn't designed right and blame Von Neuman if it makes you happy. Heck, maybe Church and Turing are to blame....but it sure isn't my powerbook.

[GnuVince]

sicarius: yes the programmer is often the culprit, but using languages such as O'Caml, Lisp, etc. helps not have certain types of bugs, including the crackers' favourite: buffer overflows.

[sicarius]

I agree with you GnuVince. Certain languages definitely provide more secure constructs (or even paradigms i suppose), but in a way it comes down to realism. While you can certainly implement anything in O'Caml that you can in C/C++ I don't think we'll see a big shift away from C/C++ for quite a while. All i'm trying to say I guess is that if i were looking for a job in the software industry I would still prefer to learn C/C++ than O'Caml for the time being.

Ontop of all that...crackers crack. If it weren't buffer overflows it'd be something else. Not an excuse at all, just part of reality.

[GnuVince]

Originally posted by sicarius
I agree with you GnuVince. Certain languages definitely provide more secure constructs (or even paradigms i suppose), but in a way it comes down to realism. While you can certainly implement anything in O'Caml that you can in C/C++ I don't think we'll see a big shift away from C/C++ for quite a while. All i'm trying to say I guess is that if i were looking for a job in the software industry I would still prefer to learn C/C++ than O'Caml for the time being.


No, people won't move to other safer languages because they fall in at least one of these categories

a) Too slow: interpreted languages or languages which compile to inefficient code (Java, Python, Ruby, Perl fall in this category)
b) Too big: the resulting binary (or distribution) is too big. Memory usage is also a big concern
c) Not enough libraries: I think there's a lib for every computer problem for C and C++. Languages like Ada, O'Caml, Lisp lack libraries which make them less attractive
d) Community: C and C++ have millions of coders. O'Caml has some thousands. Getting books, help, tutorial, jobs in C/C++ is an order magnitude easier
e) Different paradigm: a lot of safe languages are functional languages which is a different paradigm than C and C++. People get turned of by this and say it's only good for academic stuff.
f) Feel: C and C++ feel like you are doing more. If the 500-line program you made in C can be done in 100 lines of Python, you think that the C program is better for some reason.


Ontop of all that...crackers crack. If it weren't buffer overflows it'd be something else. Not an excuse at all, just part of reality.

Yeah, I agree, but buffer overflows seem to be so easy to crack. I mean, there's this tutorial by Aleph1 on phrack.org that explains in details how they work. Removing this problem would mean that people would need to study other stuff (which we'll then fix). I mean, right now it's like the Iraq Information Minister: "There are no security problems in C, we are chasing them in the desert!"

[sicarius]

...silly infidels. their coding uses a method...i call it silly...stupid.

I agree with the issues you raised above. Of course even if you say you have a 500 line C program that does the same thing as a 100 line O'Caml program, you still have to consider that somewhere along the line the same basic machine instructions are being used, which as you stated above, means about the same if not increased binary size.

[stuka]

I say it's the programmer. Even C has simple, standard library routines that are TRIVIAL to use (snprintf, for example) that can prevent buffer overflows. The difference in code length (one function argument) is tiny, and the performance difference bound to be so trivial I wouldn't bother measuring it. There's really no excuse for buffer overflows from anyone who knows ANYTHING about their language of choice (except perhaps asm, but who in their right mind codes that? )

[jemfinch]

It's language. Even good programmers make mistakes.

Jeremy

[sicarius]

Like I said early it can't be 100% either one.


Absurd example but I can write insecure code in any language. This may just be semantics here but what if I write some piece of code that accepts a user name and password for some...i don't know, for some generic system. Well my code goes and changes that user's password to the return character.

I know that isn't a buffer overflow, and I know it has nothing to do with type safety, etc. But isn't that insecure code? I can do that in whatever language I want. The general point I am trying to make here is: Stupid programmer = insecure code, regardless of language. Computers only do what you tell them to do. Whether you tell them to allow a buffer overflow, or tell them to e-mail your password to 1,000 random people.

So it can't just be the language.

[jemfinch]

Originally posted by sicarius
Stupid programmer = insecure code, regardless of language.

The problem comes in when Good programmer == insecure code. That's a language problem, and it happens all the time in languages like C, C++, and to a somewhat lesser extent, Perl. It happens far less often in languages like ML, Lisp, and Python.

Jeremy