How do I use acaddoc.lsp during startup?

[BlackBox]

There's less security issues with acad.lsp and acaddoc.lsp now that we have the Support File Search Path. While bundling a plug-in for an Exchange App makes sense, it doesn't make sense to me for managing office settings and lisp. If there's something I'm missing let me know.

I respectfully disagree, my friend.

The in-built mechanism that automagically loads Acad.[lsp[fas[vlx]]] and AcadDoc.[lsp[fas[vlx]]] user files is hard-coded to first search DWGPREFIX prior to searching Support File Search Path (SFSP)... This inherently introduces more security risk. Whereas if the order of operation were to instead first search SFSP (you know, those hard-coded Profile-specific paths that a CAD Admin had the forethought to plan out, implement, and manage), and only if none are found, then search DWGPREFIX, myriad users who employ these user files would have avoided the entire 'acad.lsp' virus/worm scenario and never even have known about it. Those who did not, would still have been vulnerable.

I've even gotten Autodesk staff to confirm, and acknowledge this fact, and still no change to the code-behind the FindFile() Method (which is what causes this).



Autoloader, as I've shared elsewhere, is actually quite good at the few things it does correctly; it has some trade-offs in terms of operation.

That said, in the context of Security, Autoloader is very much a continuation of the same, extremely flawed approach to security. Firstly, you're not going to 'turn off' this feature as even AutoCAD loads its own .bundles now to some extent - and don't expect that to reduce moving forward.

Autoloader is extremely useful for internal, or proprietary apps that makes it easy to manage, and support all APIs, CUIx, and even Tool Palette upgrades, by simply changing the UpgradeCode XmlAttribute's value (GUID string). The one shortcoming to this mechanism, is that it is still relegated to Client/user local disk - the Autoloader mechanism does not search/load SFSP to find ..\ApplicationPlugins\ on the network, as example. These locations are hard-coded. That said, it's pretty easy for one with sufficient IT permissions, to edit ..\NetLogon\<YourLogonScript>.bat to 'push' network saved copies of all internal .bundles to user's local disk at logon.

The trade-off is that despite SECURELOAD, any Autoloader .bundle found within the multiple ..\ApplicationPlugins\ locations is implicitly trusted (which means it entirely bypasses SECURELOAD even if enabled), and the mechanism isn't even smart enough to check for Hidden, etc. folder Attributes prior to loading. Ergo, instead of being relegated to the AutoLISP, and Visual LISP (ActiveX) APIs via Acad.lsp, etc., malicious code can now access ALL APIs that AutoCAD supports (i.e., .NET, JavaScript, ObjectARX [C++ for AutoCAD], etc.).

So the teams that developed Autoloader (left hand), and SECURELOAD (right hand), didn't exactly get together on how the final product would operate in a more complete sense, IMO.

Cheers

[Tom Beauford]

Seems to be security problems no matter what you use, here's hoping it will all be fixed in 2016 (Fat Chance!). Copy any file from the support path like ssx.lsp from the Express folder to your Documents folder and enter (findfile "ssx.lsp") at the command line and it will find it in the Documents folder first in every version of AutoCAD. It's probably the least secure folder on any computer. Of course including the path of the current drawing path doesn't make any sense either.

It may be a Microsoft issue out of AutoCAD's hands. Anyone with Windows 8.1 know if AutoCAD has the same issue with it?

Since I watch for the messages I've placed at the end of acad.lsp and acaddoc.lsp to let me know they were loaded correctly at least I'd have some warning if another one of them was loaded instead.

I never claimed acad.lsp and acaddoc.lsp WERE secure, just that it's gotten better. Microsoft claims dropping VBA in favor of NET made it more secure as well. I would not download the no longer included VBA support for AutoCAD because of that. Acad.lsp and acaddoc.lsp are still listed in 2015 as the files for loading lisp in help. Get a lot of drawings from consultants, but have never encountered an AutoCAD virus. Partly from being careful and part from being lucky I guess. I'll probably keep doing it the way AutoCAD says to do it till someone convinces me otherwise.

[rkmcswain]

I can test Win8.1 later today, but I suspect it's the same.

Get a lot of drawings from consultants, but have never encountered an AutoCAD virus. Partly from being careful and part from being lucky I guess.

^^^^ I agree with that

[Tom Beauford]

I can test Win8.1 later today, but I suspect it's the same.

Thanks, Microsoft claims every new version that security is worlds better than the previous one. Figure it's possible anyway.

[BlackBox]

Seems to be security problems no matter what you use, here's hoping it will all be fixed in 2016 (Fat Chance!). Copy any file from the support path like ssx.lsp from the Express folder to your Documents folder and enter (findfile "ssx.lsp") at the command line and it will find it in the Documents folder first in every version of AutoCAD. It's probably the least secure folder on any computer. Of course including the path of the current drawing path doesn't make any sense either.

One of the Autodesk software architects, and I disagree on local vs. network... They feel that network is less secure, and local is more secure, and I categorically reject that assessment. Network is planned out, managed, and has exponentially more user permissions disabled in comparison to local. Typically in any domain environment, it is the client (local) that gets infected first, which contaminates any aspect of one's domain (network).

... Here's for horses drinking water.

It may be a Microsoft issue out of AutoCAD's hands. Anyone with Windows 8.1 know if AutoCAD has the same issue with it?

I just implemented our new Windows Server 2012 R2, and Windows 8.1 Enterprise environments for our daily work - no change.

Since I watch for the messages I've placed at the end of acad.lsp and acaddoc.lsp to let me know they were loaded correctly at least I'd have some warning if another one of them was loaded instead.

Adding your own message is a good idea; I've done so for many moons, and was how I was able to identify an 'infection' once upon a time with my previous employer.

I never claimed acad.lsp and acaddoc.lsp WERE secure, just that it's gotten better. Microsoft claims dropping VBA in favor of NET made it more secure as well. I would not download the no longer included VBA support for AutoCAD because of that. Acad.lsp and acaddoc.lsp are still listed in 2015 as the files for loading lisp in help. Get a lot of drawings from consultants, but have never encountered an AutoCAD virus. Partly from being careful and part from being lucky I guess. I'll probably keep doing it the way AutoCAD says to do it till someone convinces me otherwise.

Didn't mean to put words in your mouth, if that's what I did... Merely intended to point out how it really introduces risk even if you do not currently use such files.

During that lil' 'infection' I mentioned, when I finally figured out what was going on, a coworker was unknowingly infected with a self-replicating Acad.fas worm that just happened to exists in an archive project folder he was perusing for line work on a nearby project. Thanks to some sources that shall not be named, I was able to decrypt the .FAS file and read through what it was attempting to do. It first checked to see if it existed in the application's local support folder, and if not, then replicated there, and same for DWGPREFIX marking both files with the Hidden Attribute. So what you ended up with is a worm that ensured it existed in both locations for every user that opened any drawing anywhere in the network, and was hidden from view unless you had Hidden files turned on in Explorer.

This lil' 'infection' took over my office, crossed the state, and spread into several other states from Main to Florida in one day before I identified it, and brought it to corporate IT's attention.

As a direct result of that issue, I developed my first Autodesk Exchange app named Blacklist (originally named Antivirus for AutoCAD(r) back in 2012, but was rejected by Autodesk Exchange reviewers as AutoCAD Security was being rolled out in AutoCAD 2014), that allows a CAD Admin to specify specific file names, or extensions that are not to be allowed to load at all. As this .NET code is executed at Initialize() (aka before any of the Acad* files are loaded in the startup sequence), the DWGPREFIX, working folders (if any), and SFSP are iterated and the app 'blacklists' in place any matches that result, with the ability to specify only blacklist local, network, or both.

The 'blacklist definitions' exist in a user-defined XML file that can be located in the .bundle as-is, or can be moved to a network (read-only) folder location in order to support multiple user environments, as I hard-coded it to search SFSP prior to .bundle, etc..

This app immediately stopped all subsequent infections.

I was so p!$$ed off by the ridiculous changes Autodesk Exchange reviewers wanted me to make to the app - host a library of all known virus definitions on my website, that automagically pushed any updates to all customers without their consent, permission; hello, Acad.lsp, and AcadDoc.lsp are the most common two 'virus' definitions, can you imagine what sort of angry emails I'd receive if I actually did something like that!? So, I use my plug-in, and I don't get infected by traditional means... Perhaps when the next big infection hits I'll deal with such topics again. *shrug*

Cheers

[Tom Beauford]

Thanks, didn't have that much hope for 8.1, Blacklist app sounds great.

[BlackBox]

... didn't have that much hope for 8.1

I actually love Win8.1; particularly from an elevated perspective of managing multiple users, client/server machines, and alpha/beta testing different software, Win8.1 is fantastic - hello, Client Hyper-V (built-into the OS).

Blacklist app sounds great.

Thanks; they're short-staffed right now, so perhaps I can bite my tongue about the existing shortcomings long enough to squeeze this app onto the Exchange apps shelf.

Cheers