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]

Message-ID: <4C59B51B.4040802@extendedsubset.com>
Date: Wed, 04 Aug 2010 13:44:43 -0500
From: Marsh Ray <marsh@...endedsubset.com>
To: Paul Schmehl <pschmehl_lists@...rr.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Expired certificate

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/