IP: Two security related articles: [risks] Risks Digest 21.30

[David Farber <dave () farber net>]

> Date: Fri, 23 Mar 2001 09:30:54 -0600
> From: "Sinclair, Roy" <RCSinclair () CESSNA TEXTRON COM>
> Subject: Verisign certificates problem
>
>   [From BUGTRAQ () SECURITYFOCUS COM,
>   Via both Mike Hogsett and Dave Stringer-Calvert.  TNX. PGN]
>
> Some information regarding Verisign Certificates that has come out of this
> fiasco is quite disturbing but has been under reported and may have been
> missed by many in the security business.
>
> Pay close attention to this paragraph from the Frequently Asked Questions
> part of http://www.microsoft.com/technet/security/bulletin/MS01-017.asp:
>
> "The update is needed because of a characteristic of VeriSign code-signing
> certificates. Every certificate issuer periodically generates a Certificate
> Revocation List (CRL), which lists all the certificates that should be
> considered invalid. A field in every certificate should indicate the CRL
> Distribution Point (CDP) - the location from which the CRL can be obtained.
> The problem is that VeriSign code-signing certificates leave the CDP
> information blank. As a result, even though VeriSign has added these two
> certificates to its current CRL, it's not possible for systems to
> automatically download and check it. "
> The first question I have after seeing that is how many of the rest of the
> 500,000 certificates that Verisign says they have issued also do not have
> this CRL Distribution Point field properly filled in.  In the lack of any
> information to the contrary I would hazard to guess that it's probably that
> none of the 500,000 certificates issued by Verisign have supplied the
> information that should be in this field.  If this is truly the case then we
> have yet another problem of much wider scope than the improper issuance of
> two certificates, there are a great number of valid certificates which could
> be stolen or misused and even if Verisign were to add them to their CRL the
> certificates themselves don't point to the CRL so they won't be properly
> rejected.
> Two things need to be done, one is that software which checks certificates
> must be changed to warn users that certificates lacking a CRL are much more
> suspect and Verisign needs to re-place all certificates that currently lack
> this critical information with new certificates that have this field
> properly filled in.
> Additional questions that come to mind is how many other certifying agencies
> have also failed to fill in the information in this field and what
> percentage of the certificates being used today are unverifiable?
>
> ------------------------------
>
> Date: Thu, 22 Mar 2001 15:30:32 -0500
> From: Michael Sinz <Michael.Sinz () sinz org>
> Subject: When security is based on trust
>
> So, lets see - Microsoft says that ActiveX is secure as long as the software
> (ActiveX thing) is not from an "evil" source.  To prevent bad software from
> being used, they use digital signatures to identify the person or company
> who made the software such that you could either trust them or know who to
> go after when it does something bad.  The OS and system infrastructure does
> not try to enforce anything other than to check these certificates and warn
> you based on your settings as to if you want to run unsigned software or any
> software signed by company "X" or a number of other possible combinations of
> warnings.
>
> There is no built in security beyond that point.  Once you say "Yes, run it"
> you are opening up your system to complete control by the ActiveX control.
>
> Ok, in a perfect world, with no one wishing to do harm or rob you blind,
> such a mechanism would work just fine.  The Internet is not such a world.
>
> And now, to put this into even brighter "this is not the right way to do
> things" light, Microsoft says that you can not even trust that software that
> says it is from Microsoft really is from Microsoft unless you first check
> the dates on the digital signature and remember that if it is Jan 29 or 30,
> 2001, that it is most likely not really Microsoft and you should not accept
> it.
>
> What do people do now?  If you accept anything from Microsoft, it is too
> late.  If you ask for confirmation before running, what are the chances you
> would even think to look at the dates once you see "Microsoft" as the
> signing party?
>
> All of this really goes to show that security must be done at the start and
> not just "added in" by saying "make sure you trust the author".  Even if you
> trust the author, there could be bugs.  And, as this example shows, you can
> not even always trust you know who the author is.
>
> Time to think this though some more...
>
> http://www.zdnet.com/zdnn/stories/news/0,4586,5079987,00.html?chkpt=zdhpnews01



For archives see: http://www.interesting-people.org/