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

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

Posted Nov 27, 2007 11:46 UTC (Tue) by epa (subscriber, #39769) [Link]

There aren't many "insecure" functions, there are mostly bad programmers.

True, but most programmers are bad programmers. If your criterion for being a good programmer is that you can use unsafe functions like strcpy() safely, all the time, without making a single mistake, then few of us match. An insecure function is one that tends to produce exploitable bugs when used by most ordinary programmers, who are fallible. The X.org example is indeed silly and shows the wisdom of using a half-decent string manipulation library rather than the C standard library functions, which are both dangerous and inadequate.

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

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

> If your criterion for being a good programmer is that you can use unsafe
> functions like strcpy() safely, all the time, without making a single
> mistake, then few of us match.

But, I think the point is that strcpy() shouldn't be used ALL THE TIME, but only where it
makes sense to do so...  And, yes, there are perfectly legitimate cases where it's perfectly
sensible and safe to use strcpy(); and, being forced to use some alternate function in those
clearly safe and reasonable cases is going to help no one, and is NOT going to lead to safer
code...  It's going to lead to more obfuscated and ugly code, which in turn will be harder for
future programmers to deal with...

The point is: Use the right tool for the job...  There's no one set of "good" vs. "bad"
functions...  (With the previously-mentioned exception of gets(), which is clearly just
totally broken to the point of unusability...)  There may be a sliding scale of "easier to use
safely" vs. "harder to use safely", or "more general purpose" vs. "only useful for certain
rare cases"...  But, to outright prohibit a function like strcpy() in your code is simply
madness...  Instead of blind prohibition, why not actually look at how it's used and decide if
it's safe or not?  Yes, of course it's easier to just blindly prohibit it...  But, if you
think it's leading to safer code as a result, you're simply deluded...  It's leading your
aforementioned "bad programmers" to kluge around the prohibition by using your supposedly
"safe" functions in probably silly and unproductive (and possibly unsafe) ways...  And, if you
don't actually look at their code, you'll never know about it, and will go on blissfully
thinking you're all safe and secure now that you've eliminated all the "bad" functions...
It's just a really naive and short-sighted POV...

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

Posted Nov 27, 2007 16:01 UTC (Tue) by epa (subscriber, #39769) [Link]

Every rule has an exception, and there are cases where strcpy() is just what you want.  I'm no
fan of absolutist coding standards, or total bans on particular language features or standard
library routines.  But I was saying that many string handling routines in the C standard
library are insecure in the sense that any programmer who uses them regularly, and is not a
tenth level Zen guru ninja, will sooner or later introduce an exploitable bug.  Like many
other things, they should be used sparingly if at all.

I think I'd still incline to forbid naked use of strcpy() and other dangerous functions, but
have a macro called something like strcpy_yes_really_i_know_what_i_am_doing() for the rare
cases it makes sense.

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

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

> Like many other things, they should be used sparingly if at all.

And, that's a perfectly reasonable attitude toward things like strcpy(), sprintf(), etc...
But, it's also a far cry from saying NEVER use them, because they're ALWAYS "bad"...

I also think there's something to the line of thought that if you dumb down the language so
even idiots can safely use it, then you'll end up with mostly only idiots using it...
Personally, I'd prefer to encourage programmers to get smarter and better able to write good
code than to assume they're all morons incapable of doing anything without copious amounts of
hand-holding by their language and/or coding standards...  If someone screws up and uses a
function insecurely, then call them out on it, and hopefully they'll learn not to do that and
how to do things safely in the future...  And, hopefully they'll learn WHY what they did was
insecure, not merely take away some blanket "this function is always dangerous and should
never be used" mindset...  But, maybe the next time they use that function, they'll stop for a
second and THINK about how they're using it, and whether or not it's really safe usage; and,
hopefully, might start to do that same thing with other functions as well...  That would be a
good thing, and would make them better programmers...  It's far better than having them just
mindlessly switch to using some supposedly "safe" replacement function instead...  That
doesn't improve them as programmers at all...

> I think I'd still incline to forbid naked use of strcpy() and other dangerous functions,

"There's no such thing as dangerous functions; only dangerous programmers." ;-)  Or, should
that be, "strcpy() doesn't kill people; programmers kill people"? ;-)

> but have a macro called something like strcpy_yes_really_i_know_what_i_am_doing()
> for the rare cases it makes sense.

Well, then you might still get "bad programmers" who THINK they know what they're doing still
using it incorrectly...  The only sensible approach is to simply audit the code, if you don't
trust the person who wrote it to really know what they're doing...  Yes, that may often be
infeasable, but anything else is just a band-aid feel-good measure, which does nothing to
truly improve security...

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

Posted Nov 27, 2007 17:03 UTC (Tue) by epa (subscriber, #39769) [Link]

If someone screws up and uses a function insecurely, then call them out on it, and hopefully they'll learn not to do that and how to do things safely in the future...

Of course, but what if in the meantime the insecure code has made it into a release? If your goal is to avoid security holes, then you can't rely on programmers learning from their mistakes; some mistakes can be very expensive. Of course you need to audit the code. If you choose to help yourself do the audit by writing automated tools that warn about use of strcpy() etc., then good for you. As the project maintainer you always have the option of turning off the automated check if you think it's too strict in any particular case - it sounds like the Samba developers have not needed to do that, because in their opinion there are always safer alternatives.

I don't think anyone is saying that a given function should NEVER be used (except maybe gets()), just that for the particular requirements of the Samba project they have found it worthwhile to eliminate all use of some functions.

I also think there's something to the line of thought that if you dumb down the language so even idiots can safely use it, then you'll end up with mostly only idiots using it...

Not idiots, just normal intelligent programmers who nonetheless make mistakes. Which is all of us. We need to make sure that when we make mistakes, the consequences are limited as far as possible. And even expert programmers benefit from not having to waste brainpower on worrying about whether a particular sprintf() call might or might not overflow - much better to use a more idiot-proof interface like snprintf() (which is still not perfect, of course) and spend your time doing something more productive. Computers are meant to do the dull drudge work for us.

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

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

> If your goal is to avoid security holes, then you can't rely on programmers
> learning from their mistakes; some mistakes can be very expensive.

I'd say if your goal is to completely avoid security holes, it's a very noble but naive
goal...  You're unlikely to ever achieve it...  As long as humans are still writing the code,
at least, there are always going to be mistakes made occassionally...

But, I think it's a better idea to encourage learning and improvement in the programmers than
it is to encourage laziness and blind faith in "safe" functions...  In the end, you'll end up
with better code due to better programmers...

> If you choose to help yourself do the audit by writing automated tools that
> warn about use of strcpy() etc., then good for you.

Yeah, I have no problem with that...  Considering some functions POTENTIALLY dangerous and
examining uses of them is a good thing...  Idealy, you might consider ALL functions
potentially dangerous, and so examine all new code closely...  But, in reality that's not
always practical, so yeah, this approach is at least a reasonable second-best...  But, again,
that's a very different approach than outright forbidding those functions in all cases, too...

> Not idiots, just normal intelligent programmers who nonetheless make
> mistakes. Which is all of us.

Right, we all make mistakes...  But, the difference is an experienced/good programmer is
unlikely to make the SAME kind of mistakes as an inexperienced/bad programmer...  The
experienced programmer will be aware that strcpy()/sprintf()/whatever is potentially
dangerous, and hopefully will be a bit cautious in its use, whereas the inexperienced one
might not even have a clue about what sort of problems incorrect use of the functions might
cause...  Or, alternatively, the inexperienced programmer may have been told that the
functions are unsafe, and so simply avoids them religiously, still without knowing WHY or
understanding the actual problem, and so ends up misusing the supposedly "safe" replacement
functions, instead...  (Which no one can now catch with their automated "grep for bad
functions" audit technique, either...)  Yes, we all have our brain-fart moments and totally
mess up something which we know better than to do, but that's just something that's always
going to happen no matter what, as long as we're human...  It doesn't matter if we are using
supposedly "safe" functions or supposedly "dangerous" ones; they can both be misused and
become unsafe in reality...

> much better to use a more idiot-proof interface like snprintf() (which
> is still not perfect, of course)

But, that's just the problem: it's NOT really "idiot-proof" (nor could such a thing ever
really exist, and have it still be usable for any useful programming, I doubt)...  And, the
problem is people start to think it really IS, and so get lax and careless about using it...
If you give someone a gun, would you prefer they get one without a safety but be fully informed
of its potential danger and be fully trained at handling it, or would you prefer they be given
one with a safety but be untrained at proper handling of it yet think there's no problem
because it's "safe"?  I know which one I'd choose to stand next to... ;-)  Of course, maybe
the best case scenario is one with a safety, but with a trained handler who still knows it's
potentially dangerous...  But, I don't generally see that kind of mindset in people who
recommend rote function replacement; they seem to believe in simple, black-and-white,
"function A is bad, function B is good, and if we always use B we'll always be safe"...
That's just a false sense of security and encourages laziness and sloppiness, IMHO...

> Computers are meant to do the dull drudge work for us.

Perhaps people who see using libc functions properly as dull drudge work might be happier and
more productive using a language other than C... ;-)  I love C programming, but I'll readily
admit it's not for everyone and isn't best suited to all uses...  But, if you're going to
write C code, I don't think it's too much to ask that you actually understand how to properly
and safely use the functions and language features you choose to use...

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

Posted Nov 27, 2007 18:53 UTC (Tue) by mrfredsmoothie (subscriber, #3100) [Link]

I'd say if your goal is to completely avoid security holes, it's a very noble but naive goal... You're unlikely to ever achieve it... But, I think it's a better idea to encourage learning and improvement in the programmers than it is to encourage laziness and blind faith in "safe" functions...

Which is in itself a noble goal, and in some environments (yes, I'm calling you out, corporate, commercial software managers!) just as naive.

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

Posted Nov 28, 2007 7:43 UTC (Wed) by man_ls (subscriber, #15091) [Link]

I don't think anyone is saying that a given function should NEVER be used (except maybe gets()), just that for the particular requirements of the Samba project they have found it worthwhile to eliminate all use of some functions.

Well, that is exactly what Allison is saying: some functions are better left alone. In all circumstances. It is so much trouble using them right that you are better off with the alternatives.

I think it is a worthwhile effort. RobSeace and others may argue for better programmers and years of improvement, but I think it leads to an over-specialized caste of programmers who take a long time to learn how to program anything (and who seldom take their noses up from their keyboards).

Meanwhile, the world (and not only corporate programmers) is moving in the opposite direction all the time. Many of us learned programming BASIC on our 8-bit machines, which produced perfectly good code in little time. Nowadays you have many safe languages where people can be proficient in a few months, without leaving gaping security holes all the time. It would be nice if people could code C confidently from the start, and not walk a minefield all the time. They might employ their neurons in useful knowledge, instead of "how to use strcpy() safely" or "which strXcpy() variant suits each occasion".

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

Posted Nov 29, 2007 2:01 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link]

Nowadays you have many safe languages where people can be proficient in a few months, without leaving gaping security holes all the time.

If only that were true. Those "safe" languages close off some avenues of attack, but they leave plenty of others open. Just as an example, there are tons of XSS and SQL injection attacks against programs written in those languages. And that's not to mention that those safe languages are usually written in low-level languages, so you can have serious problems if there are security problems in the language implementation itself. This isn't a theoretical problem, either; there are security advisories for Perl, PHP5, Java, and Ruby currently on the LWN security page.

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

Posted Nov 29, 2007 12:34 UTC (Thu) by epa (subscriber, #39769) [Link]

Those "safe" languages close off some avenues of attack, but they leave plenty of others open. Just as an example, there are tons of XSS and SQL injection attacks against programs written in those languages.

Note that these attacks too can be dealt with by having appropriate language support and type checking. For example, the output function which prints some text to the web page could take not a string but an HTML_string. Attempts to concatenate an ordinary string and an HTML_string would fail with a type error; an explicit HTML_quote function would take a string and quote unsafe characters returning an HTML_string. Then HTML injection attacks, which are caused by treating an ordinary string as HTML code when in fact it can have arbitrary user-supplied content, would mostly be eliminated.

Perl's taint checking does something like this, although it's not very flexible.

I don't mean to say that all security holes can be eliminated with language support, just to point out that we can make things a lot better if there is the will to do so. But it's so much more convenient just to say print "<h1>Hello $name</h1>"... languages need syntactic sugar to make the pill easier to swallow. Perhaps a syntax for safe string interpolation where every interpolated string is automatically HTML-quoted.

Insecure programming

Posted Nov 29, 2007 20:24 UTC (Thu) by man_ls (subscriber, #15091) [Link]

Well, a few security concerns is better than a lot of security concerns. You still have to be concerned with untrusted input or privilege separation. Still, there is nowhere near the ridiculous amount of security holes in C programs.

Some problems are harder than others. If I can choose I tend to prefer the simpler problems.

Insecure programming

Posted Nov 29, 2007 21:52 UTC (Thu) by i3839 (subscriber, #31386) [Link]

Like handling OOM because of the bloatware that snacked all free memory. ;-)

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

Posted Nov 28, 2007 8:12 UTC (Wed) by tyhik (subscriber, #14747) [Link]

"But, to outright prohibit a function like strcpy() in your code is simply
madness..."

You are grossly ignoring maintainability. Allison has a lot of experience in maintaining a
large project and knows very well the real value (or the lack of) letting opinionated
codewarriors micro-optimize with whatever means they claim they master.

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

Posted Dec 6, 2007 9:21 UTC (Thu) by yeti-dn (guest, #46560) [Link]

You are grossly ignoring maintainability.

In the cases strcpy() is the right function to use, the alternatives require less
straightforward, more complex code -- I would even say obfuscated code in some cases.  How is
this good for maintainability?

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

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

sprintf() is sufficiently hard to use safely for nontrivial format strings that you might as
well ban it, too. You end up having to reimplement the sprintf() format string parser just to
figure out how long the sprintf() output is going to be, or engage in horrible tricks with
mmap()ed regions and SIGSEGV handlers. I've had to do the latter to keep software running on
platforms without snprintf(), but if I'd had my druthers I'd just as happily have dumped
support those platforms.

(Free software can import a proper snprintf() implementation in that situation anyway.)

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

Posted Nov 27, 2007 14:42 UTC (Tue) by bfields (subscriber, #19510) [Link]

sprintf() is sufficiently hard to use safely for nontrivial format strings that you might as well ban it, too.

Well, there are still plenty of trivial uses of sprintf(); in many cases there's an obvious upper bound on the length of the output.

Grepping through the source for sprintf() and looking for problems certainly makes sense, but if you ban it outright then the worry is that some coders will find some mechanical workaround for the ban that just replaces an obvious bug by one that's harder to see.

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

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

> Grepping through the source for sprintf() and looking for problems
> certainly makes sense, but if you ban it outright then the worry is that
> some coders will find some mechanical workaround for the ban that just
> replaces an obvious bug by one that's harder to see.

Exactly...  Plus, if you instill in them the idea that (for instance) snprintf() is the "safe"
replacement for sprintf(), then you'll get them just unthinkingly using that instead, and
perhaps using it incorrectly...  (Eg: passing an incorrect buffer length, or blindly allowing
truncation when it's not desirable, or blindly using the return value without accounting for
it exceding the buffer size due to truncation, etc...)  And, since other people think
snprintf()==safe, then it's unlikely to get noticed as easily as improper sprintf() usage...

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 (subscriber, #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 (subscriber, #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 (guest, #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. :(

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

Posted Nov 27, 2007 18:17 UTC (Tue) by iabervon (subscriber, #722) [Link]

There's a good reason for using 'strncmp(input, "constant_string", strlen("constant_string"))'
instead of 'strcmp(input, "constant_string")': it gives substantially different results. The
former tests whether 'input' starts with "constant_string", while the latter tests whether
they're equal. Of course, it's best to have a macro or inline function for the former so that
it's clear to everybody what you're testing, to save a bit of line length in the source, and
to make sure the arguments don't get out of sync. Now 'strncmp(input, "constant_string",
strlen("constant_string") + 1)' would be dumb, but it's perfectly fine to avoid testing
against the constant's nul-termination if you don't want that to count as a difference.

You're probably thinking of strcpy, not strcmp, which wouldn't be in an if and would use
sizeof the first argument as the length limit. And your point would be correct there (except
for having found it in that particular code, probably); it's better to use strcpy and a clear
proof that the buffer has enough space (rejecting the operation entirely if it isn't possible)
instead of truncating the input in the case where it overflows, which is likely to do
something that nobody wants anyway.

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

Posted Nov 28, 2007 11:47 UTC (Wed) by dgm (subscriber, #49227) [Link]

I think it's

strncmp(input, CONSTANT_STRING, (sizeof(CONSTANT_STRING)/sizeof(char))-1)

what makes sense in that case. Why determine _at_run-time_ the lenght of a constant string?

Insecurity Blues: Jeremy Allison reflects on Samba security flaws

Posted Nov 28, 2007 18:21 UTC (Wed) by iabervon (subscriber, #722) [Link]

If it's a string constant at compile time, any good compiler will identify its length as a
compile-time constant as well. The strlen version also works on a constant string that's been
put in a char * variable that can only have one value at that point in the code (where the
compiler determines that the value is a constant, but the size of the expression is the size
of a pointer), and the same idiom applies to non-constant second strings. Oh, and sizeof(char)
is defined to be 1, because that's the unit that sizeof's value is in.

strlen vs sizeof

Posted Nov 30, 2007 5:04 UTC (Fri) by pjm (subscriber, #2080) [Link]

Note to other readers: gcc will normally do this strlen optimization, but not if any of the
following flags are in effect: -fno-builtin, -fno-builtin-strlen, -ffreestanding, -fno-hosted.
In particular, don't rely on this optimization if you're writing code for Linux or any other
operating system kernel.  The effect can probably be overridden with an explicit
-fbuiltin-strlen, though I haven't checked.  I note that rgrep fbuiltin linux-2.6.21 (the
latest version I have handy) finds no matches.

strlen vs sizeof

Posted Nov 30, 2007 16:49 UTC (Fri) by iabervon (subscriber, #722) [Link]

I thought that the kernel source actually also made that optimization itself,  but I guess
that dealing with text strings isn't sufficiently common in the kernel to make it worth
setting up. The kernel source does do a bunch of its own optimizations in macros based on
arguments being constants for things like memset and some math, and could pass off to
__builtin_strlen() the arguments that won't actually generate a function call.