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 12:44:56 +0100
From: Christian Sciberras <uuf6429@...il.com>
To: noloader@...il.com
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Getting Off the Patch

I think at this point we need to put a line between those who |don't care
about patches|, those that |install patches after careful testing|, and
those that |install whatever patch| comes their way.

Cheers.




On Wed, Jan 19, 2011 at 12:25 PM, Jeffrey Walton <noloader@...il.com> wrote:

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

Content of type "text/html" skipped

_______________________________________________
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