I don't think you want it to "ignore" out of bounds reads/writes, but most modern languages throw an exception if you make such an erroneous access. That definitely gets rid of a load of security problems immediately. See the recent slashdot article about "Secure Programming in C" for a bunch of language-oriented debate.
That's security through obscurity. Widespread diversity helps the ecosystem; it does not generally help the individuals.
Some security through obscurity is still some security nonetheless. It's just not a good idea to trust in obscurity alone.
Being diverse does indeed help the individuals, and the analogy with "ecosystems" breaks down because computer security does not work the same way as random genetic mutations. Exploits are designed by people with finite resources, and they are less inclined to develop exploits for rare programs. A really diverse network will probably only see exploits at nodes where there's something really interesting and worthwhile to pillage, since it's simply not worth it to develop an exploit to compromise only a few machines.
That said, I still think the best way to get more secure systems is to stop trying to write them in C. (See the recent discussion on slashdot for my comments...)
Yes, that's right. Though they never actually sent mail saying, "Man, we give up!!!" they haven't e-mailed me in over a year, so I consider that a victory!
If you don't like this kind of bullying, definitely don't give in. Post your correspondence on your web page, with as little editorializing as possible, and let others draw their own conclusions. If their behavior is outrageous enough, I'm sure you'll find that it results in a lot of bad publicity for them, and the last thing they want is for students to have a good excuse to hate the association when they call asking for money. Go ahead and stick a paypal link on the site that lets alums donate to the school at their discretion. Make sure you use trademarks carefully (you can check a primer about this many places online), and build your site with renewed purpose.;)
Spurious legal threats, be they from lawyers or just the old boys' club, are one of the worst problems in the legal climate today. Since there's so little cost to fire off a Cease and Desist letter that sounds scary but is essentially contentless, corporations do it as a last resort to harass small developers who they'd never be able to beat in court. The only way I know of to fix this situation is to make there be a *high cost* for waging war against the small guy, and this could easily come in the form of bad publicity if people don't just shut down their sites right away.
By the way, yes, this has happened to me several times. Most recently was my battle with the DMCA over flipping embedding bits.
Re:And the second rule of secure programming club
on
Secure Programming
·
· Score: 1
or assure you that your program has no "undefined behavior" (i.e., a security hole). These are impossible in C,
Because they're impossible in general. See "halting problem, the".
Uh, what? Yes, most properties of programs are undecidable. Nonetheless it's simple to have a language that guarantees various properties, it just can't be exact. ML and other languages with static safety properties work by excluding all of the programs that are unsafe -- and then some others. The others are typically programs you don't want to write (because their correctness depends on some unclear criteria). At the expense of excluding some strange programs, you get a decidable property that IMPLIES the relevant safety properties.
Anyway, properties like not writing outside the bounds of an array are checked dynamically in almost every safe language. Those properties are guaranteed exactly, because they are semidecidable. You don't need decidability if you catch them at run-time. (On the other hand, you don't know if your program has such a bug until it's triggered.)
In the sense that the VM is just another piece of software, capable of being attacked and exploited.
Half of those languages don't even run in a VM. They are compiled like C, thus subject to the same set of "system" security holes (hardware bugs, kernel bugs, compiler bugs, and system library bugs).
You're jumping to (incorrect) conclusions a lot. I recommend you open your mind and try some new languages!
Re:We really need a different language
on
Secure Programming
·
· Score: 1
Yeah, I know, apache is huge and has a lot of features that would be hard to copy, especially for a single guy who probably doesn't use most of them. Fortunately, apache has a pretty good security record despite being written in C. I think that most people use a very small number of features in SSHD, though, so that is why it is next on my list!
Re:We really need a different language
on
Secure Programming
·
· Score: 1
But yet, if you want a box that has a database, web server, allows you to login (with crypto) and sends email then there are none, ZERO, nadda choices but C. Well maybe roxen web server counts, but that includes it's own interpreter... so I'd say not.
Yes indeed! But just because it is doesn't mean it ought to be. From a pragmatic point of view, there is a load of work to start any kernel project, so I don't expect it to happen soon. (And in fact, all the eyeballs and hero hackers working on the linux code results in a pretty damn good system after all. It just comes at the expense of a lot of work!)
Really if it were that simple, people would have written and used SMTP/HTTP/SSH servers in python or whatever.
This I don't agree with. In fact, in a couple weekends I rewrote ftpd in SML, because I got fed up with buffer overflows in wu_ftpd. It was really easy, and the code went from something like 24,000 lines to 3,500 (including an implementation of MD5 and MD5_crypt, and some other general server stuff that I reuse in other projects). I plan to rewrite others, especially sshd which has had a number of annoying vulnerabilities recently. I don't see any reason why a team of good hackers couldn't port the basic functionality of a number of standard services in a short period, and it would certainly help users sleep more soundly at night!
Re:Scripting languages have problems, too ...
on
Secure Programming
·
· Score: 1
where you've chosen the language based on other reasons than just how to handle a string concatenation at one point
Well, I can't reasonably argue that everyone should drop his current project and rewrite the whole thing in ML! But there is not such an incredible barrier to entry that a new project, especially one designed with security in mind, couldn't pick tools that have certain kinds of security built in. Picking a library for C is a good step, but using a safe language will take you farther and also make it less of a chore!
Re:And the second rule of secure programming club
on
Secure Programming
·
· Score: 1
Attempts like "safety properties" strike me as just giving a warm fuzzy feeling without doing much beyond security-through-obscurity.
Like well-designed hardware, a language can provide you with an abstraction that you can depend on. In particular, safe languages can do things like guarantee the sanctity of an abstract type, or assure you that your program has no "undefined behavior" (i.e., a security hole). These are impossible in C, and are often what underlies security holes, and indeed, many bugs in general. It's not security through obscurity; it's security through security.
but I have yet to see anything that isn't just being touted as "this silver bullet will make your problems all go away".
Well, you've called on two catch phrases, but you haven't explained how they apply to languages. In what sense don't languages like SML (or, hell-- Java, Dylan, ADA, Lisp, or any of the other safe languages proposed by slashdot posters) solve all of your buffer overflow problems? (And double-free, integer overflow, etc. problems) Have you even used such languages?
Re:Scripting languages have problems, too ...
on
Secure Programming
·
· Score: 1
> Getting people to use a string library is much easier than getting the to rewrite all their code in a new language, or > even create new code in a language they haven't used much before.
Is it? At least in a language with string primitives, I can just say (SML):
let
val s1 = "Hello" ^ " " ^ "World\n" in
print s1 end
Whereas with the vstr library I write (no kidding, this is from their tutorial):
Vstr_base *s1 = NULL;
if (!vstr_init())
exit (EXIT_FAILURE);
s1 = vstr_make_base(NULL);
if (!s1)
exit (EXIT_FAILURE);
/* check for failure of any of the above additions */
if (s1->conf->malloc_bad)
exit (EXIT_FAILURE);
while (s1->len)/* assumes POSIX */
if (!vstr_sc_write_fd(s1, 1, s1->len, 1, NULL))
{
if ((errno != EAGAIN) && (errno != EINTR))
exit (EXIT_FAILURE);
}
vstr_free_base(s1);
vstr_exit();
I mean, yikes. Security is not the only reason to use a high-level language; ease in expressing your ideas is another. It allows you to spend time thinking about the difficult questions in security instead of repeating tedious details.
Re:Yet languages make a big difference
on
Secure Programming
·
· Score: 1
By over 50%, you mean, 43%? Also, this figure assumes that the string library will be used correctly, which,
I meant to say:... which I think is a big assumption, especially given the size of the API.
Re:Yet languages make a big difference
on
Secure Programming
·
· Score: 1
By over 50%, you mean, 43%? Also, this figure assumes that the string library will be used correctly, which,
> The rest are almost all cross site scripting, various DOS attacks and temporary file vulnerabilities which affect > python/perl/etc. programs just as much.
I don't agree, but here there's no figure for "almost all" to contend with. Anyway, I am not suggesting python or perl for writing applications, because those have their own language-based security issues, too. To be concrete, I will suggest SML or O'Caml, but there are other appropriate choices as well.
Perhaps using a new API will give some security benefit if you use it correctly. But it's still C, with all its temptations. (No doubt you can convert to char * and back when the library didn't forsee what you're doing.) If you're doing a lot of string manipulation, you might as well use a language with strings built in (vstr looks pretty painful), and if you care about security, you might as well get total protection along with protection against integer overflow and double-frees for free (by using a safe language) as well!
Re:Scripting languages have problems, too ...
on
Secure Programming
·
· Score: 1
Sure. And there are languages that avoid buffer overruns (and double-frees, something which C can't really protect against without doing garbage collection, and format string bugs, and integer overflows), too, and people stick with C due to lack of awareness.
Re:And the second rule of secure programming club
on
Secure Programming
·
· Score: 1
> "I assume that a sufficiently skilled [cracker] will be able to do anything not explicitly forbidden by the hardware."
Yes, hardware has a much better track record at being correct than software. I blame Stroustrup in part!
> So, the second rule is, recognize that most "levels of protection" and "access controls" in programming languages
If you mean "private" vs. "public," that's not what we're talking about. We're talking about your language having properties like safety, which means that the only person who gets to write code is the developer (not the remote user uploading shellcode!).
Scripting languages have problems, too ...
on
Secure Programming
·
· Score: 1
Yeah, just imagine if those applications were written in C with printf, malloc, and strcpy!!! Though scripting languages do lower the "barrier to entry," meaning that a lot more novice programmers can start writing code, I think we'd be a lot worse off if we had those same folks writing CGI apps in C.
Anyway, I do read bugtraq, and I find that most of these bugs actually are language-based. SQL injection attacks come because the API for issuing queries works on strings, instead of query data structures. If your where clause was
"id=" + n.toString() + " and password=" + p.. that would pretty much get rid of SQL injection problems, and make code easier to write and read, too.
Most scripting langauges, like perl, have similar problems in their system shell commands, since these usually use strings as the API intermediate rather than data structures. (Ie, perl lets you open a process by using "|" as the first character of the filename.) If the shell command had you pass a list of unescaped arguments, rather than forcing you to do the escaping yourself, this wouldn't be a problem.
PHP has some number of design bugs, like the ability to include headers from the internet (???) and treating undeclared variables as input from the query string. These often lead to bugs.
There are lots of other bugs to be made (XSS is not that serious unless you are using cookies for secure data, which you shouldn't), some of which are in the language and some of which aren't. Also, it is difficult to forsee what these stumbling blocks will be when designing a language. (Though I think I've outlined one general principle above: use common data structures in APIs, not unparsing and parsing of strings.) But, language is still an important issue in addressing the source of all sorts of bugs, be it C or PHP.
They surely are. Especially take C++; this code, which is entirely within the language and not any library, has an exploitable security hole (depending on its context).
/* double-free */ delete x; delete x;
as does, perhaps,
/* integer overflow */ char * z = new char[16 + size];
Any loop that might overrun array bounds is similarly vulnerable. Most recent exploitable code has not used the unsafe C string functions, since those were so easy to find in 1994 with the 'grep' method!
Of course, the C library is written mostly in C (including printf and the C string functions), so that makes it hard to argue that C is not insecure.
Now, you imply that such bugs are only the result of poor programmers being allowed to touch a computer. Nonetheless, we see the same security problems over and over in almost every application: Linux, OpenBSD, OpenSSH, MySQL, every version of Windows, Quake III, Half-Life, Perl, etc. etc. etc. Is it possible that all of these hero programmers actually just don't know what they're doing? I don't think so. Anyway, whether they do or not is unimportant: the fact is that even the best programmers create security holes, and when those holes can be avoided by switching to a language in which they're impossible, we're crazy to not do so!
Amen. Most people's experience with modern languages ends with Java running on a VM, and yes, that is pretty slow. But not all safe languages run in a VM, and not all have as much overhead as Java. For instance, I often find ML to be as fast as or faster than C, and the code is much nicer.
C is nothing special when it comes to speed, and as processors become less and less like the machine model that C was designed against, it will continue to lose its hold. ML programmers will simply change the implementation of 'map' to do pipelining, parallelization, while C programmers will have to learn the magic way to write their 'for' loops so that the compiler can recognize that they are writing 'map'.
Though certain software really needs every last cycle squeezed out of it (Doom III?) manually, nobody wants to or needs to do that for an entire application. The vast majority of software should be written in a nice language where the compiler can do the tedious work for you, and leave the hard parts to you!
Re:We really need a different language
on
Secure Programming
·
· Score: 1
> 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.
I think he is claiming that a good goal is to minimize the amount of software written in dangerous languages like C.
Some of your kernel code needs to be unsafe, for sure. Linux is over 30 million lines, and there is no fucking way that all has to be in C. It would be possible to do bounds checking and even garbage collection in most parts the kernel. (Real-time garbage collection has been done!) Using a microkernel architecture, lots and lots of code (say, the filesystem) could be written in a high-level, safe language. Doing this has various tradeoffs--speed is one that might bother the slashdot audience. Personally, I'd love to use such a system, because I care more about my computer working correctly than working fast.
The kernel is the hardest place to argue against C. For the vast majority of computer software, especially network software where security holes are most disastrous, modern safe languages are better in almost every dimension: fewer security holes, more maintainable code, less code to verify, etc. Other than "legacy code" and "legacy programmers," it baffles me that C remains so popular.
Yes, it's impossible to get rid of all security problems in general applications with a language or tool (you could even prove this, once we had a definition of "security problem"). However, it's not unreasonable to take steps in the right direction---safe languages rule out a large class of common vulnerabilities automatically.
Yet languages make a big difference
on
Secure Programming
·
· Score: 2, Informative
> and those that think they're safe merely by using a particular programming language are in for a nasty surprise.
That's true, of course, but nonetheless languages make a huge difference.
In applications, buffer overflows, along with (recently) integer overflows, double-free bugs, and printf formatting bugs, are the most common source of exploitable holes by far. (Case in point: the MySQL buffer overflow currently on slashdot's main page, the several recent RPC vulnerabilities in XP, the recent OpenBSD hole, etc.)
All of these errors would be impossible to make in a safe language.
Yes, we still need security-conscious developers, and there are still many things to worry about. But if we can get rid of the vast majority of problems, automatically (and as a side benefit get to program in a modern high-level language, which makes many other things easier), why not switch? Just because it's not a complete solution?
"safe" and "compiled" aren't mutually exclusive. For instance, O'Caml and SML are both compiled languages that have safety (impossible to have buffer overflows, integer overflows, double-free, printf-bugs, and most other common security problems). They are very fast, so don't deserve the "interpreted" stigma. Java can even be compiled and run safely outside a VM.
Otherwise, I agree with you. Languages can't possibly fix every security hole. But if you look at the majority of holes that affect us daily (like the MySQL overflow on the front page of slashdot, or the numerous recent RPC holes in Windows), those would be gone, period.
> I seldom see SUV drivers causing accidents, they tend respect the stopping distance needed in both inclement and friendly > weather.
Wow, really? I agree that commuters with little sports cars are frequently bad, but I think that an unreasonable proportion of SUV drivers are just as bad or worse.
Slashdot Mirror
I don't think you want it to "ignore" out of bounds reads/writes, but most modern languages throw an exception if you make such an erroneous access. That definitely gets rid of a load of security problems immediately. See the recent slashdot article about "Secure Programming in C" for a bunch of language-oriented debate.
Apparently you have to make it in space (!!) if you want it to be fully transparent.
Aerogel is 99.8% holes. Check out the photos of a thin sheet insulating crayons from a blowtorch!
That's security through obscurity. Widespread diversity helps the ecosystem; it does not generally help the individuals.
Some security through obscurity is still some security nonetheless. It's just not a good idea to trust in obscurity alone.
Being diverse does indeed help the individuals, and the analogy with "ecosystems" breaks down because computer security does not work the same way as random genetic mutations. Exploits are designed by people with finite resources, and they are less inclined to develop exploits for rare programs. A really diverse network will probably only see exploits at nodes where there's something really interesting and worthwhile to pillage, since it's simply not worth it to develop an exploit to compromise only a few machines.
That said, I still think the best way to get more secure systems is to stop trying to write them in C. (See the recent discussion on slashdot for my comments...)
Yes, that's right. Though they never actually sent mail saying, "Man, we give up!!!" they haven't e-mailed me in over a year, so I consider that a victory!
Uh, because OpenSSH has a remote root exploit in it, despite code audits? Diversity is useful.
I've already tried those languages, and just wasn't impressed.
You did? Then why did you think they ran in a VM? Why did you not know what kind of security properties they have?
If you don't like this kind of bullying, definitely don't give in. Post your correspondence on your web page, with as little editorializing as possible, and let others draw their own conclusions. If their behavior is outrageous enough, I'm sure you'll find that it results in a lot of bad publicity for them, and the last thing they want is for students to have a good excuse to hate the association when they call asking for money. Go ahead and stick a paypal link on the site that lets alums donate to the school at their discretion. Make sure you use trademarks carefully (you can check a primer about this many places online), and build your site with renewed purpose. ;)
.
Spurious legal threats, be they from lawyers or just the old boys' club, are one of the worst problems in the legal climate today. Since there's so little cost to fire off a Cease and Desist letter that sounds scary but is essentially contentless, corporations do it as a last resort to harass small developers who they'd never be able to beat in court. The only way I know of to fix this situation is to make there be a *high cost* for waging war against the small guy, and this could easily come in the form of bad publicity if people don't just shut down their sites right away.
By the way, yes, this has happened to me several times. Most recently was my battle with the DMCA over flipping embedding bits
Because they're impossible in general. See "halting problem, the".
Uh, what? Yes, most properties of programs are undecidable. Nonetheless it's simple to have a language that guarantees various properties, it just can't be exact. ML and other languages with static safety properties work by excluding all of the programs that are unsafe -- and then some others. The others are typically programs you don't want to write (because their correctness depends on some unclear criteria). At the expense of excluding some strange programs, you get a decidable property that IMPLIES the relevant safety properties.
Anyway, properties like not writing outside the bounds of an array are checked dynamically in almost every safe language. Those properties are guaranteed exactly, because they are semidecidable. You don't need decidability if you catch them at run-time. (On the other hand, you don't know if your program has such a bug until it's triggered.)
In the sense that the VM is just another piece of software, capable of being attacked and exploited.
Half of those languages don't even run in a VM. They are compiled like C, thus subject to the same set of "system" security holes (hardware bugs, kernel bugs, compiler bugs, and system library bugs).
You're jumping to (incorrect) conclusions a lot. I recommend you open your mind and try some new languages!
Yeah, I know, apache is huge and has a lot of features that would be hard to copy, especially for a single guy who probably doesn't use most of them. Fortunately, apache has a pretty good security record despite being written in C. I think that most people use a very small number of features in SSHD, though, so that is why it is next on my list!
But yet, if you want a box that has a database, web server, allows you to login (with crypto) and sends email then there are none, ZERO, nadda choices but C. Well maybe roxen web server counts, but that includes it's own interpreter ... so I'd say not.
Yes indeed! But just because it is doesn't mean it ought to be. From a pragmatic point of view, there is a load of work to start any kernel project, so I don't expect it to happen soon. (And in fact, all the eyeballs and hero hackers working on the linux code results in a pretty damn good system after all. It just comes at the expense of a lot of work!)
Really if it were that simple, people would have written and used SMTP/HTTP/SSH servers in python or whatever.
This I don't agree with. In fact, in a couple weekends I rewrote ftpd in SML, because I got fed up with buffer overflows in wu_ftpd. It was really easy, and the code went from something like 24,000 lines to 3,500 (including an implementation of MD5 and MD5_crypt, and some other general server stuff that I reuse in other projects). I plan to rewrite others, especially sshd which has had a number of annoying vulnerabilities recently. I don't see any reason why a team of good hackers couldn't port the basic functionality of a number of standard services in a short period, and it would certainly help users sleep more soundly at night!
where you've chosen the language based on other reasons than just how to handle a string concatenation at one point
Well, I can't reasonably argue that everyone should drop his current project and rewrite the whole thing in ML! But there is not such an incredible barrier to entry that a new project, especially one designed with security in mind, couldn't pick tools that have certain kinds of security built in. Picking a library for C is a good step, but using a safe language will take you farther and also make it less of a chore!
Attempts like "safety properties" strike me as just giving a warm fuzzy feeling without doing much beyond security-through-obscurity.
Like well-designed hardware, a language can provide you with an abstraction that you can depend on. In particular, safe languages can do things like guarantee the sanctity of an abstract type, or assure you that your program has no "undefined behavior" (i.e., a security hole). These are impossible in C, and are often what underlies security holes, and indeed, many bugs in general. It's not security through obscurity; it's security through security.
but I have yet to see anything that isn't just being touted as "this silver bullet will make your problems all go away".
Well, you've called on two catch phrases, but you haven't explained how they apply to languages. In what sense don't languages like SML (or, hell-- Java, Dylan, ADA, Lisp, or any of the other safe languages proposed by slashdot posters) solve all of your buffer overflow problems? (And double-free, integer overflow, etc. problems) Have you even used such languages?
> even create new code in a language they haven't used much before.
Is it? At least in a language with string primitives, I can just say (SML):Whereas with the vstr library I write (no kidding, this is from their tutorial):I mean, yikes. Security is not the only reason to use a high-level language; ease in expressing your ideas is another. It allows you to spend time thinking about the difficult questions in security instead of repeating tedious details.
By over 50%, you mean, 43%? Also, this figure assumes that the string library will be used correctly, which,
... which I think is a big assumption, especially given the size of the API.
I meant to say:
By over 50%, you mean, 43%? Also, this figure assumes that the string library will be used correctly, which,
> The rest are almost all cross site scripting, various DOS attacks and temporary file vulnerabilities which affect
> python/perl/etc. programs just as much.
I don't agree, but here there's no figure for "almost all" to contend with. Anyway, I am not suggesting python or perl for writing applications, because those have their own language-based security issues, too. To be concrete, I will suggest SML or O'Caml, but there are other appropriate choices as well.
Perhaps using a new API will give some security benefit if you use it correctly. But it's still C, with all its temptations. (No doubt you can convert to char * and back when the library didn't forsee what you're doing.) If you're doing a lot of string manipulation, you might as well use a language with strings built in (vstr looks pretty painful), and if you care about security, you might as well get total protection along with protection against integer overflow and double-frees for free (by using a safe language) as well!
Sure. And there are languages that avoid buffer overruns (and double-frees, something which C can't really protect against without doing garbage collection, and format string bugs, and integer overflows), too, and people stick with C due to lack of awareness.
> "I assume that a sufficiently skilled [cracker] will be able to do anything not explicitly forbidden by the hardware."
Yes, hardware has a much better track record at being correct than software. I blame Stroustrup in part!
> So, the second rule is, recognize that most "levels of protection" and "access controls" in programming languages
If you mean "private" vs. "public," that's not what we're talking about. We're talking about your language having properties like safety, which means that the only person who gets to write code is the developer (not the remote user uploading shellcode!).
Yeah, just imagine if those applications were written in C with printf, malloc, and strcpy!!! Though scripting languages do lower the "barrier to entry," meaning that a lot more novice programmers can start writing code, I think we'd be a lot worse off if we had those same folks writing CGI apps in C.
.. instead of ..
.. that would pretty much get rid of SQL injection problems, and make code easier to write and read, too.
Anyway, I do read bugtraq, and I find that most of these bugs actually are language-based. SQL injection attacks come because the API for issuing queries works on strings, instead of query data structures. If your where clause was
And(Equaln("ID", n), Equal("Password", p))
"id=" + n.toString() + " and password=" + p
Most scripting langauges, like perl, have similar problems in their system shell commands, since these usually use strings as the API intermediate rather than data structures. (Ie, perl lets you open a process by using "|" as the first character of the filename.) If the shell command had you pass a list of unescaped arguments, rather than forcing you to do the escaping yourself, this wouldn't be a problem.
PHP has some number of design bugs, like the ability to include headers from the internet (???) and treating undeclared variables as input from the query string. These often lead to bugs.
There are lots of other bugs to be made (XSS is not that serious unless you are using cookies for secure data, which you shouldn't), some of which are in the language and some of which aren't. Also, it is difficult to forsee what these stumbling blocks will be when designing a language. (Though I think I've outlined one general principle above: use common data structures in APIs, not unparsing and parsing of strings.) But, language is still an important issue in addressing the source of all sorts of bugs, be it C or PHP.
> C and C++ are not insecure at all.
They surely are. Especially take C++; this code, which is entirely within the language and not any library, has an exploitable security hole (depending on its context).
/* double-free */
delete x;
delete x;
as does, perhaps,
/* integer overflow */
char * z = new char[16 + size];
Any loop that might overrun array bounds is similarly vulnerable. Most recent exploitable code has not used the unsafe C string functions, since those were so easy to find in 1994 with the 'grep' method!
Of course, the C library is written mostly in C (including printf and the C string functions), so that makes it hard to argue that C is not insecure.
Now, you imply that such bugs are only the result of poor programmers being allowed to touch a computer. Nonetheless, we see the same security problems over and over in almost every application: Linux, OpenBSD, OpenSSH, MySQL, every version of Windows, Quake III, Half-Life, Perl, etc. etc. etc. Is it possible that all of these hero programmers actually just don't know what they're doing? I don't think so. Anyway, whether they do or not is unimportant: the fact is that even the best programmers create security holes, and when those holes can be avoided by switching to a language in which they're impossible, we're crazy to not do so!
Amen. Most people's experience with modern languages ends with Java running on a VM, and yes, that is pretty slow. But not all safe languages run in a VM, and not all have as much overhead as Java. For instance, I often find ML to be as fast as or faster than C, and the code is much nicer.
C is nothing special when it comes to speed, and as processors become less and less like the machine model that C was designed against, it will continue to lose its hold. ML programmers will simply change the implementation of 'map' to do pipelining, parallelization, while C programmers will have to learn the magic way to write their 'for' loops so that the compiler can recognize that they are writing 'map'.
Though certain software really needs every last cycle squeezed out of it (Doom III?) manually, nobody wants to or needs to do that for an entire application. The vast majority of software should be written in a nice language where the compiler can do the tedious work for you, and leave the hard parts to you!
> 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.
I think he is claiming that a good goal is to minimize the amount of software written in dangerous languages like C.
Some of your kernel code needs to be unsafe, for sure. Linux is over 30 million lines, and there is no fucking way that all has to be in C. It would be possible to do bounds checking and even garbage collection in most parts the kernel. (Real-time garbage collection has been done!) Using a microkernel architecture, lots and lots of code (say, the filesystem) could be written in a high-level, safe language. Doing this has various tradeoffs--speed is one that might bother the slashdot audience. Personally, I'd love to use such a system, because I care more about my computer working correctly than working fast.
The kernel is the hardest place to argue against C. For the vast majority of computer software, especially network software where security holes are most disastrous, modern safe languages are better in almost every dimension: fewer security holes, more maintainable code, less code to verify, etc. Other than "legacy code" and "legacy programmers," it baffles me that C remains so popular.
Yes, it's impossible to get rid of all security problems in general applications with a language or tool (you could even prove this, once we had a definition of "security problem"). However, it's not unreasonable to take steps in the right direction---safe languages rule out a large class of common vulnerabilities automatically.
> and those that think they're safe merely by using a particular programming language are in for a nasty surprise.
That's true, of course, but nonetheless languages make a huge difference.
In applications, buffer overflows, along with (recently) integer overflows, double-free bugs, and printf formatting bugs, are the most common source of exploitable holes by far. (Case in point: the MySQL buffer overflow currently on slashdot's main page, the several recent RPC vulnerabilities in XP, the recent OpenBSD hole, etc.)
All of these errors would be impossible to make in a safe language.
Yes, we still need security-conscious developers, and there are still many things to worry about. But if we can get rid of the vast majority of problems, automatically (and as a side benefit get to program in a modern high-level language, which makes many other things easier), why not switch? Just because it's not a complete solution?
"safe" and "compiled" aren't mutually exclusive. For instance, O'Caml and SML are both compiled languages that have safety (impossible to have buffer overflows, integer overflows, double-free, printf-bugs, and most other common security problems). They are very fast, so don't deserve the "interpreted" stigma. Java can even be compiled and run safely outside a VM.
Otherwise, I agree with you. Languages can't possibly fix every security hole. But if you look at the majority of holes that affect us daily (like the MySQL overflow on the front page of slashdot, or the numerous recent RPC holes in Windows), those would be gone, period.
> I seldom see SUV drivers causing accidents, they tend respect the stopping distance needed in both inclement and friendly
> weather.
Wow, really? I agree that commuters with little sports cars are frequently bad, but I think that an unreasonable proportion of SUV drivers are just as bad or worse.