Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: Getting Off the Patch
From: Zach C <fxchip () gmail com>
Date: Thu, 13 Jan 2011 19:15:04 -0800



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

Zach,

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.

Seems logical; however...

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.

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 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). 

The tl;dr summary of that, I guess, is "patching will at least keep the skiddies out."

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.

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. 

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.

Sincerely,
-pete.

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. 

Everything does make perfect sense though.

-Zach


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:

Hi,

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:

https://www.infosecisland.com/blogview/10813-Getting-Off-the-Patch.html

Sincerely,
-pete.

--
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/




-- 
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/

  By Date           By Thread  

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