Re: Bigger burger roll needed

[bkfsec <bkfsec () sdf lonestar org>]

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/