Slashdot Mirror
Secure Programming in GNU/Linux Systems: Part I
LNXPhreak writes "A new article on OSWeekly.com discusses secure programming in GPU/Linux systems in terms of programming talent and requirements. Quote: "A "secure program" is an application that sits on a security boundary, taking input from a source that does not have the same access rights as the program. Such programs include application programs used as viewers of remote data, web applications (including CGI scripts), network servers, and setuid/setgid programs."
Well that's strictly true, but you know what he's saying.
The string handling functions of the standard C library make it very easy to write unsafe code.
Similarly, a car with very bad brakes isn't intrinsically unsafe, as long as the cautious driver is prepared to take alternative precautions on ever bend. But if the driver makes an error (and everyone, yes, even you, will eventually make an error), he's going to end up wrapped around a tree.
Even though other cars aren't safe in the hands of a bad driver, given that you will make mistakes, you'll have far fewer horrific crashes in a car with ABS.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
He does have a point, though. It *is* possible to use the standard C library string functions in a safe manner, but it's difficult and error-prone - and if you make just one mistake, it might well be enough to open an exploitable hole in your program.
It's important to realise that programmers aren't perfect. "unsafe" programmers, as you call them, are not something you'll ever be able to get rid of; your best bet is thus to give them tools that make it as easy as possible to write safe code and that will mitigate the impact when things *do* go wrong - in other words, tools that will fail in a defined and safe manner.
One of the problems with C (actually, one of its strengths, too, of course, depending your point of view) is that it's really only optimised for speed, and a lot of compromises were and still are made there. Similarly, another problem is that C is intended as a very low-level language - a hardware-independent macro-assembler with automatic register allocation, if you will. This makes it very suitable for certain low-level tasks (like OS kernel programming), but it also creates problems when you move higher up in the level hierarchy, away from the bare metal.
C does have its place, but if you want to develop an application that's not closely tied to the hardware etc., C probably isn't as ideal a choice as you might think - and at the very least, if you *do* decide to use it after all, you should be aware of its weaknesses and pitfalls so you can avoid them.
It's just like with guns. Guns can be handled in a safe manner, but that doesn't mean you should give everyone a loaded and unlocked gun who's never touched one before in his life - chances are that accidents *will* happen. And while you can say that it's handler's fault, not the gun's, well... accidents still will happen. It's better to get off of one's high horse and try to minimise the number of actual incidents (and the severity of those incidents that do happen), since that's what counts in the end.
quidquid latine dictum sit altum videtur.
I completely agree with you're point, and just thought I would pose a random sort of thought I had.
The biggest problem with C and C++ is that it's very easy for novice programmers to create insecure programs because, for the most part, they don't know how to properly work with pointers. Now days it seems to me that much fewer people learn C/C++ than used to just a few years ago. In highschool in my CS pretty much everyone who knew any programming knew C or C++. Back then, and that was only a few years ago mind, it seemed rare to me to know anyone who knew, e.g. perl or Java, and didn't know C or (more often) C++.
Now, this semester I graduate with a degree in Computer Information Systems, and of the 20 or 30 people I know off hand that are within a semester or two of me, I'm the only one who is competent with C++. There are a couple of other people who vaguely know it, and could probably recognize the syntax, but couldn't write anything useful in it.
At my school, the programming languages that are explicitly required are Java, VB.NET, COBOL, and just enough C# to do some stuff in ASP.NET- which is required for the web class. They teach a couple of assembly classes, and a couple of C++ classes that are required for the CET majors and offered as an elective to the CIS majors. I'm the *ONLY* person in the 4 years I've been at school I know who is a CIS major who took these classes.
So now, a lot of people who call themselves programmers are graduating and, quite literally, have no idea what a pointer is. So, this makes me wonder. Are C and C++ safer because most of the bad programmers are now working in "safe" languages like Java, or are they less safe because people don't learn about pointers early on?
Personally, I never understood why people have such trouble with understanding pointers, but then it may be because in highschool I was lucky enough to have an absolutely fantastic computer science teacher who instilled the basic ideas in us about how the compiler works and how variables work, and what memory addresses are, etc. from our first programming class.
Anyway, there wasn't much of a point to all that (it's 4:20am right now, and I should have been in bed 4 or 5 hours ago, so just be thankful that it's coherent (if indeed it is)) but maybe it'll stimulate discussion anyway.
Famous Last Words: "hmm...wikipedia says it's edible"
...in GNU/Linux systems: 1500 pages, 3 volumes. ...in Windows systems: Two words: "You don't".
Love over Gold.
The use of unconstrained pointers and casting (don't forget that in C this includes arrays!), combined with allocation of local data in the same stack that contains state information (registers to be restored upon function return) is at the heart of a large portion (most?) of the common security vulnerabilities on PCs.
Some large-ish number of years ago I saw an article in which the author (don't recall the name offhand, sorry) asserted that raw pointers were the data equivalent of GOTOs. Both are potentially useful as under-the-hood implementation mechanisms, but entirely too easy to abuse for them to be exposed in a high-level-language.