James Tucker wrote:
One of the primary laws for speed optimisation is to trust your input
and allow for data flow instantly. Especially if your trying to send
say, an interrupt, we could re-index all of the interrupts available,
and then send it. But we'd have missed any time dependancy we were
relying on.
Life is never that simple.
No, but the situations I'm talking about are *not* those types of
situations. There's no reason why input coming in from a web server
should not be properly bounds checked.
If you're taking input and you have a reason to believe that you can't
trust that input, it's irresponsible not to check it. That includes
virtually all input from the internet.
We could always trust all input... but the fact of the matter is that...
life is never that simple.
And that
is a very valid point. The same flaws in code that cause exploits also
cause crashes by their very nature. It's not "all over the place", it's
a fact of system design. If they can't avoid mishandling input, then
people's expectations will be low. See how it all comes together?
I see how people think that other kernels actually do a better job
over this, however they haven't actually looked at the the code to
verify that fact. Furhtermore it is extremely rare that any of you are
running debugger versions of the MS os's so in reality, you don't have
a clue what is causing the crashes. This thread is starting to sound a
bit like an MS bash rather than a discussion of something that is
fact.
Actually, I'm talking about situations where we know what causes
specific crashes. It's very easy to find these situations as they're
included in security disclosures.
Obviously, it's not possible to trace every crash and fringe situations
do occur. That doesn't change the fact that MS is handling their
procedures poorly and they're making sloppy mistakes. Many other
companies/groups make sloppy mistakes as well. I didn't see anyone in
this thread claiming that MS was the only company that did this... just
that they were the most exposed one.
In my real experience where I HAVE verified the cause of a crash,
particularly in the server world, but also for many many client
crashes, it's normally a hardware failure. Be it a particular memory
bank doesn't refresh in time due to a slightly lower than normal
voltage level or a bus controller problem that is in fact an unusual,
but nonetheless problematic fault with the design of the motherboard.
This is very far from software faults.
In my real experience, there are many different causes for crashes.
Hardware is a significant cause.
See, you're not the only person with real world experience.
In my real experience, people who try to point out how they have real
experience and others don't (whom they don't even know) are talking out
their asses.
Many of the examples being used are examples of software that in
itself cannot cause a BSOD. IE being the perfect example.
Unless you have a memory management flaw where the partitioning of the
memory is compromised. Such is the situation in Windows 9x... as I
stated in the thread, it's unlikely that that type of situation would
occur in a Windows NT style environment, but you still get other forms
of crashes for a number of different reasons.
A BSOD isn't the only type of software crash and it's silly to only talk
about BSODs when you're talking about customer satisfaction.
More to the
point, the other software also mentioned tends to be the kind of
software that you can replicate the crash over and over again. If the
crash is replicatable in this way, then sure, it's probably a software
problem, but why not dump that software package, rather than claiming
that the OS should fix every bit of bad coding you've ever seen.
Where did anyone claim that it's the OS' job to fix application code?
Oh, wait, no one did.
Try reading. It's a beautiful thing.
How many of you are really using (neh, in fact, have EVER used) a
kernel that CANNOT crash by design? Anyone? Right, enough said then.
Maybe for you... but for the rest of us, life isn't that simple.
-bkfsec
(ps. I'm assuming you meant to send this to the list from your tone.
Or, maybe you got embarassed last minute and decided only to send it to
me. Either way, it's going to the list.)
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
