Signing lisps???

Signing lisps???

JamesMaeding
Advisor Advisor
673 Views
6 Replies
Message 1 of 7

Signing lisps???

JamesMaeding
Advisor
Advisor

Is anyone going to sign their lisp files?

The only instance I have ever seen of a lisp doing anything bad is the one where an acaddoc.lsp is in a drawing folder, and loads on startup.

 

Can anyone else give a single example of a "non-startup" lisp causing a problem, that would have been avoided by signing?


internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties

674 Views
6 Replies
Replies (6)
Message 2 of 7

owenwengerd
Advisor
Advisor

I suppose signing could be useful in-house if you want to detect whether a file has been tampered with, but generally signing is intended for files that will be distributed to others as would be typical of a commercial plug-in.

--
Owen Wengerd
ManuSoft
0 Likes
Message 3 of 7

JamesMaeding
Advisor
Advisor

Owen, try to come up with a scenario where siging would actually help.

I've thought through all I could, and it would not help.

 

It may be that you need to control lisp editing, but that is better done other ways.

Keep in mind there is no control of who signed the lisp, just that they are signed or not.

If you would try to use it to prevent acad.lsp from running from current drawing folder (the only real security issue I know of), the culprit could just sign the bad acad.lsp.

The signing info will not help catch that kind of person.

So you would actually be letting your guard down if using signing. You should instead prevent lisps from running from the startup folder.

 

So these cool sounding features actually become dangerous if implemented on real problems.

They sound great if you don't use them.

 

 


internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties

0 Likes
Message 4 of 7

owenwengerd
Advisor
Advisor

Your description of how signatures would be used is not altogether wrong, but it's not complete. The goal is not to "control lisp editing" or even loading of lisp files. The end user running AutoCAD is already on the other side of the airtight hatchway, so this would be a pointless exercise. The goal in this scenario is to warn the user and give them an opportunity to cancel loading of files that may have been maliciously modified without their knowledge.

 

There is some truth to your assertion that an attacker could just re-sign the maliciously modified files, and the psychology of warning dialogs is such that most users will blindly ignore any warnings and load the file anyway. However, if you are the signer and you protect your private key, there would be no way for the attacker to sign the modified file with *your* signature. Therefore, if you are a trusted publisher and the attacker is not, in theory the end user sees the warning, realizes that she's been attacked, and stops loading the infected file.

 

--
Owen Wengerd
ManuSoft
0 Likes
Message 5 of 7

JamesMaeding
Advisor
Advisor
But the only instances of bad lips are the acad.lsp and other startup lisps. This idea of protecting us is fictitious.
If adesk understood the real issue, they would target the startup lisps, but instead they lump all together and miss the chance to make signing useful.
again, can anyone give a real example of when signing will help?
the specifics of the example will reveal the real issue and it's typically lack of proper read only folders or a startup lisp that slipped in from uneducated users.
maybe there is a useful situation, how clever to we have to be to find a real use?


Sent from my Verizon Wireless 4G LTE smartphone

internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties

0 Likes
Message 6 of 7

dgorsman
Consultant
Consultant

One of the common LISP exploits is to modify existing files.  Perhaps Owen could confirm this - am I correct in thinking that programmatically modifying a LISP file (such as the infamous ACAD.LSP instance) would render the file unsigned and therefore either warn or simply not load?

 

Of course, our own specific implementations mean little to AutoDesk.  Security is growing issue, and using signed files (whether we agree with or implement the process or not) allows that check box to be ticked off.  In the abstract, this will provide some protection for OOTB users who are not able or willing to engage in the level of customization we engage in.

 

And even though the ACAD.LSP issue is the only one we can think of right now that doesn't automatically exclude any other potential problems.  Its the breaches we *don't* see that keep us up at night, is it not?

----------------------------------
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.


0 Likes
Message 7 of 7

JamesMaeding
Advisor
Advisor

Yes, lisp can write text files, and modify any lisp that is not read-only.

That would nuke the signing for sure.

 

Anyone competent enough to implement this kind of loading restriction at a real company will know how to solve the real problems without implementing it.

 

That leaves the feature useless.

 

 

 


internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties

0 Likes