lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 19 Jan 2011 06:25:57 -0500
From: Jeffrey Walton <noloader@...il.com>
To: Cor Rosielle <cor@...post24.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Getting Off the Patch

Sorry about the top post - just one comment....

> Bottom line is that patching interferes operations and therefore,
Its a sad state of affairs when folks put other endeavors, such as
uptime, above security.

I can't speak for others but I hope my data is not housed at such a
shop. If my data went out the e-door of such a shop, and the shop was
not patching, then I would consider the shop's practices grossly
negligent. It would be irrelevant to me who claimed it was OK for
whatever reason.

Jeff

On Wed, Jan 19, 2011 at 6:08 AM, Cor Rosielle <cor@...post24.com> wrote:
> I don't agree with the statement: "From a security standpoint, patching is
> better than not patching.  Period.".
>
> Sometimes patching is the right solution, often it is not. Since some asked
> experiences from larger companies, here is one:
>
> In 2001 I was responsible for maintaining all kinds of systems and services
> at a telephony and internet provider. One morning a list with our company
> name in it was mentioned in the radio news bulletins. We also found our name
> in this list in articles in newspapers. A "hacker" found we didn't install a
> patch on one of our web servers which ran IIS 5.0 on Windows 2000. The patch
> was available for about 3 months and the hacker claimed he could attack our
> server because of this specific patch missing. Because of his "ethical
> standards" he did not try to really attack the server but just publish about
> the shameful patching policies in large companies.
> Three years later, when a new website was developed, the server was
> replaced. The patch was still not installed. Even though we were in the
> radio news bulletins and news papers and the world knew about our vulnerable
> server, no successful attack occurred in all that time.
>
> O yes, they tried. I've seen it in our log files. But because other defense
> mechanisms, the known exploit did not work on our server. And since the web
> server was in no danger without this patch, we decided installing the patch
> would be a higher risk than leaving the server as is.
>
> I did not know about the OSSTMM in those days. If I did, I could have
> explained why patching is not always the best solution: it interferes with
> your operations. And if it influences you operations, you better control it.
> Not blindly execute it and install the patch using an automated update
> process, but actually control it.
> So the first thing to do is to decide if applying a patch is useful at all.
> And often it is not! E.g. why would you even consider to install MS10-085 on
> a http-only web server (MS10-085 apparently fixes an error in TLS
> handshake)? (Don't flame me on this one, it's just meant as an example). And
> if you concluded a patch is useful, then you decide if you do need to
> install it, or if it is not really necessary to install it. And if you
> install it, then decide if you do it manually, in a controlled manner, or
> use an automated update process, in an uncontrolled manner. The OSSTMM helps
> you to realize that an automated update process increases the attack
> surface, which better be controlled.
> Another option of course is to blindly install it, because you trust your
> vendor (you know, the one that provided buggy software in the first place).
> Then your not controlling, but trusting. Read chapter 5 in the OSSTMM to
> find out if that is wise for this particular vendor, or not.
>
> Bottom line is that patching interferes operations and therefore, from a
> security standpoint, it either has to be controlled or trusted. It is not
> always true that patching is better than not patching. So I would slightly
> like to rephrase that statement:
> "From a security standpoint, thinking is better than not thinking.
> Period.". (Now would it surprise you if I told you that critical thinking is
> one of the starting points of the OSSTMM??.
>
> Cor Rosielle
> Chief Technology Officer
>
>
>
>> -----Original Message-----
>> From: full-disclosure-bounces@...ts.grok.org.uk [mailto:full-
>> disclosure-bounces@...ts.grok.org.uk] On Behalf Of Thor (Hammer of God)
>> Sent: dinsdag 18 januari 2011 19:39
>> To: Valdis.Kletnieks@...edu; Cal Leeming [Simplicity Media Ltd]
>> Cc: full-disclosure@...ts.grok.org.uk
>> Subject: Re: [Full-disclosure] Getting Off the Patch
>>
>> >On Mon, 17 Jan 2011 22:29:13 GMT, "Cal Leeming [Simplicity Media Ltd]"
>> said:
>> >
>> >> Most people wouldn't rely solely on patch day to protect their
>> >> systems/network
>> >
>> >You're in for a surprise.
>>
>> One, as Cal pointed out, you cut out the context of what he said/meant.
>> And two, so what if they do?  At least they are patching.   If security
>> is the goal, then advocate for security in depth.  From a security
>> standpoint, patching is better than not patching.  Period.  If you have
>> controls in place to mitigate exposure, then they should be combined
>> with patching.  Are you taking the position that the level of "being
>> surprised" at the number of people who only patch dictates that they
>> stop patching and try to successfully implement other controls so they
>> don't have to patch?
>>
>> Playing "whack a mole" was entertaining, but in all seriousness, your
>> responses to this thread have been confusing to me.   Any security
>> model that not only advocates non-patching, but that is designed with
>> the intent of not patching is completely retarded.  I defy anyone to
>> provide verifiable evidence to the contrary that is not based on a
>> server and a couple of workstations.  Even the self-proclaimed
>> "marketing" guy who admitted he didn't know how to patch couldn't come
>> up with a single shred of substantiating research to support anything
>> different.   Comparing his "research" to Einstein and general
>> relativity is a level of ass-hattery that rivals some of the worst on
>> the list.
>>
>> So when I see you apparently supporting the idea, as someone who
>> normally provides some sort of empirical backing to his statements, I
>> become interested in what factors lead you to that conclusion.
>>
>> t

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ