For my recent column on code signing I took a close look at the Trusted Root Certificates dialog on one of my Vista systems and noticed something odd.
The selected certificate is one of two Symantec certificates. Three things are of interest, and you can see the first two in the picture: The purposes for the certificate are "". Usually certificates are listed as being used for a more limited set of purposes, such as server authentication or code signing. Also note that the "Friendly Name" field is empty. This means that the certificate was a "roll your own" version generated by Symantec themselves rather than one issued by a trusted certificate authority like VeriSign or Thawte.
But the really interesting thing is that there are no Symantec products on this system. There had been some on it but I removed them after they made the system unstable. I used the Norton Removal Tool, which is supposed to do a complete lobotomy on Symantec products on the system, to uninstall them. (Symantec conceded that the problem was caused initially by a bad update they pushed down. By the time a fix was issued I was already fed up and removed the software.)
So it looks like the Norton Removal Tool leaves the certificates on the system. This is probably not that much of a risk, although it would be better if the certificates weren't there (I'll remove them myself later). The attack scenario, I guess, is that someone at Symantec loans their private key to their brother-in-law who uses it to sign malware.which shows up to the user as having been signed by Symantec.
Not likely I guess. It does underscore how, to trust a signature, you really need to look up the certification path. Since it's unrealistic to expect normal users to do that the system as a whole (at least on 32-bit Windows) is disappointing. Things are a little different on 64-bit Windows.
The selected certificate is one of two Symantec certificates. Three things are of interest, and you can see the first two in the picture: The purposes for the certificate are "
