full-disclosure - Re: Expired certificate

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, 4 Aug 2010 16:01:30 -0400
From: Charles Morris <charlesmorris@...il.com>
To: Marsh Ray <marsh@...endedsubset.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Expired certificate

On Wed, Aug 4, 2010 at 2:44 PM, Marsh Ray <marsh@...endedsubset.com> wrote:
> On 08/04/2010 09:44 AM, Paul Schmehl wrote:
>> --On Monday, August 02, 2010 12:36:37 -0400 Elazar Broad<elazar@...hmail.com>
>>>
>>> Spot on. I know of one large accounting/ERP system(which shall
>>> remain nameless, though I am sure there are those out there who
>>> have come across it) that checked the SQL version, including the
>>> revision number at runtime, which made patching SQL impossible.
>>
>> In those cases where there are such systems, there should be mitigating
>> controls around them that increase the difficulty of break-in.  Otherwise the
>> IT department is negligent.
>
> It's not the IT department's fault if the vendor ships a product that
> refuses to run with a patched system.
>
> There have always been products out there that behave like this, it's a
> simple coding or policy mistake to make. The attraction is that they
> don't have to support any configuration that they haven't tested.
>
> Unfortunately, products that do so are straying away from the herd and
> choosing not to participate in its collective defense. They are still
> subject to all the same published attacks, but cannot benefit from the
> standard update and patch cycle.
>
> A secondary effect is that since it's so hard to predict the security of
> such a system over the long term, they simply can't be considered when
> developing general guidelines and best practices. For example, we might
> be discussing the schedule of disclosing a bug in the SQL vendor's
> product. If the SQL vendor can patch it easily for their primary
> customer base, those oddball downstream vendors are just not going to
> get much consideration. Eventually, they will probably tire of playing
> catch-up and adjust their policy.
>
> - Marsh
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

This is all true, however Paul is also correct. In the real world
where you may not get to make the decision of what software
products to implement, mitigating controls for that exposure
must be put into place; whether they be firewalls, patches,
extensive logging, or etc.

It isn't the IT Department's fault that the product is garbage,
however it is the IT Department's fault if they don't control and isolate it.
The reality is that when you walk into a room one of your options
isn't always "clean house"..

- Charles

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