Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Re: Getting Off the Patch
From: phocean <0x90 () phocean net>
Date: Fri, 14 Jan 2011 09:25:51 +0100

I don't understand this thread and what is new.

We all know it is rather hard to get protection from unknown threads,
and especially the unknow unknown. Competent administrator can try to
mitigate known unknown, eg common threats that may affect a software by
In that way, patching is not on the front of the protections, true, but
it doesn't mean you can filter 100% of the potential threats. No one can
say it.
And anyway, patching is always a must because it is there to correct an
error, the source of the problem and leave a few less chances to the

But this is so well known, at least I thought, that I wonder what is the
purpose of all of this.

Le jeudi 13 janvier 2011 à 19:56 +0100, Pete Herzog a écrit :

Please allow me to strip away any opinion for a moment and focus on 
the facts which seem to be something we will agree on.

1. A patch when applied changes the source code.
2. Patches are released AFTER a flaw is reported.
3. A patch will fix one or more reported flaws in the code.
4. The means to absolutely verify the true source of the patch 
requires that your security has not already been compromised.
5. Evidence shows that patches, under the guise of security, have been 
used in the past as a means for a company to change the function of 
their product, remove content, or enforce licensing terms after it has 
been purchased and installed on the computer.
6. Patching alone, without operational controls, has not shown to 
protect systems or services consistently.

Therefore using the facts, we can logically conclude the following: 
For every software, there are an unknown quantity of flaws. You 
protect the software with multiple varied controls to protect against 
flaws both reported and not. Therefore when you fix the flaw, you are 
only fixing a known and reported flaw. This does not protect you 
against the unknown, unreported flaws still existing and why you still 
need operational controls. So to say that you need to patch to fix a 
flaw ignores all the flaws you don't know about. To fix each flaw in 
addition to adding controls adds new uncertainties both to the 
software and the operational controls and requires further 
verification testing to avoid surprise problems. A small change does 
not mean it's a small test. To ignore the functional testing after 
patching is to trust that the software maker knows your operations 
better than you, has your best interest in mind above their own 
profits, and that is if you can even be sure of where the patch came 
from. Patch only because you can't control the interactions, can't 
stop the interactions, don't do any quality control or functionality 
testing anyway, or don't know if you've been already compromised anyway.


On 1/11/2011 2:53 PM, Zach C wrote:
Hmm. So you propose other measures of security as a way of circumventing the requirement of patching vulnerable 
software. That's nice, but it occurs to me that the vulnerable software is still vulnerable, and sandboxing (as you 
mentioned in an example) isn't always possible or feasible -- maybe it requires a code change, who knows. I see you 
mention the time it takes to test patches and their effect on your workflow, but I would figure an equal or greater 
amount of time would then need to be spent on other solutions as well -- and even when those other solutions are 
implemented, the software that you're doing all this to is still vulnerable, and likely in a way that such measures 
can't really prevent all that well (code theft, etc).

Am I mistaken? I thought I got all that right. I haven't read the OSSTMM 3 yet, granted (it's on my to-do list), 
but I would think that it's still worth doing all that -- just that disregarding patches entirely in favor of this 
isn't the solution either, which is probably not what you're saying. :)

On Jan 10, 2011, at 11:41 AM, Pete Herzog<lists () isecom org>  wrote:


Here's a new article on how and why you may want to stop patching your
software and take a new approach to your security.

"So if patching is a tactic towards a particular security strategy,
how can that be bad? I never said it was all bad. There are reasons
where patching makes sense just like there are reasons to get a kick
from a cup of coffee, get kicked by a shot of tequila, or spray stuff
up your nose to breathe easier for 1.5 seconds. Yes, for the record, I
am comparing patching to nasal spray."

Read it here:



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.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]