Slashdot Mirror
Secure Programming
viega writes "Matt Messier and I have just launched a secure programming web site. While this site does support our new book The Secure Programming Cookbook for C and C++ , it also serves as a thorough resource for developers. It has numerous links to articles and other topical resources, new recipes that demonstrate secure programming techniques a large glossary and the obligatory web log. We accept outside submissions, and will reward the best recipe submission each month-- O'Reilly will publish it on the O'Reilly Network web site and will give the author a free book. There's already a decent amount of new content, including recipes on avoiding malloc()/new-related integer overflows, watching out for security problems in API differences and issues when truncating data. There's also an RSS feed for the web log."
Once you have worked 50 hours a week in a corporate setting for 5 years as a developer (2 years) and a run-of-the-mill network/system/any-god-damn-thing-they-can-get-you -to administer(4 years, you will understand.
If you RTFA, or even just GATFA (glance at) you'll notice that the book has info on:
Random numbers
Input validation
Cryptography (e.g. ssh)
Buffer overruns are just one kind of problem you need to deal with when writing secure code. There are also DOS attacks and information theft. Even with Java, it can be quite challenging to ensure that data is properly encrypted and authenticated, and you still need to worry about permissions in the file system.
And let's not even dredge up the standard "why can't you just rewrite 100s of 1000s of lines of working C++ code in Java?" inanity.
Might Java or C# have their own security issues, where if the right set of things occur bad things could happen?
I'd rather use a language which doesn't give a false sense of security, a language which everyone obviously (well, we hope they do, but, true, not always the case) knows you have to do checks and specify how much space you really have (and so forth).
The really is no excuse to use a language like Java or C# to do your checking when you can do it yourself. Except of course, laziness >:P
The really is no excuse to use a language like Java or C# to do your checking when you can do it yourself.
That is the most ridiculous argument ever. It is tantamount to embracing only the most basic building blocks of anything and claiming that any automation or pre-made combination of those blocks as wrong.
No, it is you who is wrong. Why do you use a computer instead of an abacus? Why do you use paper when you could carve notes into stone? Things progress, things get better, and things that once were boilerplate (like manual safety checking) are taken care of so you don't have to do any of the boilerplate stuff anymore.
Embrace the better technology. Don't cling to the past or you will be left behind.
Now that you've got off your high pony, the problem is not necessarily the tools. As the site points out, buffer overflows can be avoided in C/C++. The whole point of the site is to try and improve coding practices.
And don't think that just because Microsoft is switching to managed types that they are all of a sudden going to fix bad coding practices. Sure it may reduce the effect of bad coding but it won't single handedly catapult Microsoft into security heaven.
Go back in your cave troll.
"She's a West Texas girl, just like me" - G.W Bush Iraqis
Blaming colleges is a complete copout - if colleges aren't teaching the proper skills, then employers should be rejecting applicants with inadequate skills.
The fact is, most companies couldn't give half a shit about security on a day-to-day basis, and therefore don't really care if people fresh out of college have a clue about secure programming, or even security in general.
The goal of college, in the context of our current society, is to prepare students to get a job - if employers aren't demanding it, then people aren't going to expect it to be part of a college curriculum.
Don't get me wrong, I fully agree it should be a core part of computer education right from the start, but until the technology industry recognizes it as a day-to-day need (other than the 2 weeks after you've been hacked), it won't be considered an important part of the educational process.
It's more than just speed issues. Interpreted languages have better runtime checking and thus can avoid things like buffer overruns, yes. That's great for a lot of things, don't get me wrong. For backend programs, Java is an absolutely brilliant language, as it encourages some much better object-oriented design philosophies. Even Objective C handles some runtime checking far better than C or C++, though as it is a set of extensions to C it suffers from the same weaknesses in C code.
:) Last I checked, the original Java Virtual Machine was written in C...after all, you can't run Java bytecode without something to interpret it. Similarly, I bet you most Just-in-Time Java compiler/interpreters are also written in C or C++. Even the programs which take Java code and turn it into a binary executable likely are linking it against a library which was written in C or C++.
:)
/do/ solve some problems which traditional lower-level languages are more vulnerable too -- modern interpreted are not a panacea for all programming ills. They aren't suitable for all types of programming, and even for the ones they are well-suited for, they don't automatically solve all security issues.
;)
But what is the JVM written in? I guarantee you it isn't Java.
Similarly, at my old job, I had to write low-level drivers for PCI hardware we were developing. Did I get to write these drivers in Java or C#? Of course not... you can't write low-level hardware calls such as Windows VXD files in an interpreted language; it'd really kill the performance of a system.
Just for a moment try to imagine someone writing, say, a new video driver for the Linux kernel in Python, or rewriting XFree86 in Java.
Ow.
Moreover, while Java makes it a great deal harder to, say, create a remote root exploit through a buffer overrun, it does not automatically fix problems of, say, cryptographic strength. Creating an encryption algorithm for some vital data which can be easily broken is as much a security hole and a flaw as a buffer overrun.
So while you're correct in some places -- Java and Python and C# and other interpreted languages that can do more stringent runtime checking of things really
In general, the lower-level the language, the more easily you can mess it up; ASM is even easier to fry things in than C or C++. It becomes a tradeoff, with the lower-level languages giving you progressively greater efficiency and the ability to access things 'down on the metal', with higher level languages -- while slower and more abstracted -- able to shield you from more mistakes, and more portable between situations.
Each has their place. I wouldn't want to write a web-client that ran database queries in ASM, but Java works great. Conversely, I wouldn't want to write a driver for an AGP graphics card in Python, but ASM or C works pretty well right there.
--Rachel
By hiding the details behind a curtain, I think it is more likely problems will just get ignored
So you, um, write software in machine code?
Higher level languages exist because it is tedious and error prone to need to code every last bit (pun intended) of instructon required by the CPU to do any work. The higher level the language, the more insulated you are from the machine code.
Assembler required you to know registers, C and C++ require you to free memory resouces. Java requires you to open/close files. SQL requires you to know table and column names. Each step up requires less and less knowledge of the underlying system. And each step up is safer overall.
But ANY language can be written so it is insecure and/or buggy.
We will reach a day when the Star Trek type of information retrieval and manipulation is done. We are not there yet.
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
How about a graduate who can tell me the difference between a development environment and a production environment?
Also:
- the importance of taking the time to do something right the first time as much as possible, instead of always the tiresome updates and tweaks.
- what version control software is and how it is essential to team development (hell, you'd be surprised how many senior programmers don't know about it or use it).
- how to take ownership of a task and see it through, not blaming someone else.
- how to keep busy when the current task is blocked. Find another task, stay busy.
- how to use your own head, and not ask questions about every single thing. If I have to give guidance on what colour your label should be, I might as well do the task myself.
- common design patterns and practical applications of them.
- performance optimization techniques, and why developing everything on a quad Xeon with gigabit ethernet is not always a good idea.
- how calling in sick every week is not acceptable in the real world (not at most places, anyway).
- how good organization techniques can save you a lot of time and keep you on target.
- error handling code should be hilighted more. Books always seem to omit error handling, and that's what students learn from. That leads to really buggy code.
However, C and C++ are a fairly small part of the market these days, too. All the market data I've seen recently suggests that no more than 1/3 of commercial development is in one of these languages. It's probably less.
And, there are plenty of security problems that apply to all languages, such as problems in authentication systems that provide the attacker some kind of leverage (e.g., practical guessing attacks), other misuse of cryptography (e.g., misapplying SSL) and other generic input validation problems (e.g., SQL injection). These things come up in all languages, and are things people frequently get wrong.
Tune in to Bugtraq some time to see a never-ending stream of web-app vulnerabilities. Most of these applications are not written in C.
Moral of the story: stupid programmers will be stupid in whatever language you give them.
Moving to interepreted languages mean that any dodgy user-supplied input will be detected at runtime, and will most likely result in some sort of a traceback (but no exploitable overflow).
This however does not eliminate the remaining classes of vulnerabilities, relating to default configurations (username/passwords), poor encryption mechanisms, Denial of Service attacks (minimised due to most popular interpreted languages having their own garbage collection), and more.
We need more developers to be putting on their black-hats, and looking at their code and wondering "what if I tried this? Could I break this code?".
Man watching 6 MSCE's around a sun box, looks alot like the opening scene's of 2001:space odyssey...
ah, you think it's funny - but it's true! the more a program does, the greater its potential for security flaws. thus, frymaster's first rule of secure programming: "your program shall do no more than what is absolutely required by the spec-n-rec[1]".
1. you got a spec-n-rec from the client? lucky you!
2 1337 4 u!
The problem is not the language, it's our style of programming.
The whole reason that security issues have proliferated is our stubborn insistence on allowing for variable input. If all input and systems had hard wired capacities, then, there could be no denial of service attacks as program behavior would be bounded.
Even C# and Java have DOS issues becuase of their unbounded nature. A program that reads an input stream and stuffs a link lists will be just as supsectible to denial of service attacks as any others.
Some of us remember gravitating over to C from the old Pascal and FORTRAN and BASIC because of C's penchant for creating dynamic data structures. AS I look back on that era, I wonder if we didn't make something of a mistake.
I wonder if we might borrow some of the practices from that ancient era, and use dynamic allocation as the exception, rather than rule. Programs should have fixed numbers of objects. Programs should have fixed input sizes and maximum capacities. String fields should always have a maximum, fixed, size.
I should note that if we do have less variable length allocations, then, we less likely need programming languages that make variable length easy. A more conservative, almost retro programming technique could make for faster, more secure programming.
This is my sig.
20+ years ago I used an operating system that was written in Pascal. There have been commercial operating systems written in FORTRAN, PL/I, LISP and other languages.
Mea navis aericumbens anguillis abundat
Why is the goal of college to prepare students for job? That sounds more like a trade school. College should be for the pursuit of academics.
Sock puppets stole my sig.
Are you somehow recommending a kernel be written in something else than C?
Personally I never understood why C was so popular. In particular I never understood why people thought of C as a powerful language. I don't know about the parent post, but for me I do recommend writing a kernel with something else. A mix of Ada and assembly would be my choice (yes, I know I'll get flamed for saying "Ada").
but you have to realize that unless the underlying infrastructure is built (on some low level language), you can't have high level languages.
I'm not sure what you mean by this (you don't mean you can only write a compiler from assembly, right?) but what's the difference between C and another high level language? (except for the fact it's easier to write a C compiler than an Ada95 compiler)
buffer overflow isn't the only security hole in the world
No but they are really "popular". Also don't forget about simple bugs that could be found at compile time by using a more powerful language than C.
Yes, I know you can have good programming practice in C. You can have good programming in assembly too. Unfortunately a programming language comes not only with syntax rules but also with a "culture"... and let's be honnest, C "culture" is not about good programming pratice.
If it has held up so far I am pretty sure it's unbreakable.
Horrible, terrible, abysmal way to look at things. The fact that no one has broken it yet hardly means it's impossible. Before the openbsd remote root hole, were you also thinking that it was impossible for openbsd to be broken into?
While I agree with point 2, I can only say that point 1 is at best misguided nonsense and at worst a troll. If an attacker is able to overrun a buffer by a few bytes, then they are likely able to over-run by more than the 1K for which you've allowed. This technique is likely to give a false sense of confidence in an implementation as well as cause bloat - hence negating at least some of the advantages of the costly decision to implement at a low level permitting pointer arithmetic. There are much better ways to tackle such problems. In many cases C/C++ programmers should take a leaf from Java programmers and avoid pointer arithmetic in mainline code. It is trivial to code an ADT for arrays/strings in C, and C++ programmers should really consider STL containers. Only extremely low level code ever need directly manipulate pointers - and the cost of interacting at this level should be a moral obligation to show, using appropriate techniques such as pre-condition/post-condition inductive proofs, that buffer overruns are not possible.
Oh, your very own web page cites 5 bugs per 1000 LOC for C/C++, and 1 for Java. That's a factor of 5!
The biggest problem that makes C/C++ less secure than other languages is the fact that errors are not contained locally. Every single line of C/C++ in your project can break any other line of your code, violating all security assumptions.
Sure, you have STL. And what does that buy you when there is a buffer overflow in a third party library you're using?
Right, nothing.
Besides, readable and maintainable code is a security feature in itself, which C/C++ just doesn't have. It lacks a lot of abstraction facilities.
Not seeing C/C++ as a source of many of our security problems is a state of denial.
Unfortunately, in a real world situation (as opposed to the dreams of someone walled in their own ivory tower), a program that crashes regularly is just short of useless. A program which malfunctions in the middle of writing data -- because half the logic got shortcircuited by a RuntimeException that cut straight through the last ditch "catch (Throwable all)" block -- is worse than useless.
For a geek, crashing early might be good coding practice. For a user, it's one e-commerce site they'll never visit again. (Yes, in a recent study, the main criticisms were stuff like the web site having a brain fart AFTER it swallowed the credit card number, leaving the user with no clue as to whether the order was processed or not.) Congrats, your site wasn't hacked, but the company is losing money hand over fist anyway.
Don't get me wrong, I'm not against Java, and I _do_ understand its advantages.
_But_ if using Java is your _only_ security, then you're doing it awfully wrong.
In Java, like in any other language, you _still_ have to do your own checks, and make some effort that the program will still work when confronted with malformed input. Especially when such input is not even a hacking attempt, but some hapless user typing "Jan 23, 74" instead of "23/01/1974" as you would like him to. Or he's included spaces in the credit card number (which causes Long.parseLong() to throw an exception.) Or whatever.
You do _not_ want the program to crash early and safe on the user, you want it to display a clear error message, and give the user plenty of clue as to how to correct the problem. And a chance to do so.
You also have to account for such user deviations as "what if he opens a link in a separate page, so now we have TWO pages sharing the same session id. And the user is doing different things in each." That's absolutely _deadly_ for brain-dead sites which store everything in the session. Just because Java's servlet interface makes it easy to store stuff in the session, doesn't mean it's also _safe_ to do so.
I've seen at least one e-commerce site which ended with products flagged "new user" and users flagged as "sold", because they relied on the session in the wrong way. Yes, noone took over their site, but the cost of that screw-up was very high nevertheless.
Briefly: again, just programming in Java doesn't automatically make your programs bullet-proof. There is no auto-magic substitute for good coding and design.
A polar bear is a cartesian bear after a coordinate transform.
To start, the parent comment should be modded back up. The parent poster isn't a troll; (s)he just has strong opinions.
Onto the post ...
Geez, how hard can this be? C and C++ are the only two major languages
on the market nowadays which allow array overflows, pointer dereferencing
into code, free creation of unsafe code, and other fun stupidities. As such,
they are easily the WORST LANGUAGES on the market for secure
programming.
This is a common programming fallacy. It's not the programming language that makes it easier to create a secure program; it's the programmer with a thorough understanding of security that makes the (infinitely approaching) secure program.
Sure, people will say oh, yeah, but you can be insecure in any
language. These people should have their CS degrees revoked.
They're right (and if you had your way, I'd have my piddly degree revoked in a few seconds :P)!
There are dozens of popular programs written in C/C++ in which security holes haven't been found, programs that are written carefully and thoroughly debugged by programmers that understand security. Programming languages like Python, Ruby, LISP, [... ad nauseum] make it easier to avoid common pitfalls (i.e. buffer overflows), but there are plenty of security holes that can be introduced into programs written in those languages.
Don't get me wrong. I'm a Python zealot, I like Ruby, and I think Modula-3 has (had?) the potential to be one of the best systems programming languages available (if not for the lack of tools associated with Modula-3). However, that doesn't change the fact that there are great C/C++ programmers out there that will write less buggy code in their lifetimes than many Python/Java/Ruby/[insert your favorite language of convenience] programmers that don't know the first thing about computer security.
I could apply your logic to language interpreters/compilers for some of the languages you mentioned (i.e. Java, Python, Ruby, etc.). Is the Python interpreter less secure than a Python program because the interpreter was written in C? If the interpreter is insecure, then what does that say about Python programs when they're being interpreted by the interpreter? A program is secure if it's behavior is predictable, given a certain set of actions.
Devin
Oh, we have some pseudo-scientific measurements in this regard. Gwydion Dylan comes with a Dylan-to-C-translator. Average performance loss when compared wo writing directly in C is between 10 and 30%, and that's mainly due to garbage collection overhead and some register lossage (we have to pass an extra stack pointer to the generated C functions).
Bounds checking is nearly free on modern CPUs. Branch prediction and superscalar execution buys us that. Measurements show the overhead to be less than 0.1%, for sieve of Erathostenes, which does array access all of the time.
And OCaml shows that you can even beat C in terms of performance once you can do global optimizations like deciding which registers to save and which not on a per-function basis.
Last, but not least, having a real high-level language available means it is easier to implement funky algorithms that reduce algorithmic complexity. It's most often the brain and not the muscle that makes software run fast.
Seriously, let's say I write an application to manage a little local computer store, why should I use C and potentially ship a lot of memory-related bugs with my app when I can use something like Lisp or Python or O'Caml which all are stable, complete and powerful languages in which that task would be easy and would result in a better application?
So you don't want to have memory allocation and pointer issues. Fine. That does not make your programs secure which is the end goal of secure programming in ____.
You still have issues of data/input validation, principle of least priviledges, secure (confidential and/or authenticated and robust) communications, sanitizing the enviornment, dropping unnecessary priviledges (and designing the program so it can drop priviledges early on before user/network client interaction), race conditions, error handling, and many many other tedious yet important issues.