Insecurity Blues: Jeremy Allison reflects on Samba security flaws [LWN.net]

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

Posted Nov 27, 2007 18:03 UTC (Tue) by nix (subscriber, #2304) [Link]

Yeah, but improper sprintf() usage is known to cause vast problems *every damn time*, pretty
much, unless the code around it is carefully written.

Improper snprintf() usage --- well, you *can* parlay truncated output into an exploit
sometimes (and a DoS more often), but it's a hell of a lot harder than parlaying a buffer
overrun into an exploit.

All functions with any limits are risky if used without consideration of those limits: the
question is whether exceeding the limit invokes undefined known-to-be-insecure behaviour, or
whether like snprintf() its behaviour in those circumstances is defined and consistent.

I prefer defined and consistent behaviour out of my systems, thanks.

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

Posted Nov 27, 2007 19:21 UTC (Tue) by RobSeace (subscriber, #4435) [Link]

> Yeah, but improper sprintf() usage is known to cause vast problems *every damn time*, pretty
> much, unless the code around it is carefully written.

Well, yeah, but improper usage of ANY function is a bad idea anyway...  For every sprintf()
catastrophe you can imagine, I can dream up one just as bad for snprintf(), too...  Harder to
mistakenly code, perhaps...  But, not necessarily even...  It's not just undesired truncation
to worry about...  If they pass in a too-large buffer length, it's just as bad as sprintf() at
that point...  (It's not always possible to use sizeof(buffer); eg., dynamically allocated
strings...)  It's also concievable one might use the return value as a count of how many bytes
are in the buffer for later memcpy() or whatever purposes, in which case failure to check for
a retval > buffer size will likely cause equally bad problems...

Look, I'm not saying don't use snprintf()...  I use it and indeed think it (or asprintf(),
even better) should probably be used in MOST cases instead of sprintf()...  But, I'd never say
one should NEVER use sprintf(), either...  I'm just saying, use the right tool for the job,
and THINK about what is appropriate to use in any given situation, rather than just
unthinkingly and dogmatically choosing a "safe" function over an "unsafe" one...

> All functions with any limits are risky if used without consideration of those limits

Exactly...

> the question is whether exceeding the limit invokes undefined known-to-be-insecure
> behaviour, or whether like snprintf() its behaviour in those circumstances is
> defined and consistent.

Again, you're only considering the unexpected truncation case, NOT the case of passing in an
incorrect buffer length, or misusing the return value (which can legitimately exceed the
buffer length)...  In those cases, you're back into "undefined known-to-be-insecure"
behavior...  And, by people thinking snprintf() is always safe, they're less likely to spot
such improper uses, too...

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

Posted Nov 27, 2007 20:19 UTC (Tue) by rmstar (guest, #3672) [Link]

If anything, this thread shows that in an ideal world, booby-trapped languages like C would be avoided. It provides just too many opportunities for the unwary (even if competent) programmer to make dangerous mistakes.

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

Posted Nov 27, 2007 21:34 UTC (Tue) by RobSeace (subscriber, #4435) [Link]

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...

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?

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

Posted Nov 28, 2007 14:35 UTC (Wed) by epa (subscriber, #39769) [Link]

There are C-derived languages like Cyclone which are just as fast for all practical purposes but safer. I'd also put in a word for C++ if it's used sensibly.

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

Posted Nov 29, 2007 3:00 UTC (Thu) by pynm0001 (subscriber, #18379) [Link]

Indeed, C++ can be very safe when people use the tools it gives you.  Of 
course, you could say the same about C (i.e. use glib only for strings), 
but C++ is nice in that exceptions and scoped destructors make it much 
easier to handle resources.

But then you have to buy into the mantra (i.e. always handle resources in 
a class that will destroy them on destruction).  C++ gets a bad rap as 
just being C with some OOP thrown in, but it's not a disaster waiting to 
happen.

It does take forever to compile though. :(