Flaws Result From Low-Level Languages

I found this article on SecurityFocus regarding the never-ending flow of security advisories and vulnerability alerts that come out. The author suggests that many things are written in C / C++ ostensibly for speed- but that they need not be written in low-level languages. He proposes that higher level languages like Perl of Java can do the trick without much of a performance hit and more importantly without so much access to core system processes.

Quote:

---

There is also a macho streak in programmers: a tendency to believe that one's own code is well-written, and a corresponding belief that real coders, like fighter pilots, work as close as possible to the bare metal: Real programmers manipulate the system at the lowest possible level, for the maximum possible effect.

---

He freely admits that the higher-level languages have their own issues and security vulnerabilities and that its possible to use tools to help validate code against vulnerabilities in the lower-level languages.

Quote:

---

It would be nice if we could expect that our programmers would act more like airline pilots than fighter pilots: that they acknowledge, and accept, the responsibility that they take for the well-being of others. Until they take this step, I doubt that the quality and security of the code that we all rely on will improve.

MORE

---

I am a mere programming dabbler- a little C++, a little VB, VC, etc. - but by no means a guru in any of them. I am curious if other programmers feel that the programming community at large is not doing enough to write secure code and validate it before pushing it out the door.

Microsoft takes a constant stream of heat over their security flaws- but it seems that no vendor has such a great track record. Can the programming community improve this situation or is it just the way it will always be?

Quote:

---

I am curious if other programmers feel that the programming community at large is not doing enough to write secure code and validate it before pushing it out the door.

---

I think one of the hardest things to do is code for every tangible possibility. One of the most difficult and yet most frequent issues I ran into when coding was user error. Even with our software testers (thank god they were across the country from us), end users still found a way to break what seemed to be perfectly coded and tested programs. Now add users who thrive on reverse engineering programs and *poof*, you have one pissed off boss knocking on your door, wondering why he hired you in the first place.
So to answer your question, I think 'some' programmers out there may not put a valiant effort into writing and testing secure code. For the majority, I would say, since their well being and paychecks rely on the fact that they can code...I'm sure they are trying their best.

Good comments all around...

I have a penchant for developing 'proof-of-concept' buffer overflows for apps written for UNIX, Linux, VMS, and Windows. The lowest common denominator in these is not allocating enough space for data. In my observation, some of the most well written and robust programs that are vulnerable to buffer overflow are amoung the most dangerous, because they keep running instead of Seg Faulting and dying off. This is not always the case as I am certain you already know, but it does point to what we already know about daemons being more dangerous than regular user apps if exploited, especially if run as root (can I get a duh? :) ).

At least as far as buffer overruns/overflows are concerned anyway, and with many other common security issues in coding, it is usually best to explicitly check and handle situations each and every place that allocating and freeing memory are taking place. As ShagDevil pointed out though, users will try to do the most amazingly stupid or just plain abusive things to your apps, and the safe bet is to count on this during development.

There are some really serious problems even in so-called "high-level" languages. You can't get much higher than SQL (a so-called fourth generation language), right? Yet the majority of problems in web applications come from interactions between another language and SQL

Of course this is a special case of the more general "string parsed" vulnerability, i.e.

Routine A takes untrusted input from user and passes it to routine B. Routine B, rather than using the input unmodified, does some parsing on the input for special characters, and takes some different actions based on the content. In some cases the programmer of routine A is unaware of this parsing, or takes insufficient precautions to prevent errors.

A low-level example of this is C printf format string vulnerabilities. But many of the examples exist in higher level languages too.

So even in the high-level languages, VB & Java, where strings are dynamically allocated the correct size, you cannot free memory explicitly (hence can't get it wrong), there are no pointers to overwrite (programmer-visible ones anyway), there are still a lot of problems.

"Low level" problems:
- Buffer overrun
- "Double free"
- handling pointers incorrectly
- etc

"High level" problems
- Parsing
- For example SQL injection, HTML cross-site scripting
- printf format strings

The vast majority of these problems come from bad interfaces. Look at

In perl, "open" - the string is parsed for special characters like > and |
In SQL, unless you use parameterised queries, you have to mix data and commands!
HTML - often composed by string manipulation, there are lots of ways of injecting commands in it

And also

PHP - just plain bad design, having global variables determined by user input ("register_globals") - that's asking for trouble.

slarty just a note php's register_globals is off by default from like 4.2.0 iirc
but php does produce alot of shitty coded sites but thats not phps fault ;)
rioter

Like rioter said already, it's not the programming language but the programmer him(/her)self that makes the flaws. A code doesn't have to have flaws as long as the human makes no mistakes (and it always does). The compilers etc. of the high level languages are written with a low language. Wether a low language has more access to core functions or whatever doesn't mather and isn't even 100% true. It should be able to for instance manually edit the memory like you have to do in assembler, for the compiler will change it all in machinecode eventually.

I think manyprogrammers can do better, just to learn some more before writing things. Many many people just buy a php book... ow now I can write php code... if(!$crash) {blablalba and they forget all kinds of security measures like filtering out //.\.\\./\.//.\/.\/\/ and the like in for instance mailforms or anything. Many people aren't just experienced anough to write secure code.

register_globals may be off by default, but I run several sites, and there are quite a lot of applications out there that require it to be on (my sites have a mixture; some run with it off, others on)

Clearly it is turned off wherever possible, but I still stand by my opinion that having globals registered in this manner was a bad idea in the first place, and essentially a design fault.

I'd hardly call C/C++ low-level in the first place.

but as was pointed out on slashdot by many people, quite obviously this guy has a beast of a computer and unlimited funds if he wants to have application level stuff like e-mail clients written in Perl and Java