[Full-disclosure] Getting Off the Patch
lists at isecom.org
Fri Jan 14 14:03:10 GMT 2011
> While true, the patch is still most likely going to eliminate the flaw I
> *do* know about. I don't have either the connections or the time to find
> and know about some flaws that aren't covered by the patch, this is
> true; but I will know about the ones that are, and given my lack of
> connections, so do many other people, which increases the potential of
> exploitation (not the likelihood so much, but the potential). If I have
Which is all the more reason to implement an array of controls
(defense in width) for the interactive points rather than rely on
patches to fix ONLY the problems you know about.
> the tools and the knowledge to fix a problem, I would figure that I
> would be remiss in not employing them merely because the other controls
> in place should keep my data safe. Especially if there is a direct
> interaction with what I'm patching and what I want to protect (website
> code & apache, can't expect it to work and not be able to read/run my
> code and such).
And you would be wrong because patching means changing the code. You
know what you have and the operations are as you want them. Then you
want to change the code to deal with some problem which requires you
to verify your operations again to assure it is what you want. Perhaps
you don't implement change control. Perhaps you don't do functional
testing of operations after patching. Perhaps you choose to trust the
same people who made the flaw in the first place. Perhaps you don't
know your operational baseline. Perhaps you have lots of time to
spare. All reasons why you may want to patch AND use controls. But you
would be remiss to think that patching means only fixing a problem and
changes nothing else.
> The tl;dr summary of that, I guess, is "patching will at least keep the
> skiddies out."
Which is good if the world was made of only skiddies and all the bad
things that can happen are in the hands of the lowest common
denominator. But operational controls will keep out the skiddies and
all the rest of the undesirables.
> Potentially, yes. However, it's not exactly like patches I can somewhat
> trust can come from anywhere else (unless I wrote it), and if I continue
> to use the software I probably trust its author. It also takes
> substantial effort to evaluate switching products entirely as opposed to
> patching what you currently have, but that's just stating the obvious.
Or else, do what is realistic- control that which you have less than
nominal reason to trust. If you can't control it, get rid of it.
Patching it constantly will only constantly change your operations
which, should be as stable as possible. The less stable it is, the
less you can tell when something is wrong.
> All I'm really saying here is that controls external to what is weak are
> nice and definitely a recommendation, but ultimately can only mitigate
> what can be done. I'm saying it's generally worth it to patch for that
> extra assurance against well-known flaws -- but, granted, only
> especially so after a given period of time that sees many more and/or
> 'potentially fatal' flaws exposed to the public.
And I'm saying that's the wrong way to think about this because
patches don't just fix the flaw. They change things. There is nothing
wrong with a flaw in your software if it can be mitigated in other
ways efficiently because your software is FULL of flaws that you don't
know about anyways. So you can mitigate a large number of them or even
all of them before they become zero days. So don't waste your time on
the patching and the updating because a patch isn't always "just a patch".
Pete Herzog - Managing Director - pete at isecom.org
ISECOM - Institute for Security and Open Methodologies
www.isecom.org - www.osstmm.org
www.hackerhighschool.org - www.badpeopleproject.org
Full-Disclosure is hosted and sponsored by Secunia.