*Most* programs?!?
|
| Author | Content |
|---|---|
| phsolide Feb 15, 2009 11:39 AM EDT |
Quoting:But most programs written in C are plagued by security issues because of their usage of unsafe functions. Oh, please. Does "cat" have security issues deriving from its use of strcpy() and strcat()? No. Does "nm" or "ls" or "ps" or any of the myriad of programs written in C? Only a small minority of programs have trouble with usages of unsafe functions. And in almost all of those cases, unvalidated user input constitutes the real problem (don't check the length of the input in this case). Will this rube write an article next about how "most programs in Perl|JavaScript| PHP|Python|Java are plagued by security issues because of their usage of unsafe string concatenation operators"? Because that's exactly the issue behind SQL Injections. Tools all have their appropriate uses, even very sharp, very loud, very dangerous ones. Bandsaws can take off a hand as easily as they can cut contoured shapes in wood. Does that mean woodworkers should abandon the use of bandsaws? |
| theboomboomcars Feb 15, 2009 11:15 PM EDT |
Quoting:Does that mean woodworkers should abandon the use of bandsaws? Of course, didn't you get the memo? The bandsaw, tablesaw, and jigsaw have all been replaced by the Psysaw. It's the saw that cuts wood just by thinking of the cut that you want cut. It is much safer than previous types of saws because it doesn't use a blade. |
| gus3 Feb 16, 2009 12:26 AM EDT |
Most programs written in C are written by rank amateurs in high school or college, who have had zero education in secure code. "nm", "ls", "ps" and the rest of util-linux/binutils/procps are but the slimmest slice of C programs. Thanks to their age, they have been examined, tested, hacked, crashed, fixed, and re-tested. But even that isn't a very strong guarantee. Look at Debian's OpenSSL compromise, caused by someone who tinkered with cryptographic entropy code that he had no business tinkering with. That code wasn't composed insecurely, but it became insecure due to third-party incompetence. What makes you think the same thing can't happen to util-linux via the "unsafe" functions? And Theo is reading this and laughing at us. |
| shmget Feb 16, 2009 1:09 AM EDT |
gus3 said: "That code wasn't composed insecurely, but it became insecure due to third-party incompetence" Sure, but there is no API to protect against stupidity and/or incompetence. 'safe' functions are only safe if they are used, and used the way they are supposed to. Murphy's Second Corollary: It is impossible to make anything foolproof, because fools are so ingenious. |
| tuxchick Feb 16, 2009 1:15 AM EDT |
Forgive the intrusion of this lowly egg--- so the article is not giving good advice? |
| Sander_Marechal Feb 16, 2009 3:05 AM EDT |
tuxchick: Actually it does not, though I completely disagree with phsolide. There is a nice signature floating around on gamedev that says it all:Quoting:As a general rule, if you post in the "For Beginners" forum and your code contains the word 'char', you have a bug. std::string roxors teh big one one one one. The article suggests using strlcpy() instead of strcpy() but you still end up lugging around null terminated char pointers with all kinds of problems. Use a proper string class instead like std::string or Boost::string. |
| herzeleid Feb 16, 2009 5:18 AM EDT |
oh noes! did you know teh linux kernel is written in c? Actually, most operating systems are written in c. |
| gus3 Feb 16, 2009 9:35 AM EDT |
Yes, and the weekly security list in the SANS @Risk Consensus Security Vulnerability Alert reflects this. |
| krisum Feb 16, 2009 1:14 PM EDT |
As mentioned in the comments, the strl* functions are non-standard (GNU libc does not have them) and using strn* functions or snprintf as required would be the way to go. |
| herzeleid Feb 16, 2009 2:21 PM EDT |
@gus - so, you seem dead set against c - what language do you think the kernel should be written in? |
| techiem2 Feb 16, 2009 2:38 PM EDT |
vb.net! *hides* |
| jezuch Feb 16, 2009 4:15 PM EDT |
Quoting:what language do you think the kernel should be written in? Assembler! Oh, wait, C is a high-level assembler... Never mind. |
| Sander_Marechal Feb 16, 2009 4:35 PM EDT |
@herzeleid: Nothing wrong with C if you know what you're doing and need the power that C provides. C is a powertool and should be wielded responsibly. For most new projects C simply isn't the right language. Especially not without using sensible safeguards like a decent string library. And the kernel is just a stawman argument. Kernels are such performance sensitive, complicated and atypical projects that they defy the standard arguments about choosing your projects implementation language. |
| herzeleid Feb 16, 2009 6:15 PM EDT |
@techiem2 - yep, vb.net was the silly example I had in the back of my mind when I asked the question - that and visual c++ @jezuch - indeed, I always heard c referred to as "portable assembler" - it's got nearly the same bit tweaking capabilities. @sander - the fact that the kernel is performance sensitive is the point I wanted to make. What's the alternative, assembler? c is much safer, more manageable and easier to debug than assembler, and it's faster and leaner than any of the alternatives. Actually, come to think of it, about 5% of the linux kernel *is* written in assembler, really low level, architecture specific stuff. In short, there are a number of real world scenarios where c is the only practical choice. if you know c, and the code needs to be lean, efficient and blazing fast, you really don't want to do it in python, java, haskell or ruby! |
| Sander_Marechal Feb 16, 2009 6:21 PM EDT |
@herzeleid: Yes, but the truth is that many more applications are implemented in C that would be warranted under those arguments. Even I am guilty of it. Gnome-hearts is mostly implemented in C but it would probably be much better to implement it in Python and link in a small C library to do fast rendering of the cards on a GDK buffer. |
| gus3 Feb 16, 2009 6:29 PM EDT |
herzeleid: In properly trained hands, C can be powerful. In properly trained hands, a backhoe can be powerful. But most programmers are at the equivalent stage where they only know how to put in the keys and start the engine. I wouldn't trust them to avoid the overhead lines or the pipe running from the back-yard well. |
| techiem2 Feb 16, 2009 6:33 PM EDT |
Quoting:In properly trained hands, a backhoe can be powerful. In improperly trained hands (or just not careful ones), that backhoe will cut through your college's T1 line.... (yes, that happened when I was at college) As you say, it's all dependent on the skill and carefulness of the user. |
| phsolide Feb 16, 2009 10:27 PM EDT |
Well, you'll never really understand garbage collection if you just program in Java or Scheme or Tcl. And as G.K. Chesterton once said, "Sufficiently advanced incompetence is indistinguishable from malice!" I just think that blaming ASCII-Nul terminated strings for all problems constitutes dangerous short-sightedness. I've seen code using "std" C++ stuff that was indistinguishable from maliciously-coded programs. If you follow "Bugtraq" and "Full-disclosure" mailing lists, you'll see that most big bugs these days are not at the C-level: they're SQL injections, or getting the PHP interpreter to execute some code you uploaded earlier, or getting a CGI-BIN program to execute concatenated strings. Buffer overflows don't come up very often at all anymore, not since the "Witty" worm, anyway. |
| gus3 Feb 16, 2009 10:42 PM EDT |
Quoting:I've seen code using "std" C++Right there's your problem... /ducking |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!