After I mentioned in an earlier post that I had digitally signed the sample LISP file I had provided, this generated some interest. In this post, I’ll explain why you might want to sign your LISP files. In a later post, I’ll explain how to do it.
These days it is standard practice for developers to digitally sign their code. Operating systems and applications are displaying increasingly scary warnings when coming across unsigned code. Here is an example of the sort of message you get when you load an unsigned LISP file into AutoCAD from a location that has not been explicitly configured as a trusted location:
If you’re a CAD Manager dealing with your own internal code, it’s not too onerous to configure AutoCAD in Options > Files such that a folder is trusted by AutoCAD and place your code in there. The folder should be read-only; if it isn’t, AutoCAD warns you when you try to configure it. If you do this, the scary warnings don’t appear to bother and confuse your users, even if your code is unsigned.
Another way a CAD Manager can avoid the warnings is to set the SECURELOAD system variable to 0. That’s generally not recommended because it turns off AutoCAD’s security features. While you’ll probably get away with this, there’s always a chance that a user will load some malware and then you’ll have to explain yourself to management.
If you’re not just using your code internally and it’s going to be used by other parties, then you’re not going to have that level of control over the user environment. In recent AutoCADs it’s possible to set up the installation deployment such that users can’t turn off the security settings. If the CAD Manager at the location using your code has done this, your potential users are going to be presented with unprofessional-looking scary warnings.
If you sign your code, users might still get a warning, but it’s less scary. It identifies you as the verified source of the code so they will have more confidence in picking the Always Load button. Once they’ve done this, other signed code of yours will be automatically trusted.
There’s another important reason you might want to sign your code, and that’s protection against other people’s modification of your code. If somebody edits your LSP file and then gives it to someone who tries to load it, the user is presented with an even scarier warning:
Note that this warning no longer has your name on it. This means it’s possible to protect yourself from people (internal or external) who well-meaningly hack about with your code and then try to blame you when it goes wrong. It also gives a level of protection against your code being infected by malware.
Note that all of the above only applies to AutoCAD 2016 and later. AutoCAD 2014 introduced some LISP loading security measures, but the signature stuff came a couple of releases later. Earlier AutoCAD releases, along with compatibles such as BricsCAD and ZWCAD, will just ignore the digital signature. It’s just a comment in the code as far as they’re concerned.
LISP files with the LSP, MNL, FAS, or VLX file extensions can be digitally signed. There’s a bug in the original iterations of AutoCAD 2016 and AutoCAD 2018 that prevents signed VLX files from working. This was patched later in both releases (2016 SP1 and 2018.0.2), but if you’re distributing your code externally there’s always a chance that your VLX might end up in the hands of somebody using a broken release. Also, VLX files that are digitally signed cannot be loaded into AutoCAD 2015 and earlier, broken or not. You should bear that in mind before distributing signed VLX files. I don’t do it and would advise against it. Thanks, Autodesk.
Given this information, if you decide that signing your LISP is a good idea, watch this space for information on how to do it.
Great explanation Steve. This signing feature has to be one of the oddest I have seen from them in a while. If there were common malware attacking acad, it would make sense. There is only one instance I know of, that falls anywhere near this category and its the bad acad.lsp that was getting passed around. The only reason it was able to run, was its one of those specially named files acad loads on startup, AND acad looks for it in drawing folder BEFORE using support paths. That was the killer. I told them that a thousand times and I think the latest versions have settings to not load startup files from drawing folder. Took like 4 releases to get there. But then we still have the excess reg app problem which is 100x worse than any security issue, and they leave it alone. The real problems are resulting from dwg structure that transmits things like app ids, anno scales, and materials from dwg to dwg automatically through wblock or xreffing.
Yes, I told them about the implied path thing being the biggest problem a thousand times too. Must have been 10 or 12 releases ago.
It was low hanging fruit – something that could easily have been done at low cost and large benefit. I guess the fact that it was eventually done makes this a better-than-average AutoCAD feedback experience.
Steve, have you heard of any other malicious code happening in acad besides acad.lsp and its brothers (acaddoc.lsp….)?
You mention signing being standard practice, but not for macros and things LISP is used for in my experience.
Autodesk cannot give examples of actual malicious code, and they say “if we told you, you might use it” BS.
You can tell I feel they drummed up fear to make their feature important. Reality is some paying client demanded it so they all of a sudden got motivated to add it and them pumped the advertising like its what we always wanted.
acad.vlx in a zip is the traditional vector for malicious AutoCAD code but there are several other possibilities. One of the other vectors is going to be written about here later by a guest poster, if all goes according to plan.
I’m sure you and I could easily produce our own malicious code examples.
But yes, it’s important to get the risk into context, and right now it’s not significant for anyone who has the implicit path feature in its default turned-off state and who doesn’t go running stuff blindly.