mailing list archives
Re: Getting Off the Patch
From: Pete Herzog <lists () isecom org>
Date: Fri, 14 Jan 2011 15:03:10 +0100
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
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 () isecom org
ISECOM - Institute for Security and Open Methodologies
www.isecom.org - www.osstmm.org
www.hackerhighschool.org - www.badpeopleproject.org
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/