positive logic?

[ark () eltex ru]

-----BEGIN PGP SIGNED MESSAGE-----

nuqneH,

Looks like i missed interesting things ignoring the whole Code Red discussion :(
(It is almost impossible to read _all_ messages in _all_ mailing lists i am
subscribed to)

I'd like to know more about "positive logic". It is good when you protect,
say, tcp/ip stack: you make formal description of the state machine and then
just drop everything that does not match. This method is secure by design,
but real ip stacks implement performance hacks that make this approach
hard and confusing (thanks we have ipfilter that does much of dirty work for
us ;)

But things are not so clean when we do talk application layer. 
Things that are "exploits" for some web servers - or worse, cgi's - are perfectly
legal requests for others because those requests do confrom http standard.

There are exceptions that are easy to handle but the problem still exists.
How can one be so sure every "bad" request will be blocked? The only solution
is having (and maintaining it up-to-date!) huge database of what requests could 
be handled by every application we run and which ones are illegal. Most fit some
known patterns but the problem still exists. 

I know there are some products that claim to do, but i'd like to see technical
papers describing how does it work in details. Otherwise i am forced to think of
it as snake oil.

What about open source implentations ;)?

Darren Reed <darrenr () reed wattle id au> said :

> In some email I received from Joseph Steinberg, sie wrote:
> > I agree wholeheartedly that we do need to come up with a better way of
> > addressing these issues than patching every specific vulnerability. Our
> > e-Gap systems do this with positive logic -- i.e., enforcing that
> > web-servers/applications only receive requests in formats that the
> > web-servers/apps expect. So, worm attacks, hacker attacks, etc. (which are
> > generally based on unexpected submissions) fail -- regardless of whether the
> > particular hack is known to our product or not. I am curious how others deal
> > with this.
> [...]
>
> How about making it a felony to sell or otherwise provide software for
> commercial use that contains buffer overflows ?  Or make it something you
> cannot "disclaim" - it should be part of the exercising of due diligence
> every software company has to get them out of software before releasing it.
>
> I'm actually half serious about this.
>
> It's time to start raising the bar.
>
> How much does it cost the world to patch these problems up vs the developer
> to put in place proper testing to find and eliminate these problems before
> it goes out the door?  How can we allow such a critical piece of modern life
> to be such a pile of rubbish?  The frightening thing is if you look from the
> embedded market all the way up to super computers, there are no exceptions
> in the "has a buffer overflow security hole" category.

                                     _     _  _  _  _      _  _
 {::} {::} {::}  CU in Hell          _| o |_ | | _|| |   / _||_|   |_ |_ |_
 (##) (##) (##)        /Arkan#iD    |_  o  _||_| _||_| /   _|  | o |_||_||_|
 [||] [||] [||]            Do i believe in Bible? Hell,man,i've seen one!

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1i

iQCVAwUBO2/6GaH/mIJW9LeBAQFXYAQApAXAk2IvloeK9H6e7YoCgrr5pGFP9i8d
pJG9f2rconfvhfQsSf33SOxVr9AmMWhgYHcfHRi1hqpgfqLxy2vpCHLc2SXslleo
8oM+bzLXZi5kIdrqgjwmzqLnD+cZbEMLHSOwda8/8feHVBHMqWqg8f3gtyoB+dpn
UJcasDg/9zI=
=xIa0
-----END PGP SIGNATURE-----
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards