Benjamin Scott wrote: > On Fri, 23 Mar 2001, Bob Bell wrote: > >> Just for those of you who have not seen the bulletin, there is yet another > >> reason to look towards Linux. > > > > My understanding is that this has nothing to do with Microsoft > > Windows. > > The problem is a design flaw in Internet Explorer/Windows, specifically, > ActiveX. > > You can solve this problem by turning on the feature of MSIE called "Check > for certificate revocation". That will cause MSIE to check every certificate > it gets to see if it has been revoked by the issuer. Naturally, this feature > is turned off by default for all versions of MSIE. No, that won't fix it. Verisign's certificate revocation mechanism doesn't work with Microsoft's verification, at least. In fact, the mechanism is somewhat broken and won't give any warnings in certain circumstances. Refer to http://www.securityfocus.com/frames/?content=/templates/archive.pike%3Flist%3D1%26mid%3D67303 and http://www.angelfire.com/ab/juan123/iengine.html for relevant issues. Until this matter is resolved, the best protection is to change Internet Security levels to Disable Signed ActiveX. Of course, that breaks Microsoft's Windows Update service among other things. Really the best protection is to not use Internet Explorer (or even Windows). :-) >From Microsoft (http://www.microsoft.com/technet/security/bulletin/MS01-017.asp): > VeriSign has revoked the certificates, and they are listed in VeriSign�s > current Certificate Revocation List (CRL). However, because VeriSign�s > code-signing certificates do not specify a CRL Distribution Point (CDP), > it is not possible for any browser�s CRL-checking mechanism to > download the VeriSign CRL and use it. Microsoft is developing an > update that rectifies this problem. The update package includes a CRL > containing the two certificates, and an installable revocation handler > that consults the CRL on the local machine, rather than attempting to > use the CDP mechanism. > > Is this a security vulnerability? > > This issue does not meet the strict definition of a security > vulnerability, because there is no flaw in any of the affected Microsoft > products. The problem results solely because of an error made by a > third party. However, it clearly poses a grave risk to customers, and > we have issued this bulletin to provide information about the issue and > the actions customers should immediately take. That seems more than a bit picky in my mind. > VeriSign screwed up by not checking when they issued a certificate, but I > think Microsoft has made enough bad design decisions to make them guilty, too. > > ... [VeriSign] was tricked into believing ... Verisign issued the certificates January 29th and 30th. They noticed the problem two months later during a background check. The background check is supposed to happen BEFORE issuing the certificates, not after. It doesn't matter how someone tricked them. They shouldn't have issued them without the verification first. This was a violation of their policy. I had a problem renewing a certificate with them because the company's name was slightly different from the previous year (N.E. What Where When vs. New England What Where When). This was a certificate I had had for five years. So, if they were that picky on a renewal (after the verification had been done), how could they issue one with no validation? Basically, they screwed up. >From Verisign (http://www.verisign.com/developer/notice/authenticode/faq.html): > As good as our process is, we did not detect fraud at issuance - stage one. > This was due to human error. We did detect fraud at stage two. We discovered > the fraud during routine fraud screening. That said, we are actively > implementing controls to improve our internal processes to prevent first stage > failures to detect fraud. We will be adding technical controls as well as more > manual checks and balances to prevent this from occurring in the future. -- Dan Jenkins ([EMAIL PROTECTED]) Rastech Inc., Bedford, NH, USA, 1-603-627-0443 *** Technical Support for over a Quarter Century
begin:vcard n:Jenkins;Dan tel;fax:1-603-627-7513 tel;work:1-603-627-0443 x-mozilla-html:TRUE url:http://www.rastech.com org:Rastech Inc. adr:;;21 Curtis Lane;Bedford;NH;03110;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Technical Director fn:Dan Jenkins end:vcard
