Vulnerability

    Verisign

Affected

    Verisign

Description

    Following  is  based  on  a  Microsoft Security Bulletin MS01-017.
    VeriSign, Inc., recently advised Microsoft that on January 30  and
    31,  2001,  it  issued  two  VeriSign Class 3 code-signing digital
    certificates to  an individual  who fraudulently  claimed to  be a
    Microsoft employee.  The common name assigned to both certificates
    is  "Microsoft  Corporation".   The  ability  to  sign  executable
    content  using  keys  that  purport  to  belong to Microsoft would
    clearly  be  advantageous  to  an  attacker who wished to convince
    users to  allow the  content to  run.   The certificates  could be
    used to sign programs, ActiveX controls, Office macros, and  other
    executable content.  Of these, signed ActiveX controls and  Office
    macros would pose the greatest risk, because the attack  scenarios
    involving them would  be the most  straightforward.  Both  ActiveX
    controls and Word documents can be delivered via either web  pages
    or HTML mails.  ActiveX controls can be automatically invoked  via
    script, and Word documents can be automatically opened via  script
    unless the user has applied the Office Document Open  Confirmation
    Tool.

    However,  even  though  the  certificates  say  they  are owned by
    Microsoft,  they  are  not  bona  fide Microsoft certificates, and
    content signed by them would not be trusted by default.  Trust  is
    defined on a certificate-by-certificate basis, rather than on  the
    basis of the common name.   As a result, a warning dialogue  would
    be displayed before any of  the signed content could be  executed,
    even  if   the  user   had  previously   agreed  to   trust  other
    certificates with  the common  name "Microsoft  Corporation".  The
    danger, of course,  is that even  a security-conscious user  might
    agree to let the content execute, and might agree to always  trust
    the bogus certificates.

    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.

    - The  certificates  are  not  trusted  by default.  As a  result,
      neither code nor ActiveX controls  could be made to run  without
      displaying a warning  dialogue.  By  viewing the certificate  in
      such dialogues, users can easily recognize the certificates.
    - The certificates  are not the  bona fide Microsoft  code-signing
      certificates.  Content signed by those keys can be distinguished
      from bona fide Microsoft content.

    Sadly, Thawte (which was purchased  by Versign and is supposed  to
    be the second largest  CA) does not include  a CPD field in  their
    server  certificates  either.   Actually  checking  most of the CA
    certificates shipped with IE less than half have a CPD field.   Of
    the big CA only Entrust seems to use the field.

    On the plus  side if you  use IE and  go into Internet  Options ->
    Advanced  ->  Security  and  check  the  boxes  next to "Check for
    publisher's  certificate   revocation"  and   "Check  for   server
    certificate revocation" then you will get a warning. IE won't  pop
    up the warning when you visit a site with a certificate without  a
    CPD  field  but  if  you  click  on  the  lock  and  bring  up the
    certificate window you will see the following text:

        "Windows  cannot  determine  the  validity of this certificate
         because it cannot locate a valid certificate revocation  list
         from the certificate authority that issued this certificate."

    First of all, CRLDP is an optional extension, which means you  can
    include it or not  include it (most CAs  leave it out).   Claiming
    that  Verisign  are  somehow  at  fault because they don't include
    this extension is incorrect.

    Secondly, even if they had included it, it wouldn't have done  any
    good.   The revocation  checking in  MSIE is  handled by an add-on
    DLL called  VSREVOKE.DLL.   This has  some random  URL at Verisign
    hardcoded into it.   If you go into  MSIE and dive down  into some
    obscure  menu  and  enable  revocation  checking (it's disabled by
    default),  what'll  happen  is  that  it'll  go  to  the hardcoded
    address,  find  there's  nothing  there,  eventually time out, and
    process the cert anyway.   The only effect of enabling  revocation
    checking is that every time MSIE sees a cert, it stalls for  about
    a minute  before it  continues as  if nothing  was wrong (this was
    for IE4, maybe they've finally fixed it in 5, but that won't  help
    the  huge  number  of  uses  who  get  IE4 pre-installed and never
    change their machine configuration).

    Therefore even if Verisign had included CRLDP's, MSIE will  ignore
    them  by  default,  and  if  you  can  figure  out  how  to enable
    processing would get it wrong.  Even if Verisign were to add  them
    to their  CRL, it  wouldn't help  you if  you were using Microsoft
    software.

Solution

    A  patch  is  available  to  fix  this vulnerability.  Please read
    Security Bulletin

        http://www.microsoft.com/technet/security/bulletin/ms01-017.asp

    for information on obtaining this patch.

    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.  Versions of the update are being prepared for  all
    Microsoft platforms released since 1995.  However, because of  the
    large number  of platforms  that must  be tested,  the patches are
    not available at this writing.

    MS urges customers to take some or all of  the following  steps to
    protect themselves  should they  encounter hostile  code signed by
    one of the certificates.
    - Visually  inspect  the   certificates  cited  in  all    warning
      dialogues. The two certificates at issue here were issued on  29
      and  30  January  2001,  respectively.   No  bona fide Microsoft
      certificates were issued on these dates.  The FAQ and  Knowledge
      Base  article  Q293817  provide  complete details regarding both
      certificates.
    - Install the Outlook Email Security Update
      (http://www.officeupdate.com/2000/downloadDetails/Out2ksec.htm)
      to prevent  mail-borne programs  from being  launched, even  via
      signed  components,  and  install   the  Office  Document   Open
      Confirmation                                                Tool
      (http://officeupdate.microsoft.com/downloadDetails/confirm.htm)
      to force web pages  to request permission before  opening Office
      documents.
    - Consider temporarily  removing the VeriSign  Commercial Software
      Publishers CA certificate from the Trusted Root Store. Knowledge
      Base article Q293819 provides details on how to do this.