SECURELOAD will not work in a Reactor

[tommy.holder]

SECURELOAD will not work in a Reactor... Using AC2014 and in an effort to prevent users from loading other than company approved programs and macros we aretrying to monitor “SECURELOAD” when it changes using a reactor and force/set it to something else but it does not work. It just return the word "SECURELOAD" and the number set following at the Command prompt.. I have read the Bundle white pages. Studied all information in AC2013 and AC2014, I have taken the AU class on security. Attened the discussion groups at AU as well. But there is something missing in this process of security. It is, "How do we prevent users from loading code into AutoCAD once started?". . Our goal is to load only company approved code and prevent user loading of personal preference or pirated code. We want them to draw not add code or bring stuff in that has not be reviewed. We are SOX compliant and have to prevent this. Let alone the possible idea of being busted for using code that could bring fines to the company. . We were hoping with the new release of AC2014 and the Secureload features that it would be possible to monitor this system variable and when changed from other than 2 we set it back. . The reactor and results of running the reactor shown below: Ideas to do this are welcome!!! . (vl-load-com) (defun c:CKSL () (if *SECURELOADReactor* (progn (vlr-remove *SECURELOADReactor*) (setq *SECURELOADReactor* nil) (setq SECURELOAD:Callback nil) (prompt "\nReactor stopped. ") ) (progn (setq *SECURELOADReactor* (vlr-sysvar-reactor ;I have tried also “vlr-editor-reactor” "" '( (:vlr-sysvarchanged . SECURELOAD:Callback) ) ) ) (defun SECURELOAD:Callback (rea var / varName) (if (and (wcmatch (setq varName (strcase (car var))) "SECURELOAD") (cdr var) ) (setvar "SECURELOAD" 1); Problem is it just writes to the command line “SECURLOAD” 1. Like it doesn’t see setvar ;;; (alert ;;; (strcat "\n[App Event] : System Var Changed\t\t: " varName) ;;; ) ) ) (prompt "\nReactor started. ") ) ) (princ) ) ACAD Text Window (F2) results follow: Command: CKSL <-- Manual execute of the reactor Reactor started. Command: Command: 'VLIDE Command: Command: SECURELOAD Enter new value for SECURELOAD <1>: 0 <-- changed the value manually. ; error: AutoCAD variable setting rejected: "SECURELOAD" 1 <-- Results of reactor -->but works if SECURELOAD is replaced with another sysvar like FILEDIA sysvars. Please consider this as a positive feature. Tommy Holder

[dbroad]

I don't think you can prevent a drafter from loading code he intends to load.  You could track the loads and do random audits to find the employees that are not playing by the rules.

I also don't see how this has anything at all to do with Sarbanes-Oxley.  It's about getting drawings done efficiently and accurately. Sarbanes-Oxley is about accurate and honest record keeping.

As a sole-proprietor, the first thing I did was to turn off SECURELOAD.  IMO it adds nothing to the security of the system and is only a false promise of increased security.  For instance, a reactor that could turn on/off SECURELOAD would make it self evident that it doesn't work.

[BlackBox_]

I recently addressed a similar topic here, that may or may not be informative.

Even within a .NET event handler, one must wait until the Application.Idle (as an example), before one can successfully modify SECURELOAD (there may be an earlier event, but that was for demonstration only)... Even still, the code that was loaded, has already executed, malicious or not.

Also worthy of note, regarding SECURELOAD, you might consider this post.

Cheers

[dbroad]

In addition to what I (and Blackbox) already said:

1) A sysvar reactor cannot be used to change the variable that triggered it within that reactor's callback. (Basic reactor guidelines)

2) Even with SECURELOAD set to 2, a user could load a lisp program from another non-company, non-secure folder by using VLIDE.

3) A user could easily disable a functional sysvar reactor by using (vlr-remove-all) at the command line.

4) When posting code on this website use the code button on the posting editor or as txt attachment.

5) “It is impossible to make anything foolproof because fools are so ingenious.” source unknown

This is a solution (that demonstrates proper reactor technique only).  It does not guarantee anything.

(vl-load-com)
 ;|Start a sysvar reactor to track and hold values of critical
variables. Add the variable (all caps) and the preferred value
of that variable as a dotted list to the data element of the
reactor.  Secureload is being monitored here.
Expectations:
This reactor can be disabled by a single (vlr-remove-all) by a
knowledgable user.  The secureload warning can be ignored by
someone wanting to load certain programs.  It is assumed that
the user is using a (load "") form to load his programs and
that a lispreactor would be sufficient to turn the variable
back on.  It may be necessary to add other reactors such as
a command reactor to manage and hold variables other than
secureload. I would suggest tracking the commandended,
commandwillstart, and commandcancelled events for completeness
for other variables.|;

;;D.C. Broad, Jr.  APR 2014

(if (= (type svmon) 'VLR-SysVar-Reactor)
  nil
  (setq	svmon (vlr-sysvar-reactor '(("SECURELOAD" . 2))
				  '((:vlr-sysvarchanged . checkvar))
				  )
	)
  )
(vlr-add svmon)

(defun checkvar	(r l)
;;;uncomment next line to see the reactor in action.
  ;;(alert "checkvar") 
  (if (setq v (assoc (car l) (vlr-data r)))
    (progn (vlr-remove r)
	   (vlr-lisp-reactor v '((:vlr-lispwillstart . resetvar)))
	   )
    )
  )
(defun resetvar	(r l)
  ;;(alert "resetvar")
  (vlr-remove r)
  (setvar (car (vlr-data r)) (cdr (vlr-data r)))
  (vlr-add svmon)
  )

[tommy.holder]

dbroad, This Sarbanes-Oxley issue is stretching it a bit but is an IT requirement for maintaining complete and accurate records of code developed preventing shadow programming. Good idea on aduiting the users. May be more work than value but worth a look. As for the secure load, it does what it's planned to do. But in a company where loading priated code could cost the company and malicious code possiblities could affect the network this is a must. Especially if the boss says find a solution. So I am reaching for possible solutions. Thanks Tommy

[tommy.holder]

BlackBox_ , Thanks - I was wondering if you have tried to monitor the Registry for the change and change it back in the registry. But you comments on bundles puts the nail in the coffin so to speak. So there is not anyway to completely prevent this so I am done. At least until Autodesk offers a better solution. v/r/ Tommy

[BlackBox_]

---

@tommy.holder wrote:
dbroad, This Sarbanes-Oxley issue is stretching it a bit but is an IT requirement for maintaining complete and accurate records of code developed preventing shadow programming. Good idea on aduiting the users. May be more work than value but worth a look. As for the secure load, it does what it's planned to do. But in a company where loading priated code could cost the company and malicious code possiblities could affect the network this is a must. Especially if the boss says find a solution. So I am reaching for possible solutions. Thanks Tommy

---

You can mitigate risk, but especially if you're using AutoCAD 2012 or newer, you're unable to prevent potential malicious code. Period. The new Autoloader mechanism is implicitly trusted (which automagically bypasses any, and all measures you implement as part of your deployment, see the 'security' link in my siganture for more info), and worst, Autodesk considers the local disk (you know the one first possibly infected via infected folders, and has direct access to Al Gore's Interwebs) as being safer than files/folders on your own internal IT maintained network. Your best defense is a well organized deployment, and educated users.

FWIW - I'll offer you a comment I once offered Autodesk, regarding AutoCAD Security: 

---

Coming from the Military myself, the security gamble isn’t about preventing exploitation of all possible vulnerabilities... It’s about securing your weakest points in critical order for mission accomplishment, controlling the flow of information, early warning system redundancy, and something that even the lowest ranking Soldier knows... Overlapping fields of fire.

---

Cheers

[tommy.holder]

understood - will attach in the future - thanks for you and Blackbox for your insgiht. This will help be close this task as a noty doable at this time. But I will experiment with both of your suggestions. If I work out a solution I will post them. Best Regards, Tommy

[BlackBox_]

---

@tommy.holder wrote:
BlackBox_ , Thanks - I was wondering if you have tried to monitor the Registry for the change and change it back in the registry. But you comments on bundles puts the nail in the coffin so to speak. So there is not anyway to completely prevent this so I am done. At least until Autodesk offers a better solution. v/r/ Tommy

---

I missed this post, when I posted my latest comments....

Registry monitor is where I was headed next in concept, but I wanted to first explore other events within AutoCAD first (i.e., only make it as complex as needed)... All we're trying to do, is disallow LISP, etc. from being able to disable an otherwise 'secure' environment.

The crux of Autoloader, is that is doesn't adhere to AutoCAD security at all. Speaking both as a CAD Admin, and a published app developer, I'd hate to see users locked out of write permissions for these app-dependent folders simply on the basis that it is possible for malicious code to write a new .Bundle (given that Autoloader doesn't even bother to check to see if a given .Bundle is read-only, or hidden, etc., nor do users necessarily check what has/hasn't been added prior to launching AutoCAD).

Again, your best defense is educated users, and a reasonable early warning system (whatever that means in the context of your employers environment)... There are steps you can take, so I wouldn't write this off just yet, but I didn't want you to misunderstand the extent which you could pursue this specified task (and all those implied tasks) while managing your employer's expectations.

I'd still encourage you to to what you can, where you can, and continue to explore other means by which to entrench your deployment against potential risks as you see fit.

Cheers

[tommy.holder]

Good Advice - thank you - Tommy

[BlackBox_ · Accepted solution]

---

@tommy.holder wrote:
Good Advice - thank you - Tommy

---

That is kind of you to say, Tommy; you're welcome.

[dbroad]

Glad I was able to help.  Training of your employees is the key to your security.  As long as everyone cooperates, reactors can be an element in the protection but should only be used with the awareness of the weaknesses.

Blackbox - Your referenced posts and discussion was helpful as well.  I didn't know about the built-in holes of the applicationplugins.

[BlackBox_]

---

@dbroad3 wrote:

Blackbox - Your referenced posts and discussion was helpful as well.

---

That is kind of you to say, dbroad; I'm happy to help.

---

@dbroad3 wrote:

I didn't know about the built-in holes of the applicationplugins.

---

Both Autoloader & Security are good at what they do individually, but there seems to be a bit of a 'left hand not talking to right hand' scenario in the finished result, IMO.

From a security standpoint, the ..\ApplicationPlugins\ folder(s) ultimately are unprotected and introduce potential risk (just as Acad.lsp did before it), and from a user/developer standpoint these folders are incredibly valuable for ease of app distribution and offer the promise of productivity gains through innovation... I think there's a middle ground to be had, I just don't think we're there yet.

AutoCAD Security is from the outset a process of evolution, that to be effective, inherently must walk the fine line between maintaining awareness & protection against potential threats, and must avoid any negative affect on user, or user's workflow in the process... At present, Autoloader & Security are mutually exclusive.

As a loosley related security example that predates all of this....

Something so simple as changing the order of operation for the mechanism that automagically loads Acad.[lsp[fas[vlx]]] and AcadDoc.[lsp[fas[vlx]]], such that either file located within SFSP (only if found), take precedence over that which may be found in DWGPREFIX, would have saved countless users literaly decades of Acad* file virus & worm exposure... Yet even with Autodesk staff in agreement (I may have mentioned it a time or two in the past), nothing has changed.

... My $0.02

Cheers

[tommy.holder]

Thanks for sharing your thoughts. I have not had any luck working to a solution.