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.
Lesson #1: All Java programs are automatically secure.
:)
See, that's why I keep coming to Slashdot. You learn something new every day.
You want the truthiness? You can't handle the truthiness!
It's a good idea to have resources that are committed to security. Although some will claim that languages such as Java or C# prevent security issues, this is simply not true - there are many avenues to building security weaknesses... and those that think they're safe merely by using a particular programming language are in for a nasty surprise.
Of course, a web site and a few books won't prevent security issues - but the more it gets the word out about good programming practices, the better!
---
Herb Chambers - where my nightmare came true!
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
I won't given the color scheme.
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.
Or for a quick and free guide, you can download the secure programming faq from one of the oldest websites on the internet-
Securing Programming FAQ
--
Analytic & algebraic topology of locally Euclidean meterization of infinitely differentiable Riemmanian manifold
These degrees are handed out like toilet paper these days.
Let's teach future American programmers proper security before they graduate and start writing professional software.
There's no excuse for the fact that in order to write good, clean, secure code, our youngsters have to visit websites like secureprogramming.com in order to just get by.
What a disgrace.
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
Are you somehow recommending a kernel be written in something else than C??? Sure, not all systems software is kernel mode C, but you have to realize that unless the underlying infrastructure is built (on some low level language), you can't have high level languages... in other words, the bottom line is Assembly. You have to build your way to it.
Now that said, the buffer overflow isn't the only security hole in the world, in fact more security holes come from very very high level, very abstract programming fallacies... such as for example the cookie exploit (it's a logical bug) that Hotmail had a while back.
All this being said, I feel like a dirty karma whore right now (feeling the slimey breath of modders down my neck), so I'll say it right out: I'M PRO MICROSOFT.
<runs for cover>
use a language that was specifically designed with security in mind
like say, Ada
oh yeah, let the negative moderation begin
because programmer can't stand being held by the hand
too big ego
They happen because A) most code is written in C or C++, and B) everyone makes mistakes (even the finest open source developers overlook simple buffer overflows).
That's not true. qmail and djbdns do not have security holes. They were written using secure coding techniques that make them immune to things like buffer overflows. You can't "overlook" a buffer overflow with stralloc.
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
No buffer overflows
Without throwing an exception and crashing the program.
No dereferencing of null pointers
Without crashing the program (java.lang.NullPointerException).
No object creation failures (all "new"s succeed)
Without crashing the program -- usually as spectacuarly as a C program since an out-of-memory condition will make Bad Things happen with the VM or JIT as well.
Sounds like a great candidate for writing an OS kernel in. Microsoft are you listening?
The Secure Programming Cookbook for C and C++, Chapter 1: Find an Alternative to C and C++.
Seriously!
Lesson #2: No matter how obvious it is that you're trying to be funny, someone will mistake your comment for totally serious and sincere (or, in this case, totally sincere in sarcasm). Which leads to...
Lesson #3: Don't try and be funny. You'll just end up having to explain it, and--as the Heisenberg Principle attests--an explained joke ceases to be funny.
Seeing how the parent didn't specify which security issues were fixed by switching from C/C++ to Java, and the website is devoted to "secure programming" without regard for language, the parent gives the impression that switching to Java automatically renders an application completely secure.
Despite Java's safer memory usage, an application is still open to a wide variety of attacks. Such grandiose security claims about managed languages are worthless (except for the schmucks trying to get a contract to rewrite a critical application in Java or C#).
See? See how not-funny you made me?
You want the truthiness? You can't handle the truthiness!
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
"Now I'm just a lowly IT worker, managing web servers and crawling under desks"
Crawling under desks? I know admin'ing IIS servers is bad enough because of the security problems, but to have to blow your boss to keep your job?
Talk about getting fucked in both ends!
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.
This is just silly - existing commercial lisps compile to machine code, same as c, or fortran, or ada, etc. Current lisp implementations run on stock hardware, on all the major platforms - Windows (XP,ME, NT, 9x, Dos), Linux (ix86, sparc, ppc), Mac OS X (and Classic), and various Unices.
OS kernels are not written in lisp because Unix was written in C, so everyone mistakenly believed that C was *the* language for OS kernel implementation. However, this is simply not so. Any language compiler that can generate machine code can be used to write an OS kernel.
I recommend Python.
Open source, expressive (very short code can achieve a lot), readable (very short expressive code is easily groked -- fewer bugs), no direct pointer manipulation (safe -- fewer bugs), integrates nicely with other languages, runs on a variety of platforms, very easy to learn.
1. Create your own malloc/free new/delete heap. This heap should always have blocks of 0's interspersed throughout and a 1K walled block of 0's at the end of the heap. Any programming errors may result in garbage, but it won't result in injected code vulnerabilities.
2. No direct DB access technology on your web service front ends. If your web UI code has SQL in it, you're doing something wrong. Your Web GUI should access an intermediate layer, instead. UI is notoriously easy to compromise, and the best way to make SQL injection attacks is to not have SQL directly beneath the button your users are playing with.
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.
... is any programming job that can't be exported to India!
"Lord, grant that I may always be right, for Thou knowest that I am hard to turn" -- A Scots-Irish prayer
Been in the security game for 10 years...
From all these posts, it seems that all programmers don't have a clue about programming in a secure manner. I disagree, its just that times have changed.
Surely, a few years ago this was the case. But certainly not as bad as now. Most PHB worth their weight usually know the security buzz words associated with an implementation are. If they don't give support to the developers to create a secure solution, they arent just lacking in security skills - they are lacking in overall management skills and an understanding of IT. Security has to be part of the overall process when in development, PHB's must invest *training* for programmers and develop standards to follow.
Previous posters saying that it should be manditory for all post grads to have indepth security skills is down right short sighted. Security is a bottomless pit with many variables, a general subject can be taught. However, security can't stem strictly by programming practices. It is a collection of standards from all types, from the network, operating system to the application level. Not to mention the usual deal of people, process and technology.
I've lost count of how many pen tests I've completed where the application design was rock solid, however they had a bad password on their admin portal.
Nuff said....
Bah. That they do not have security holes is implausible, if not actually impossible, to prove. It's hard to even define what a security hole is; a changing threat model has "caused" many security holes. (Is an open relay a security hole? I say yes. Twenty years ago, everyone said no.) I doubt your statement. I can't point at a hole right now, but I have confidence that at least one security hole will eventually be discovered in those programs.
They were written using secure coding techniques that make them immune to things like buffer overflows. You can't "overlook" a buffer overflow with stralloc.
No, they make it easier to avoid buffer overflows. They don't prevent them: I quote from your hyperlink:
If they use sa.s and sa.len directly, they can screw up and increase len inappropriately. The API seems good in that it makes it much harder to do things wrong, but it is hubris to say it makes you invulnerable. Besides, buffer overflows are possible for things other than strings, so this solves only (the most common) part of the problem. And there's still the legacy code that people can use without porting to stralloc.
It does seem like a good library if you're stuck using C. Another alternative is APR, which makes managing all sorts of memory allocations much easier. Pools are handy things when dealing with a language that primitive.
But there are languages in which it actually is impossible to have a buffer overflow. Please don't confuse the issue by saying that this (which makes it somewhat easier to avoid this error) makes the error impossible.
Just in case the site gets slashdotted, here's a cut-n-paste of the home page. Whew, glad I was able to get in to get this:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, mmessier@secureprogramming.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Apache/1.3.28 Server at www.secureprogramming.com Port 80
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.
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.