Community
You can sign your own code, and declare yourself trusted to yourself.
Hopefully malicious code publishers will not be declared trusted for the general public by the certification authorities.
And, if they turn out to be malicious later on, the trust can hopefully be revoked.
Dear Neil,
I just received another developer query, critically urgent, on digitally signing your Revit add-in, with the ADN case number 12147397:
We have a client that is deploying Revit 2017 and addins using Microsoft System Centre software.
They ran into the following issue: when users start Revit they are prompted to verify the addins; this is expected for the first time.
However, when the user selects 'Always Load' the addins, this choice only remains valid for that single session.
If they close Revit and reopen Revit, they are prompted again to verify the addin.
Where does Revit store the addin credential information?
Can we check whether it is being stored correctly?
This problem is affecting digitally signed Revit addins from multiple developers and publishers.
The same addins work as expected ("Always Load" selected only once) on other computers that don't have the software deployed with MSC.
This issue is holding up the deployment of Revit 2017 to over a hundred computers within the organisation and therefore is absolutely critical for us.
Do you have any advice how this can be resolved?
Thank you!
Cheers,
Jeremy
I just received an update from the developer saying that the issue is presumably solved.
Check the Certificates setting:
Internet Explorer -> Tools -> Internet Options -> Content -> Certificates -> Trusted Publishers
Is the published listed under Trusted Publishers?
If not listed, you will be prompted each time…. This could be the cause of the issue.
Cheers,
Jeremy
A non-technical analogy might be a good place to start…
Imagine a situation where someone tells you that it is going to rain tomorrow. Should you trust that statement? Questions you might ask yourself are:
• Who is telling me this information?
• Do I trust this person to have accurate data and repeat it accurately to me?
It is easy to imagine ways to answer the first question. You may personally know the speaker, check their ID, have a friend vouch for them, etc… But the second question is trickier. Source credibility has as much to do with the person receiving the data as the person transmitting it. While some people tend to be viewed as more credible than others, nobody is viewed as always credible by everyone. The second question gets even more complex when you start wondering where this person obtained their information. Did they get in a plane and view the weather patterns for themselves? If they got the information from a source, you must now make assumptions about how trustworthy that source is. Generally, determining whether you trust a person is a complex process.
Code signing answers the first question. When you load an add-in, Revit can look at the signature and tell you who wrote that code. Assuming that the author's private key hasn't been compromised and that the CA did their job properly, that is an accurate statement. But we can't know if you trust that person/organization or how much you trust them.
There is a famous case of Adobe's code signing key being used by attackers to sign malware. Adobe had incredible security on their private key, keeping it in an HSM. But the attacker was able to infiltrate their infrastructure, get their malware signed, and then distribute the signed malware. If a user had previously checked "always trust from this publisher" during an Adobe installation, the malware would have been installed silently. Users who didn't check that box would have gotten the trust this publisher dialog, and given a chance to wonder why "Adobe" (actually malware) was installing something on their computer.
Clearly the Adobe case is extreme, but I think it helps illustrate the point that determining the trustworthiness of the code signer is not something that can be done programmatically. There is no algorithm for trustworthiness that doesn't involve the user's personal viewpoint (eg: perhaps a government worker trusts things signed by the government while a private citizen may choose to be more circumspect of their government). So we're left prompting you, asking for your opinion on trust.
Ensuring that only trustworthy certs are in the Trusted Publishers cert store is a problem that Windows and users manage outside of Revit. The only way to get a bad cert there is to have malware run on the computer under the current user or for the user to download a cert and install it. At that point, the best option is to consider the computer compromised and to wipe and reinstall the OS (AKA: nuke it from orbit). The trust store is the definitive source of trustworthiness for Revit, and for Windows in general.
A similar situation arises in browsers. They have a cert store that tells them whether to trust a CA for signing SSL/TLS certificates. A default set of certs comes with the browser, and users can modify that set. But the browser always trusts the cert store. The infamous Lenovo-Superfish scandal occurred because Lenovo was adding untrustworthy certs to the cert stores on computers that it sold.
Neil Smithline
Revit Software Security Architect
Regarding
This whole thing is so silly. I mean its a Revit addin we are talking about here, not an attempt by Anonymous to destroy everything Revit in architectural firms all over the globe.
as Matthew Taylor points out, that is not the case. The AutoCAD Medre virus stole 100's of thousands of documents and emailed them to China. But the threat being real doesn't justify a lacking implementation on our part.
While we made every effort to sign all Autodesk add-ins, it sounds like we missed a few. In general, if an Autodesk add-in is not signed, that should be treated as a bug and reported to Autodesk support so that we can fix it. I'm unfamiliar with the Roombook add-in, but I'll see that it gets signed.
Unlike Windows, Revit has a mechanism for remembering that you've said "Always Load" on an unsigned add-in. If that box isn't working for you, whether the add-in is signed or not, that is a bug (provided that you're not updating the add-in between uses). Besides just being unfriendly, as Matthew points out, repeatedly seeing that dialog leads to user fatigue. This contributes to users making bad security choices when a dialog is presented for a real threat. (Even I find myself reflexively clicking the "OK" buttons on security dialogs - very bad.) In short, I view excessive dialogs as a security problem that we must fix. I'm not exactly how to investigate this problem further. I'll talk to our support organization and someone will get back to you.
Neil
PS: I think I've already mentioned this, but I'll repeat it: I think that code signing and user prompts are not a great design. They interrupt workflow and rely on users making difficult decisions based on limited information. Not a recipe for success. Unfortunately, code signing and user prompts are state of the art. Windows, Linux, and MacOSX, along with major browsers use this mechanism. We'll continue to fine-tune our implementation and investigate alternative technologies as they become available.
Neil Smithline
Revit Software Security Architect
Regarding:
@matthew_taylor wrote:
That said, I think the 'always load' label is misleading.
I think the labelling is generally a little odd. It's about trusted publishers, not about trusted add-ins...Well the add-ins are trusted because they have a trusted publisher.
I agree that "Always Load" is a _bit_ misleading when you are prompted for allowing a signed add-in as you are actually permitting all add-ins from this publisher (well, actually from this publisher when signed with this certificate). On the other hand, "Always Load" is exactly what we mean when you are prompted for an unsigned add-in as selecting it will only permit that add-in to be silently loaded in the future. After quite a bit of usability research (we may have spent as much time designing the dialog as we did implementing the cryptography), we felt that this distinction was small and unimportant to most users and that consistency between dialogs for signed and unsigned add-ins was more important than 100% accuracy.
I'd be interested in hearing if you see any serious problems with the wording or dialog design. Especially if you feel that the current design leads to users making bad security decisions.
Neil Smithline
Revit Software Security Architect
Hey Jason - I've been trying to reproduce the Roombook problems that you are having and can't. The add-in loads silently for me. I also tracked down the responsible party in Autodesk and they are unable to reproduce it as well. I am using Revit 2017 and the Revit 2017 Roombook extension. I'm not sure if it makes a difference, but I downloaded the extension from the Autodesk Desktop App. What versions are you using? Is there any other information that you can think of providing to help us reproduce the problem?
Neil Smithline
Revit Software Security Architect
Forums Links
Can't find what you're looking for? Ask the community or share your knowledge.
Post to forums
