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/