Signed Malware, Revoked
Posted by Craig H on 16 July 2009
A number of blogs and news sites have picked up on a report from Dancho Danchev last week, identifying some malware that was submitted to, and signed by, the Symbian Signed portal.
As soon as we were notified of that (the following day) we revoked both the content certificate and the publisher certificate used to sign the malware. That means that the Symbian software installer will not now install the malware, providing that revocation checking is turned on. Unfortunately, revocation checking is often turned off by phone manufacturers, because the data traffic could cause problems for people who do not have a data plan as part of their service or who pay for data by volume.
Here’s how to turn on revocation checking, which we strongly recommend if you have a flat-rate data plan:
On S60 3rd and 5th edition, the setting to turn on revocation checks can be found in the application manager, for example:
App. manager →
Online Certificate Check
On UIQ 3, the setting to turn on revocation checks can be found here:
Control Panel →
Enable Revocation Check
Please note that applications not signed by Symbian Signed may not include the URL for the revocation check in the signing certificate. In these cases, the software installer can direct the revocation check request to a default URL, however at present there is no server in place able to respond to such default requests, so the default URL should be left unset.
So that applications not signed by Symbian Signed (for example, those signed by the phone manufacturer, or self-signed by third parties) can still be installed, the revocation check should not be set to mandatory (for example, “Must Be Passed” for S60), it should be left as advisory (for example, “On” for S60).
We do have security measures which try to catch submitted malware before it gets signed, and we are currently investigating how those can be improved in the light of this latest incident.
Footnote: Earlier today we found that, due to human error in processing the revocation, it wasn’t being properly reported by the server. This has now been corrected.