We’ve been getting some interesting responses back from the AutoCAD Security Survey that has been posted over on the AutoCAD Futures beta forum. (If you haven’t already responded, we’d appreciate you taking the time to do so: it’ll probably take you less time than reading the rest of this blog post. Then please come back and finish reading this, too. ;-) The survey is intended to gauge whether the safeguards we first introduced in AutoCAD 2013 SP1 (and then further enhanced with the SECURELOAD mechanism in AutoCAD 2014) are properly understood and considered valuable.
From some of the feedback we’ve seen so far from the survey, it seems there are people out there who have concerns that introducing a JavaScript API somehow increases AutoCAD’s vulnerability to malicious code. I suspect this is due to the general sense that accessing the Internet is somehow what causes malicious code to infect computers, and that desktop software is inherently safer in nature.
This isn’t quite right. Yes, having computers connected to the Internet does increase their chances of being infected by malware, but it’s just one way of getting malicious code onto your system: aside from the obvious risks of malware coming across on pluggable media (CDs, DVDs, USB keys, etc.) recent research shows that it’s now possible to bridge the air gap, which is just plain scary.
Ignoring that last point, for now, system security ultimately comes down to trust. If you’re running AutoCAD on Windows, you (or perhaps your IT department) have placed trust in Microsoft and Autodesk to provide executable code that behaves in line with your expectations. Every time you install additional software onto your system – or open a DWG file that has been sent to you, more on this later – you are trusting the source of those bits.
Operating systems – especially those in the mobile space – are increasingly sandboxed, which means applications don’t have access to the APIs that could do naughty things on your system (sometimes the user gets the chance to approve or veto, sometimes the APIs are simply not there). This is also partially true on the desktop – where users can run with limited privileges – but to a far lesser extent.
Desktop AutoCAD does not run within an OS sandbox and neither does it provide nor enforce use of its own sandbox for applications, so application code that executes inside AutoCAD generally has the privileges accorded to the current OS user. As an AutoCAD user, you need to think carefully before running any custom application code inside AutoCAD, irrespective of the mechanism used to get it onto your system.
Software vendors are increasingly providing curated online marketplaces (a.k.a App Stores ;-) in an attempt to address both the discoverability of applications but also to increase the level of trust users have in them: typically some level of QA has been performed by the vendor to decrease the chances of these applications doing bad things. This is certainly true of Autodesk Exchange, for instance.
Running a custom module that happens to access the internet to download HTML and JavaScript which then gets executed locally isn’t fundamentally less secure than local executable code. In fact the nature of our hosting means that the code can run in the browser sandbox and only call into a limited set of functions that we make available to it. Alright, so these functions allow the HTML/JavaScript to call into .NET or native code, whether exposed as a callable function or a command, but then the application modules need to be present (and trusted) to provide these functions.
And the user isn’t free to browse to any web-page from an AutoCAD-hosted HTML dialog: it’s the local .NET or ObjectARX application that decides which pages to load into the browser, and if that application is doing something malicious then it’s much simpler to do so directly than loading a web-page to do it.
We introduced the SECURELOAD system variable to make people think carefully about the source of the application code they’re loading and running. If you don’t know or trust the source of executable code then you should not run it. Although it’s possible to do so – and it removes the annoyance factor of seeing this dialog on a regular basis – you should not disable the SECURELOAD feature. You should configure it to load modules you trust automatically but leave it enabled, otherwise.
The same goes for drawings you receive from untrusted sources: people may not realise this, but security researchers have found vulnerabilities in our DWG processing code (which have since been patched for AutoCAD 2011-2014 and fixed in AutoCAD 2015) that could allow users to execute malicious code that’s delivered as part of a specially crafted DWG file. We have a team focused on shoring up AutoCAD’s security to reduce the risk associated with this kind of attack, but this is really to point out that users need to think about trust whenever they load an application or open a DWG file from an unknown source.
In the next post I’m going to give some more context as to why all this matters (I would have included it here, but today’s post is already long enough). I’ll also introduce some resources that will hopefully make you think differently about security, as well as serving as some really interesting summer reading (honest!).