| |||||||||||||
|
| |||||||||||||
Insecurity Blues: Jeremy Allison reflects on Samba security flawsInsecurity Blues: Jeremy Allison reflects on Samba security flawsPosted Nov 27, 2007 21:34 UTC (Tue) by RobSeace (subscriber, #4435)In reply to: Insecurity Blues: Jeremy Allison reflects on Samba security flaws by rmstar Parent article: Insecurity Blues: Jeremy Allison reflects on Samba security flaws
Well, I certainly wouldn't say that... There are many things which C is perfectly suited for... (Not to mention most of your "safe" languages being written in C to start with, so if C is so bad, the underpinnings of your "safe" language is unsafe, too...) It's not a language for the novice to use to write production code, however... It's definitely not easy or friendly to newbies... But, once you know it well, there's really nothing better for most tasks, IMHO... Yes, it requires strict competence, if you're writing anything with any sort of security needs, but I'd say that SHOULD apply to ANY language, because if you allow incompetents to write security-critical apps, then regardless of language, you probably have an insecure pile of junk (just maybe free of the standard C gotchas)... If your only worry is libc string functions, then use a managed string library of some sort, and be just as safe as your "safe" language of choice... If you choose to use low-level C strings, then well you better be competent enough to use them properly, or the fault lies entirely on YOU, not the language... I hate people complaining about too-powerful features which allow shooting oneself in the foot; those same powerful features also allow lots of useful functionality to people that know how to use them properly, and the language would be worse off without them...
(Log in to post comments)
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 27, 2007 23:02 UTC (Tue) by rmstar (guest, #3672) [Link] (Not to mention most of your "safe" languages being written in C to start with, so if C is so bad, the underpinnings of your "safe" language is unsafe, too...)There are quite a few instances where such languages are written in itself. Without endorsing it, I think Ocaml is one. Most of the time, the implementation in C is just a vehicle. C happens to be everywhere, so. Often there is some core runtime, written by competent programmers, that is written in C because there is no point in not tapping the unix infrastructure at that level, and that is always C. Besides. If you write a compiler in C, it does not mean that the compiled language inherits C's unsafe semantics. Yes, it requires strict competence, if you're writing anything with any sort of security needs, but I'd say that SHOULD apply to ANY language, because if you allow incompetents to write security-critical apps, then regardless of language, you probably have an insecure pile of junk (just maybe free of the standard C gotchas)... I think that is a bogus argument. If you have the same software, but without buffer overflows, and have reduced security flaws to true logic errors, then a lot has been won. Let's drag the traditional car analogy into the mix. The reality is that you will have loads of incompetent drivers. You could give them plain old brakes, or ABS. You could give them anti-slip and whatnot, or a POS that will bite back as soon as the driver makes a mistake. Personally, I think it is an obvious choice. It certainly is one in the Real World, where it has been decided that you must wear seat belts, for instance.
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 28, 2007 0:11 UTC (Wed) by RobSeace (subscriber, #4435) [Link] > There are quite a few instances where such languages are written in itself. Some, yes... I was thinking more about the script/VM type languages (Java, Python, etc.), which most people love to tout as do-all C replacements... > I think that is a bogus argument. If you have the same software, but > without buffer overflows, and have reduced security flaws to true logic > errors, then a lot has been won. Well, I'm not sure what you're defining as a logic error, if a buffer overflow isn't one... The programmer made a mistake and misused the API in regards to how much room he really had in his buffer... Now, you can argue that's an undue burden on us poor programmers to have to deal with, but I'd disagree (when talking about purely C programmers; if they can't handle it, they really shouldn't be writing C code)... But, in any case, it's clearly an error on the programmer's part, every bit as much as anything else they could do wrong (eg: see my aforementioned ways to misuse "safe" functions like snprintf())... And, it's not like we're talking about just magically making buffer-overflows go away with no other changes to the code (which will surely introduce NEW bugs), either... That would be equivalent to using some bounds-checking compiler or something... But, you're talking about changing to a completely different language, and/or using completely different functions (back on track with the original topic), which means you don't necessarily end up with a bug count of "old_bugs - buffer_overflows"... > It certainly is one in the Real World, where it has been decided that > you must wear seat belts, for instance. Unless you live in NH, the last state in the country to respect drivers enough to let them choose their own safety needs for themselves... ;-/ But, to continue the analogy: would you rather drive on the road near (or with) an untrained driver who THINKS he's driving a "safe" car, and therefore is much more lax and uncaring in his driving, or a highly trained driver who is driving a horribly unsafe car with no safety equipment of any kind, but who knows it full well and is capable of handling it?
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 28, 2007 0:57 UTC (Wed) by rmstar (guest, #3672) [Link] The programmer made a mistake and misused the API in regards to how much room he really had in his buffer... Now, you can argue that's an undue burden on us poor programmers to have to deal with, but I'd disagree (when talking about purely C programmers; if they can't handle it, they really shouldn't be writing C code)... As far as I can tell, this means that nobody should be writing C code. And that means especially those deluded enough to believe they are invincible and infallible.
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 28, 2007 7:23 UTC (Wed) by njs (guest, #40338) [Link] >this means that nobody should be writing C code No, it just eliminates those of us who are only on par with, say, Jeremy Allison, or Tridge. I can when necessary write pointer-slinging, strcpy-calling, safe code. But ugh, who wants to live like that? It's like buying a house with razors on the doorknobs and poison in the fridge -- you have to be on your toes *all* *the* *time*. Much nicer to furnish up a cozy codebase with fuzzy rugs and sane routines you can count on. (And that's true no matter what language you're using.) (Tangential note to RobSeace: English contains many fine sentence-terminal punctuation marks, but the ellipsis, when used in quantity, is not one of them. Or at least it makes this reader's teeth hurt. FYI.)
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 28, 2007 11:36 UTC (Wed) by RobSeace (subscriber, #4435) [Link] > I can when necessary write pointer-slinging, strcpy-calling, safe code. But ugh, who wants to > live like that? It's like buying a house with razors on the doorknobs and poison in the > fridge -- you have to be on your toes *all* *the* *time*. Much nicer to furnish up a cozy > codebase with fuzzy rugs and sane routines you can count on. (And that's true no matter what > language you're using.) Yeah, and I agree with you completely... Nowhere did I ever say everyone should be using strcpy()/sprintf()/whatever ALL THE TIME... In fact, several times, I've said exactly the opposite: such things should probably be used pretty sparingly, and only when they really make sense... It's merely the dogmatic total rejection of such functions being used EVER which bothers me... It's like blanket prohibitions on goto; sometimes, despite it being an ugly beast that when misused can lead to horrible spaghetti code, there really is no better tool for the job than goto, and trying to conjure up some other method will only lead to uglier and harder to follow code... I'm just saying, use your brain and use the right tool for the job; and, don't just choose or reject your tools based on dogma... > (Tangential note to RobSeace: English contains many fine sentence-terminal punctuation marks, > but the ellipsis, when used in quantity, is not one of them. Or at least it makes this > reader's teeth hurt. FYI.) Heh. Sorry about that... ;-) It's a REALLY old bad habit that I'm not sure I'm even capable of breaking at this point in my life...
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 4:19 UTC (Thu) by njs (guest, #40338) [Link] There certainly are people who are dogmatic about whether the use of strcpy is acceptable -- both those who say it is not, and those who say it is. At the moment I'm seeing more of the latter than the former in this thread :-). I don't, though, see Jeremy Allison's comments as falling into either camp; rather, he sounds like he's saying "this is how we do things around here, because it's what we've found through experience works best for us". Your situation, of course, might be different, but it's hard to argue with that sort of statement directly unless one has had the experiences it is based on, or at the least studied them. I have to say my own experiences seem more like Jeremy Allison's than yours, though, to the point that I wonder if we're coming from the same place at all. Do you, for instance, mostly write new projects from scratch, rather than working in existing codebases? Your protestations about strcpy sound to my ears like someone saying "I only put razors on *some* doorknobs, and only doors I use less often and where they look particularly pretty". Sure, it'll be fine when you first install them, but it's stressful to always have to be on your toes whenever you use that door, and sooner or later you're going to wander into that room while half-asleep and lose a finger. Likewise, it's stressful to always have to be hyper-alert whenever one deals with a function because it contains dangerous calls like strcpy, and sooner or later someone's going to make a mistake. Except that in the worst case the latter mistake might cost millions of dollars, which is probably *more* than your finger was worth... > Heh. Sorry about that... ;-) It's a REALLY old bad habit that I'm not sure I'm even capable of breaking at this point in my life... I would personally find the agony of hitting the search-replace button to be totally worth it if it improved my image in the eyes of those I wanted to talk to, but this may be another place where we agree to disagree :-).
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 11:32 UTC (Thu) by RobSeace (subscriber, #4435) [Link] > There certainly are people who are dogmatic about whether the use of strcpy > is acceptable -- both those who say it is not, and those who say it is. At > the moment I'm seeing more of the latter than the former in this thread :-). I know it was meant as a joke, but it's really not true... No one at all here is saying to DOGMATICALLY choose to use strcpy() (or anything else) in all situations... I'm saying THINK about what makes sense to use, and use that! That's all... Why is that so controversial?? Because I won't rule out the POSSIBILITY of even CONSIDERING to use strcpy()?? Ruling something out completely without any logical thought or consideration is the definition of dogma... > Do you, for instance, mostly write new projects from scratch, rather than > working in existing codebases? These days, quite a bit of both... In the past, mostly the latter... > Likewise, it's stressful to always have to be hyper-alert whenever one > deals with a function because it contains dangerous calls like strcpy, > and sooner or later someone's going to make a mistake. I'm saying don't use it when it's a "dangerous call"; use it only when it makes sense to obviously safely do so... Just as a simple example: to implement a strdup(): "newstr = malloc (strlen (oldstr) + 1); strcpy (newstr, oldstr);"... That's never a "dangerous" usage, and there's no possibility of problems arising from that strcpy() which using any supposedly "safe" replacement would save you from... (And, for the wise-guy about to point out potential integer overflow in the malloc() call, shut up... ;-) Assume there's checking prior that catches it... In any case, it's got nothing to do with strcpy()...) > I would personally find the agony of hitting the search-replace button > to be totally worth it if it improved my image in the eyes of those I > wanted to talk to, but this may be another place where we agree to > disagree :-). Apparently so... I figure anyone so shallow as to judge me based on such a simple quirk of my writing style (on the Internet, no less, where you're lucky to get any punctuation at all, or capitalization, or anything approaching semi-correct spelling more than 50% of the time) is not someone whose opinion I care much about anyway... Thankfully, most people don't do that... (And, since you haven't actually stopped talking to me either, I'm guessing you must not judge me so poorly as to be unworthy of talking to, at least, even though you're the only one complaining...)
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 28, 2007 11:29 UTC (Wed) by RobSeace (subscriber, #4435) [Link] > As far as I can tell, this means that nobody should be writing C code. And > that means especially those deluded enough to believe they are invincible > and infallible. That's a silly thing to say... I didn't say anything about being invicible or infallible... I said if you can't handle doing the hard work necessary to use libc functions properly, then you probably shouldn't be writing C code (or, at the very least, you shouldn't be using those libc functions)... There's a difference between knowing well how something works and being able to use it, yet making a simple mistake (which as I said before, we're all likely to do as long as programs are written by humans) vs. not knowing/caring how it works and being unqualified to use it, but trying anyway and making a mess of things... The outcomes may be roughly the same in some cases, but the important difference to me is that the former programmer will undoubtedly learn from the mistake and be far less likely to make it again in the future, while the latter will just complain about the inadequacies of his language/libraries, yet likely just continue on still using them and still doing the same stupid things again in the future...
When C is appropriate Posted Nov 30, 2007 21:48 UTC (Fri) by kevinbsmith (guest, #4778) [Link] There is also a big difference between thinking you are skilled enough to be safe and productive in C, and actually being so. Sadly, a lot of folks fall into the former camp. And by definition, they think they are in the latter group. I would like to see the language selected based on appropriateness for the task, rather than who the coder happens to be. Just because you have massive C skill doesn't make it the right choice for all projects. Conversely, while I love Ruby, I probably wouldn't want my video driver written in it. My own personal bias: Use the highest-level language you can get away with. Which means not C most of the time. YMMV depending on your line of work, of course. I view C now as being where assembly language was 20 years ago. Lots of folks then were still using assembly where C would be much more appropriate. I was happy to get out of assembly language, and later was happy to get away from C (for most projects, although I still go back to it once in a while).
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 28, 2007 3:37 UTC (Wed) by dvdeug (subscriber, #10998) [Link] I don't think that the amount of safety equipment changes the driving standard of most drivers, and I really don't think that we're magically going to get real life drivers and programmers replaced with these highly trained expert drivers. Personally, I want a guarantee that if some idiot without a seat belt dies in an accident with me, I get let off the hook. If you want to take your safety into your own hands, you don't get to hold others responsible for it.
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 28, 2007 11:58 UTC (Wed) by RobSeace (subscriber, #4435) [Link] > I don't think that the amount of safety equipment changes the driving > standard of most drivers No, and I didn't say it did... I was posing a hypothetical between two very different drivers/programmers with different equipment to TRY to make the point (but obviously failing to do so) that it's not the EQUIPMENT which matters so much as the driver/programmer... > and I really don't think that we're magically going to get real life > drivers and programmers replaced with these highly trained expert drivers. *sigh* If only... ;-) But, seriously, how do you think we end up with highly-trained expert programmers if not by them learning from long experience? The thing is, some people just don't WANT to learn, and don't care about safety... You know the people in regards to drivers: idiots chatting away on their cell phones, putting on make-up, shaving, reading papers/books, etc. all while driving... Anyone with half a brain cell could realize that's dangerous, yet they do it anyway... Some would probably continue doing it even after causing an accident while doing it... These are the same sort of people who as programmers continue misusing strcpy()/sprintf()/etc., refusing to understand or care about the security implications... It's these sort of people who need to go (to another language or at least to safer functions), IMHO... But, I don't think it's fair to assume EVERYONE is that sort of person, either... There do still exist people who WANT to learn and are capable of understanding how to write proper code with low-level C tools, given time... And, they should be allowed and encouraged to do so... > If you want to take your safety into your own hands, you don't get > to hold others responsible for it. And, holding others responsible is precisely what all the "C/libc is unsafe and too hard to use!" whiners are doing... If it's too hard for someone, they should use something else... But, to go on using it, and then when THEY screw up to blame it on their language/library (which THEY chose to (mis)use), is exactly (mis)placing the blame on others... To reiterate: I have no problem with someone saying, "I think sprintf() is too hard for me to use safely, so I'm going to use snprintf() instead!"... What I have a problem with is saying, "sprintf() is too hard for ANYONE to EVER use safely, so I'm DEMANDING that EVERYONE ALWAYS use snprintf() instead!"...
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 0:21 UTC (Thu) by dvdeug (subscriber, #10998) [Link] > to TRY to make the point (but obviously failing > to do so) that it's not the EQUIPMENT which matters so much as the > driver/programmer... Hyperbolic comparisons are never going to make the point. There are no drivers safe enough to drive down residential streets in a rocket car. There are drivers who injure people or damage property driving a tricycle. Saying the equipment doesn't matter is as silly as saying the driver/programmer doesn't matter. In any case, if a problem is important enough, you work on all aspects of the problem. We didn't take <a href="http://en.wikipedia.org/wiki/Radithor">Radithor</a> off the market and declare the war on bad medicine over; we worry about medicines that have a slight chance of causing liver trouble. If I'm writing code that's a matter of life and death, I want the best programmers, but I also want to use <a href="http://en.wikipedia.org/wiki/SPARK_programming_language">SPARK</a>, where I don't just trust the programmer, I can actually prove that there are no divisions by zero or buffer overflows. I'm also not going to run this on computers from Wal-Mart; I'm going to run it on systems with RAID, parity-checking memory, and older hardware that doesn't have cutting-edge bugs. > The thing is, some people just don't WANT to learn, and > don't care about safety... And some of them do want to learn and do care about safety, but still make mistakes. > You know the people in regards to drivers: And there are people who don't do anything particularly wrong as regards to driving, but don't make good drivers, because they don't have a long attention span, they don't have good reflexes, etc. > There do still exist people who WANT to learn and are capable of > understanding how to write proper code with low-level C tools, > given time... And, they should be allowed and encouraged > to do so... Why? How many people have to suffer identity theft because while these people were trying to learn, they let a box get rooted? No other occupation encourages the use of dangerous hard-to-use tools except when it's actually necessary. > And, holding others responsible is precisely what all the "C/libc > is unsafe and too hard to use!" whiners are doing... If it's too > hard for someone, they should use something else... As a general rule, those people do use something else, whenever their boss isn't someone who insists that C is the only language to use. But they still have to deal with the problems from everyone else using C. > What I have a problem with is saying, > "sprintf() is too hard for ANYONE to EVER > use safely, so I'm DEMANDING that EVERYONE ALWAYS > use snprintf() instead!"... And what I have a problem with is hackers walking all over my system because someone "knew" they were good enough to use sprintf. Psychological studies show that many of the people who have the most confidence in their ability in a subject actually have just enough knowledge to be dangerous.
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 11:47 UTC (Thu) by RobSeace (subscriber, #4435) [Link] > Hyperbolic comparisons are never going to make the point. Right, but yet everyone still uses them... I was merely contininuing the previous poster's seat-belt/car analogy... > Saying the equipment doesn't matter is as silly as saying the > driver/programmer doesn't matter. Very true... Thankfully, I don't see anyone here who said anything of the sort... > And some of them do want to learn and do care about safety, but still make mistakes. If they're human beings, of course they make mistakes... Is anyone actually READING my previous posts, or just blindly attacking me as if I were a straw-man?? > And there are people who don't do anything particularly wrong as regards > to driving, but don't make good drivers, because they don't have a long > attention span, they don't have good reflexes, etc. Then, you know, maybe they really shouldn't be driving at all... > Why? How many people have to suffer identity theft because while these > people were trying to learn, they let a box get rooted? *sigh* So, to you, "learn" == "write production code"?? Ok... I'll try to make it clear (again; I'm sure I've said it before): no, I don't think inexperienced programmers should be using C at all to write production code... Any shipped C code had best be written by pretty highly experienced C programmers, IMHO... But, the only way you GET highly experienced C programmers is to let them learn how to create it... But, you need not actually ship the junk they're sure to write AS they're learning! > No other occupation encourages the use of dangerous hard-to-use tools > except when it's actually necessary. And, sometimes, C is actually necessary, for any number of reasons... On top of that, it's really a good language, once you know how to use it... Just as "vi" is a great editor for experts at it, but you sure wouldn't want to foist it on someone unsuspecting...
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 14:54 UTC (Thu) by dvdeug (subscriber, #10998) [Link] What part of reality are we in here, where we can afford to take all these programmers that are filling needed positions and writing needed code, and tell them they need to be serving apprenticeships for a few years? It's not going to happen. "learning" in this case means "writing production code", because no one is going to pay for anything else. C is not actually necessary in most cases. Excluding things like X and the kernel, where the use of C is debatable, mainstream application code can be written in just about any language, and the only possible reason for C is premature optimization.
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 15:38 UTC (Thu) by RobSeace (subscriber, #4435) [Link] > It's not going to happen. "learning" in this case means "writing production > code", because no one is going to pay for anything else. If they won't pay for it, then they deserve what they get: buggy, insecure code written by inexperienced programmers who don't know what they're doing... And, anyone buying/using their software should realize that's what the situation is, and avoid their software, if they're smart... You also make it sound as if there's no "learning" that goes on prior to one getting a professional programming job... I don't know about you, but long before I was ever hired and paid to write any code, I already HAD quite a bit of experience at doing so, not only from HS and college classes, but also from working on various personal projects and making the effort to learn things on my own (mainly because I very much enjoy programming, and wanted to become as proficient at it as possible)... Of course, once on the job, I certainly learned a lot more, as well... But, you make it sound like companies are hiring random monkeys off the street who don't know C from COBOL, and expecting them to churn out production quality C code for peanuts... If that's the case, I would want to avoid any such company's products like the plague... > Excluding things like X and the kernel, Yeah, little minor things like those... ;-/ > where the use of C is debatable, Debatable?? Ok... Let's see you write that Python/Java-based kernel... > and the only possible reason for C is premature optimization. The ONLY possible reason, huh? Suppose you require the use of certain libraries, which are only available in C (and don't have the time/money to port them to some other language)? Suppose you need to port to multiple different weird systems, and the ONLY thing you can count on them having in common is a C compiler that roughly understands at least some subset of plain old ANSI C? Suppose you need to write really compact and efficient code for running on some very underpowered hardware? Suppose your company already has a large number of proficient C programmers, and you simply don't want to waste their talents (or replace them all) writing in some completely foreign (and likely undesirable) language for them? Suppose you simply like C, consider it elegant and beautiful, and don't think there's any real NEED to use anything else?
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 16:34 UTC (Thu) by dvdeug (subscriber, #10998) [Link] So basically all the bugs in current software are due to inexperienced programmers, and the only way to solve it is more training. Since that's not going to happen everyone should just tolerate bugs instead of trying something to fix them. Great solution. > But, you make it sound like companies are hiring random monkeys off the > street who don't know C from COBOL, and expecting them to churn out > production quality C code > for peanuts... Where are these programmers getting the training on how to use sprintf in C? I don't recall that in any of my college classes, nor really do I recall it in any of the books on C I've read. > Yeah, little minor things like those... ;-/ Yeah, minor things like those. The amount of code in the kernel and X is dwarfed by the amount of code in Mozilla and KDE and GNOME. What language we use for them should not dictate what language we use for the rest of our code. > Debatable?? Ok... Let's see you write that Python/Java-based kernel... Can you name any languages besides Python, Perl, Java, C, and C++? Oh good, BASIC, but I'm sure you can name some more... In reality, kernels have been written in a number of languages, including Ada, PL/1, Modula-3, Pascal, Oberon, and, yes, Java. In all cases, including C, you need a certain amount of assembly glue code, but beyond that it's just normal code. > Suppose you require the use of certain libraries, which are > only available in C It's possible, but overrated. Many languages have automatic binding generators from C to that language. > Suppose you need to port to multiple different weird systems, and > the ONLY thing you can count on them having in common is a C compiler > that roughly understands at least some subset of plain old ANSI C? Point GCC at then and write in Java or Ada. Seriously, it's possible, but it's not like it's a common problem, and trying to use a compiler that "roughly understands at least some subset of plain old ANSI C" is masochism. The days of writing code for random UNIX systems without GCC are seriously numbered. > Suppose you need to write really compact and efficient code for > running on some very underpowered hardware? Again, I assume you must have missed that class on the history of computing? C was not the first language on the block; there are many languages that predate C, and hence were designed for running on some very slow hardware. Many languages are better at running on very small systems, like FORTH. Ada was _designed_ to run on underpowered embedded hardware. And really, not only is this another niche field, what's very underpowered hardware today could frequently run Java or Perl. > Suppose you simply like C, consider it elegant and > beautiful, and don't think there's any real NEED to > use anything else? An engineer uses the best tool for the job. If you using a tool because you like it, against any argument that it's not the right tool for a job, you're a hobbyist, not a serious professional.
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 17:13 UTC (Thu) by RobSeace (subscriber, #4435) [Link] > So basically all the bugs in current software are due to inexperienced > programmers, and the only way to solve it is more training. Since that's > not going to happen everyone should just tolerate bugs instead of trying > something to fix them. Great solution. My god, you DO so love attacking straw-men, don't you? How about addressing things I actually said, rather than inventing easy-to-attack arguments and putting them in my mouth? Could you possibly be bothered to stick to doing that, by any chance? Thanks... Where on Earth did you read anyone EVER say we should "tolerate bugs instead of trying to fix them"?? It certainly was never anything *I* said, I know that much, at least... And, what makes you so bloody resistant to the idea of actual training and experience for programmers?? You prefer inexperienced programmers who don't know what they're doing to write your software? I sure don't... You casually state that's never going to happen, as if you control the world or have omniscient insight into the minds of everyone on the planet... Despite the fact that I know it DOES indeed happen at many places around the world... > Where are these programmers getting the training on how to use sprintf > in C? I don't recall that in any of my college classes, nor really do I > recall it in any of the books on C I've read. I sure recall it (and my memory sucks! ;-))... I can remember lots of seg-faults in my early days of learning C, and learning about buffer overflows and how to avoid them... (Back then, there wasn't much talk about them being security risks though, just annoyances to be avoided...) > In reality, kernels have been written in a number of languages, Uh huh... And, "in reality", how many of those are actually USED for any real work, and not just as teaching tools or demos? > The days of writing code for random UNIX systems without GCC are > seriously numbered. Yeah, but that number is not yet zero... > Again, I assume you must have missed that class on the history of computing? And, I assume you enjoy being a condescending, sarcastic know-it-all? It's all well and good to talk about ancient languages which no modern programmer actually USES for anything anymore... But, lots of people actually USE and KNOW C, unlike Ada or FORTH... (Yeah, yeah, I'm sure you and a couple other people here know them both intimately... I'm glad for you... But, please don't try to pretend they have anything like the mindshare of C...) > An engineer uses the best tool for the job. If you using a tool because > you like it, against any argument that it's not the right tool for a > job, you're a hobbyist, not a serious professional. Wow, that was EXACTLY my entire point from the beginning of this thread! You have just restated my entire thesis in two succinct sentences... Using the best tool for the job necessarily requires considering all the options and knowing how they all work, so that you can make an informed decision as to which tool truly is the best for any given situation... The outright, blind, dogmatic rejection of certain tools (strcpy(), sprintf(), etc.) is counter to that goal, and is doing precisely what you claim is not something a "serious professional" should do... Thank you for finally agreeing with me... ;-)
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 17:43 UTC (Thu) by dvdeug (subscriber, #10998) [Link] I believe that programmers get paid big bucks because they are well-trained already. If they were more well-trained, then they would have to get paid even bigger bucks. Which is going to cost everyone who employs programmers, and in the end everyone uses computers. So, yes, at some level, I am opposed to more training for programmers. Nor do I think that more training is always the solution. Do you think that the programmers of Samba are untrained? > My god, you DO so love attacking straw-men, don't you? Is this coming from the person who asked me about writing a kernel in Java and Python? > And, "in reality", how many of those are actually USED for any real > work, and not just as teaching tools or demos? I don't know; is VMS just a teaching tool? What about OS/360? > It's all well and good to talk about ancient languages which > no modern programmer actually USES for anything anymore. It's easy to describe C as the best language, if you can make up ad hoc reasons to exclude any competitors. Actually, Ada has a well-maintained GCC frontend, and the standard was last updated with new features in 2005. > But, please don't try to pretend they have anything like > the mindshare of C. So now the only real languages are the ones that have the mindshare of C? > > If you using a tool because > > you like it, against any argument that it's not the right tool for a > > job, you're a hobbyist, not a serious professional. > Wow, that was EXACTLY my entire point from the beginning of this thread! Like when you said you should use C because > Suppose you simply like C, consider it elegant and beautiful, ? That's not a professional's attitude. > The outright, blind, dogmatic rejection of certain tools > (strcpy(), sprintf(), etc.) is counter to that goal, What goal? Writing good software maintainable by real programmers? Writing software that can be easily checked for certain bugs whose warning signs are the use of those functions? Or writing code that might cause millions of dollars to be lost due to a security hole, which just shows that the programmer wasn't experienced enough?
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 18:12 UTC (Thu) by nix (subscriber, #2304) [Link] Ah, but you see, if everyone was well-trained and thus their code had no bugs, there'd be no problems with a language like C with major built-in trapdoors and the trapdoors would be harmless and we could build a Great Underground Empire connecting the trapdoors. I had a boss like that once, who thought that the solution to writing bug-free code was for everyone to introduce fewer bugs every week, so that in the end we would introduce no bugs at all. This strategy works excellently if you never have off days, never get out on the wrong side of the bed, never have to maintain an existing body of buggy code, have a perfect memory, and live in the Transcend. For the rest of us it is useful to try to find tools that reduce the probability of bug introduction as well as to improve so that we introduce fewer. (I like C and I use it all the time, but still the facts remain the same: bugs in C *do* often lead to security holes, and people *are* human and *do* introduce bugs.)
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 18:52 UTC (Thu) by RobSeace (subscriber, #4435) [Link] > For the rest of us it is useful to try to find tools that reduce the > probability of bug introduction as well as to improve so that we introduce > fewer. And, I've done nothing but agree with that sentiment... I'm merely saying that in your search for tools, make sure you truly consider all your options, instead of just dogmatically rejecting some when you don't understand WHY (which is what blanket prohibitions do)... A sane person WILL generally choose snprintf() over sprintf() in most situations... But, they should understand WHY, and recognize the cases when it's perfectly fine to use sprintf() instead (though, they still may not choose to for other reasons, which is fine too)...
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 19:32 UTC (Thu) by nix (subscriber, #2304) [Link] I generally assume all such blanket prohibitions to come with a `this is only a guideline, follow it unless you're damn sure you know why not to'. This isn't the law, after all: not following a coding style guideline isn't a crime.
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 19:40 UTC (Thu) by RobSeace (subscriber, #4435) [Link] > I generally assume all such blanket prohibitions to come with a `this is > only a guideline, follow it unless you're damn sure you know why not to'. Well, if that's the case, then I have absolutely no problem with it... Pointing out potentially dangerous functions and discouraging general/widespread use of them is perfectly reasonable, just as discouraging widespread use of gotos is perfectly reasonable... I was only ever arguing about flat-out total rejections of such things, which DO sometimes occassionally have perfectly reasonable uses... > This isn't the law, after all: not following a coding style guideline > isn't a crime. No, but if it led to flat-out rejection of any code containing such things, without even examining the uses for validity, I'd think that was wrong... Of course, they're perfectly within their rights to reject any code they like, but I'm just saying it may not be the best idea in the world, because the use of such things may not ALWAYS be an indicator of horrible code... An indicator you should look closer and see, sure...
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 30, 2007 15:36 UTC (Fri) by dvdeug (subscriber, #10998) [Link] Actually, in Samba's case, I believe the functions are poisoned, so the compiler won't compile with those functions in the code. It's the most reliable way of enforcing a coding standard.
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 18:23 UTC (Thu) by RobSeace (subscriber, #4435) [Link] > I believe that programmers get paid big bucks because they are well-trained already. Hah! If only... (To both parts! ;-)) During the dot-com days, there was an influx of "programmers" who didn't know a thing about actual programming, but were just there to make money... Lots of them still exist, sadly... Then, there are the lowest-bidder outsource coding shops, who don't care a bit about the quality of code they write, only getting it out the door as quickly as possible... SOME programmers are indeed well-trained already; but, to think ALL of them are is kind of delusional... > Do you think that the programmers of Samba are untrained? I know nothing of their background, so I'm not really qualified to comment... But, no, I highly doubt most of them are untrained... But, at the same time, I kind of doubt most of them are making such coding mistakes all the time, either... If you accept code from random people (and, I'm not trying to say that's a BAD thing), some of them are likely to be less skilled/experienced and make more junior mistakes... > Is this coming from the person who asked me about writing a kernel in > Java and Python? That was simple sarcastic snark to your "debatable" comment... ;-) I wasn't making up a weak argument, putting it in your mouth, and attacking it... If I were, I would've said, "So, your solution is to write all kernels in Java and Python from now on. Great solution!"... See the difference? > So now the only real languages are the ones that have the mindshare of C? When did we get into a discussion of what constitutes a "real language"?? I was discussing realistic choices of languages to use in creating real-world software... Just because language X is indeed a real language, and may in fact be the greatest one ever created, doesn't mean you'll be able to find any programmers in the real world who know how to write code in it, or who WANT to... > Like when you said you should use C because I was proposing a series of hypothetical situations in which one might choose to use C, to counter your silly assertion that the ONLY possible reason one might have to use it is "premature optimization"... I wasn't stating it as a personal opinion or proposing it as a reason anyone else "should use C"... (There you go again, putting words in my mouth...) Even an irrational reason is a reason... And, clearly demonstrates your claim of no other possible reason existing false... > What goal? What goal? The one we were discussing at the time: the goal of choosing the best tool for the job...
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 18:44 UTC (Thu) by dvdeug (subscriber, #10998) [Link] I see the difference; with enough ellipses and smilies, sarcasm becomes a great tool for serious discussion. I also see that it's good to take everything the other person says literally and feel free to make absurdly hyperbolic. Refusing to write using standard English conventions means that you privilege your ease of writing the message over your desire to communicate with the other person. That's a bad sign for a discussion.
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 19:00 UTC (Thu) by RobSeace (subscriber, #4435) [Link] > Refusing to write using standard English conventions means that you > privilege your ease of writing the message over your desire to communicate > with the other person. That's a bad sign for a discussion. WTF?? Where did that comment come from? I think any English-speaking person can very clearly understand me... I don't think a few elipses renders text incomprehensible... If it does, you must have trouble handling most writing on the Net... And, smileys are standard and desirable features of Internet communication, the last time I checked (and, I've been communicating on it without complaint for quite a very long time)... But, I guess it's easier to just resort to ad hominem attacks than engage in rational debate...
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 19:30 UTC (Thu) by nix (subscriber, #2304) [Link] Massive use of ellipses renders text *much harder to read* than it otherwise would be, which means that a lot of people will skip what you write, presuppose what you write to be rubbish, and so on. (I know this from experience: my handwriting is so nearly unreadable that when I moved from school to university and was allowed to use wordprocessing and typesetting tools instead of handwriting, my average marks rose by 40%+, and that's for stuff which is less subjective than `will people think I'm not worth reading just because of the way I write'. You're torpedoing your own arguments before you even make them.)
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 19:56 UTC (Thu) by RobSeace (subscriber, #4435) [Link] > Massive use of ellipses renders text *much harder to read* than it > otherwise would be, I'm not sure I understand WHY... I've been writing this way (online) for nearly 20 years now, and this thread is really the first time I can ever recall anyone complaining about it... I write this way in work E-mails, in personal E-mails, on forums, etc... No one ever seemed to have a problem with it... I once had someone go beserk on me because I used to hit RETURN at the end of each line in forums, instead of letting it wrap... (I've semi-broken that habit, but still do it some places... Always in E-mail, at least...) But, never because of my elipses abuse... (And, I do admittedly abuse the poor things! ;-)) In fact, by regular communication with them, I've unconsciously gotten a few other people to start doing the same thing in all their messages (not just to ME, either) now... I guess I'm a corrupting influence... ;-) But, as corruptions of the English language go, I consider my crime pretty minor compared with the usual examples you find from most other people online (especially these days)... But, I certainly do apologize if you have trouble reading it... I certainly didn't intend it to be hard to read...
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 19:30 UTC (Thu) by dvdeug (subscriber, #10998) [Link] I didn't saying anything about whether English-speaking people can understand you, or about whether the extensive use of ellipses renders the text incomprehensible. But it is easier to read text that uses the standard English conventions, and polite and wise to write text that is easy for your audience to read. I have found that people who don't bother to follow standard English conventions, like punctuation, capitalization and spelling don't tend to be the people who write the most insightful and interesting statements, and that the people with reasonable insightful responses tend to be in standard English orthography. I think the rational debate on this thread is about over. Neither of us is very calm, you're making claims that everything I said is a straw-man, and I'm feeling that you're making hyperbolic statements and interpreting everything I say incredibly literally.
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 22:07 UTC (Thu) by i3839 (subscriber, #31386) [Link] I'm biassed, but to me this was never a rational debate, simply because most people, including you, neglected to use valid logical argumentation. The C programming language is just a tool, as is sprintf/snprintf. How you can blame the tool for its wielder's mistakes is beyond me. The hate against C seems to be running deep in some people. How this turned into a debate about ellipses is very interesting, and a nice methaphore for this whole thing: It's not about the details of how you write something, but what you write. (Yes, which programming language you use is a minor detail of the whole. So stuff it up you fanatical language freaks.)
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 22:22 UTC (Thu) by dvdeug (subscriber, #10998) [Link] As I mentioned above, Radithor, a water "medicine" infused with radium, was taken off the market after it killed someone. Why isn't that just a tool, that shouldn't have been blamed for one person overusing it? Our society is filled with examples of this; the government regulates all sorts of things so that they aren't dangerous in normal use, even if the person doesn't use it exactly as per the instructions. > It's not about the details of how you write something, but what you write. r34lly? y0u 4ctu4lly r34d th15, ju5t l1k3 y0u w0uld r34d 4nyth1ng 3l53? HOW IT"Z WR1TTEN DOESNT CHANGE ANYTH1NG 4 U???? You vould r-r-read mein normal posts if dey vere all like dis? I dink not.
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 22:52 UTC (Thu) by RobSeace (subscriber, #4435) [Link] > Our society is filled with examples of this; the government regulates all > sorts of things so that they aren't dangerous in normal use, even if the > person doesn't use it exactly as per the instructions. Yes, but you seem to imply that that is a GOOD thing... I would disagree, in most cases... I'm a pretty big fan of personal responsibility... I'm not saying sell razor-wire and napalm as child toys; I'm saying if you buy a product which is very obviously and clearly dangerous (especially if documented as so), then you should be responsible for misuse of it, not the manufacturer/seller... Simply forbidding sale of it (or castrating it somehow to make it "safe") is generally a bad idea with most things, because there's usually some legit/safe use of it as it is, so it's kind like cutting off your nose to spite your face, as they say... (Or, perhaps more aptly, cutting off your legs to prevent any falling accidents...) If it can be modified in such a way as to be safe yet still just as useful and usable as it was, then great... But, it's rarely the case, as safety measures tend to carry SOME kind of overhead, most of the time... (Though, why on Earth anyone should really want to drink radium-laced water, I have no idea... But, if they really want to, and are informed of the dangers, then I say let them... *shrug*) Oh, and do you honestly find the mere presense of 2 extra periods at the end of each sentence equivalently annoying and obfuscated as leet-speak?? If so, I'm very sorry... (Not enough to stop, just for you, however... ;-))
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 30, 2007 13:39 UTC (Fri) by i3839 (subscriber, #31386) [Link] Tell me, in what way is Radithor a tool? A scalpel is a tool, a potential dangerous one too I might add. Cars are very dangerous in normal use, killing thousands of people each year, and nothing is done about it. But as you said, other ridiculous things are regulated. Clearly it's more about politics and what the masses feel than what makes sense, so I don't think using it as an argument for anything is convincing in any way. I'm afraid you'd need to think something of your own. Yes, I actually read what you wrote. Yes, like I'd read everything else. Perhaps because I'm curious about what people think and have to tell? How it's written doesn't change the content at all, at worst it only makes you look like an idiot, which causes me to develop a certain bias, which might influence how I react to what you write. But if you write sensible thing in that pseudogerman or whatever it's supposed to be, yes I'd read it all. I'd assume that you had a reason to write in such way though. English isn't my native language, so perhaps I'm more tolerant for strange variants (like American ;-).
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 30, 2007 15:28 UTC (Fri) by dvdeug (subscriber, #10998) [Link] Cars are very dangerous in normal use, which is why a lot is done about it. Anti-lock brakes, steel roll-cages, minimal standards on bumpers, seat belts, shoulder belts, rear shoulder belts, air bags, passenger-side airbags, side-impact airbags, and numerous less-visible changes. Two cars from every new model are destroyed in crash tests.
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 30, 2007 16:31 UTC (Fri) by i3839 (subscriber, #31386) [Link] It aren't the drivers that are killed most of the time, I'm talking about people outside the car: pedestrians and cyclists mostly. And besides all those counter measurements even car drivers still die. Judging how lots of other things are handled cars should have been forbidden by now, to name one thing. The original point was that what the government regulates and what not, and how, isn't in any way a valid argument, because it lacks rationale. Missing the mark again...
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 30, 2007 16:50 UTC (Fri) by dvdeug (subscriber, #10998) [Link] > It aren't the drivers that are killed most of the time, > I'm talking about people outside the car: > pedestrians and cyclists mostly. http://www.car-accidents.com/pages/fatal-accident-statist... shows that in the US, roughly 85% of the people killed in car accidents were in cars, and more than half were drivers. > The original point was that what the government regulates and > what not, and how, isn't in any way a valid argument, because > it lacks rationale. Of course it lacks rationale, given that politicians were handed their positions on a silver platter and aren't accountable to anyone. Not only, they're lobotomized before the job, and have to use a Magic-8 ball to make decisions. Of course it has rationale. Apparently not one you agree with, but politicians justify everyone one of their decisions to their coworkers, to the lobbyists and to members of the public. It's not perfect, it's not inarguable, but it's there. I guess you started this argument by saying that anyone who disagreed with you wasn't rational, so I guess expecting you to acknowledge that anyone else might have reasons for what they do is too much to ask.
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 30, 2007 17:46 UTC (Fri) by RobSeace (subscriber, #4435) [Link] > Of course it lacks rationale, given that politicians were handed their > positions on a silver platter and aren't accountable to anyone. Not only, > they're lobotomized before the job, and have to use a Magic-8 ball to make > decisions. So, THAT'S how they do it? I always wondered... I mean, the lobotomies were obvious, but I had no idea about the Magic 8-Balls! ;-) > but politicians justify everyone one of their decisions to their coworkers, > to the lobbyists and to members of the public. Um, in which country does this happen?? Certainly not the USA, I'm sure of that much... Here, the politicians generally vote for whatever measures are pushed by the companies or lobbying groups giving them the most money... Or, during election times, whatever makes them look the most favorable to their voting demographic... Hell, most of the time, they don't even READ the bills they're voting on! And, any justifications given are no more than superficial BS, in general... (No, this doesn't describe ALL politicians... Only about 99% of them... ;-/)
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 30, 2007 18:04 UTC (Fri) by i3839 (subscriber, #31386) [Link] I wasn't talking about the USA either, but it seems it's much worse than I thought, 43,000 deaths a year. I looked it up, and here it's about 50/50 between car inhabitants and others dying, so you were right that I underestimated the ration. You don't seem to know the meaning of the word "rationale". Having a reason isn't enough, sorry. First, I didn't start this discussion, I hopped into it. Second, it's not about disagreement, it would be jolly boring if we'd agreed. It's about reason (different meaning!) and ratio, or the lack thereof. If there was a toy that killed 43,000 people a year it would be prohibited immediately, without questioning. If terrorists killed 43,000 people a year, the world would be too small, the counter measurements even more draconian than they currently are. But it are just cars, so then it's ignored. (before you get ideas, no, I'm not saying that cars should be prohibited too, just pointing out a big inconsistency.) You may paint your cat blue because it's raining today. That's not a good rationale. It's not that I disagree with the reason (it is raining after all), it's that the reasoning is crap. If you don't get this I give up on you, if you don't mind.
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 30, 2007 18:37 UTC (Fri) by dvdeug (subscriber, #10998) [Link] rationale: An explanation or exposition of the principles of some opinion, action, hypothesis, phenomenon, or the like. Webster 1913. Having a reason is good enough. If you banned cars in the US, very few people would have been able to escape Hurricane Katrina; the death toll in New Orleans would have been in hundreds of thousands if people couldn't drive off. To replace cars in the US would take billions--possibly trillions--of dollars in public transit that would take years, maybe decades, to create. They don't ignore the death toll; they constantly require new safety features, they make laws requiring the use of seat belts, and test and study. You demand an unreasonable standard of not ignoring.
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 30, 2007 20:54 UTC (Fri) by i3839 (subscriber, #31386) [Link] I give up.
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 16:38 UTC (Thu) by nix (subscriber, #2304) [Link] Last week I rewrote a small chunk of a financial app that wrapped around Oracle's in-database XSLT translator (based on an ancient version of Xalan-J, I think, but it's hard to find out) to use libxslt instead. Because libxslt is C, and Oracle's translator is Java, this meant a complete rewrite of the wrapper and the code that called it. That change alone gave us a speedup of a *minimum* of 50x, not because of my code, but because of the efficiency (or lack of it) of the code I was wrapping (and the astonishing inefficiency of Oracle's Java-in-DB implementation). Not all optimization is premature, and not everything can be rewritten in other languages. (I mean, yes, I probably could have written a more efficient XSLT translator, but that would have been ridiculous given that libxslt was already there.)
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 11:07 UTC (Thu) by ekj (subscriber, #1524) [Link] But, seriously, how do you think we end up with highly-trained expert programmers if not by them learning from long experience? The amount of experience the average programmer has will neither increase nor decrease if we disallow gets(), or use python, so I don't see how this is relevant. Unless you think that only experience with gets() and C is helpful. The thing is, some people just don't WANT to learn, and don't care about safety True. Some of these people are even programmers, working on your project. Which is -one- of the many reasons safe defaults make sense. Many more people truly genuinely wants to write the best possible code they can, but are nevertheless unable to avoid introducing memory-leaks, buffer-overflows and various other impossible-in-other-languages or unlikely-in-other-languages bugs regularily. Any "solution" that has as step 1: 'Make sure everyone is an expert.' Or step 1: 'Make sure nobody makes mistakes' is anything but.
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 12:00 UTC (Thu) by RobSeace (subscriber, #4435) [Link] > The amount of experience the average programmer has will neither increase > nor decrease if we disallow gets(), or use python, so I don't see how this > is relevant. Unless you think that only experience with gets() and C is helpful. gets()?? Who here was defending gets()?? That's the ONE function everyone seems to agree upon (including myself) that it's really just totally broken and should truly NEVER be used... But, ignoring the gets() straw-man, yes I do think experience with C (and all its dangerous functions, including enough to at least understand why gets() is a horrible function and should probably always be avoided) is certainly useful... If you want to be a C programmer! If you want to use something else, more power to you... But, if you want to write C code, you should indeed understand it... I don't think that's such a radical idea, really... I'm not sure what is so upsetting to people... > Any "solution" that has as step 1: 'Make sure everyone is an expert.' > Or step 1: 'Make sure nobody makes mistakes' is anything but. Well, then, thank K&R I see no one selling such a "solution" here... Seriously, is this Attack a Straw-Man Day, or what?? My step one: Use your brain in choosing your language and the library functions you use in your code, and make sure you understand how they really work... If you can't handle C, then fine use something else... If you need to write C for some reason or other, then fine, take the time to learn how to do so properly... Failure to do that does not equate to a failure of the language or the library functions (assuming they're behaving as they're designed to and not truly buggy themselves, anyway), but to your own failure... No, I don't expect everyone to become expert C coders; but, I also don't expect those people to be shipping production C code they've cobbled together, either! No, I don't expect everyone to become superhuman and error-free; but, I expect experienced programmers to learn from their past mistakes, and be less likely to make them again, as time goes on...
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 17:54 UTC (Thu) by dvdeug (subscriber, #10998) [Link] > But, if you want to write C code, you > should indeed understand it... I don't think that's such a radical idea, > really... It's not, until you combine it with criticism of anyone who encourages the use of other languages.
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 18:01 UTC (Thu) by RobSeace (subscriber, #4435) [Link] > It's not, until you combine it with criticism of anyone who encourages the > use of other languages. And, where exactly did I do that? I've repeatedly said that if you don't think you can handle C, then you should certainly use some other language... The only thing I've objected to is the notion that NO ONE should ever use C... (Or, as the thread originally started with, no one should ever use so-called "dangerous" functions for any reason at all, even when such use is clearly and obviously NOT dangerous in any way...)
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 10:52 UTC (Thu) by ekj (subscriber, #1524) [Link] The question isn't if the burden is "undue", the question is if the added burden is worth it -- if the benefits more than outweigh the disadvantages. Now, you can blabber all days about how it is /possible/ to use all features of C safely. That is however of limited value when literally decades of experience from the real world shows that most programmers don't manage that even most of the time, and even elite programmers don't manage it all of the time. Yes, there's -tons- of mistakes one can make even in saner languages, and people do. But those mistakes tend to be possible in C too, so it's sort of a non-argument. Fixing buffer-overflow is still worth it even if people will still suffer sql-injection. Your analogy is silly. Offcourse you'd prefer sharing the road with good drivers rather than bad, but improving the cars don't magically the drivers worse, so the choice is a false one. It's more like, would you rather share the road with average drivers driving cars that are as safe and forgiving of error as possible, or would you like to share the same road with the same drivers, but with cars lacking these safety and forgiveness-features. I'm pretty much of equal skill as a C-programmer and a python-programmer. It's safer to "share the road" with a program I've written in python than with one I've written in C. The mistakes I can make in python are -all- possible in C too, and in addition there are large and common cases of bugs that just can't happen in python. And to top it off, any mistake in C tends to be the equivalent of "can run arbitrary code" kinda thing. In Python many (NOT ALL) mistakes blow up safely with an exception. Unexpected exceptions aren't good. They're a lot better than arbitrary-code-execution though.
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 12:18 UTC (Thu) by RobSeace (subscriber, #4435) [Link] > It's more like, would you rather share the road with average drivers > driving cars that are as safe and forgiving of error as possible, or would > you like to share the same road with the same drivers, but with cars > lacking these safety and forgiveness-features. What's wrong with having people of different skills and abilities driving different cars with different sets of safety equipment? Or, to try to steer back away from the silly car analogies, what's wrong with some programmers writing in supposedly "safe" languages, and others who have more experience and skill in supposedly "dangerous" ones? Or, having some using "safe" functions, and others who can handle doing so safely using "dangerous" ones when they feel it is necessary/useful to do so? I don't see why we need any One True Language or One True Set of Lib Functions which everyone must use... Because, the "average driver" (damn, back to the car analogy! ;-)) you mention is merely a figment of statistics and doesn't actually exist... In reality, there are widely differing skill and experience levels of driver all sharing the road... So, catering to some mythical "average driver" with a one-size-fits-all car and set of safety features is likely to just annoy and displease most of the REAL drivers that have to use it, either because it's too dumbed-down and hand-holding or still not enough for the ones dragging down that average... > And to top it off, any mistake in C tends to be the equivalent of "can > run arbitrary code" kinda thing. ANY mistake? I think that's stretching things quite a bit... But, yeah, many memory-handling bugs are very serious... But, you know, there exist libraries on top of C which take away most of the low-level complexity of dealing with memory allocation and such, nearly eliminating such problems in the same way as alternate languages, too... So, why don't people just use those, if that's the level of safety they want and need to code in C for some reason? But, if they choose to use the low-level tools, and fail to take the time to learn how to use them properly, or fail to excercise proper care when using them, then the fault lies on them, not the tools...
Insecurity Blues: Jeremy Allison reflects on Samba security flaws Posted Nov 29, 2007 12:58 UTC (Thu) by i3839 (subscriber, #31386) [Link] Sigh, there we go again. Buffer overflows aren't as bad as they seem, but are treated very seriously because they might be exploitable. In practice they aren't much worse than an unexpected exception crashing the app. Things that make buffer overflows very hard to exploit in reality: - Address space layout randomization - Non-executable stack/heap. And if you want to have more security for a small cost, just compile the programs with gcc's -fstack-protection option. glibc also has some security measures to prevent jump-into-libc attacks. Can we please move on to higher level bugs causing exploits? Or even integer overflows. Please?
|
|
||||||||||||