About the authors

« Where to download Autodesk Inventor Tooling 2010 product from? | Main | Autodesk Inventor Tooling 2010 not listed in Inventor addin »



Feed You can follow this conversation by subscribing to the comment feed for this post.

Great idea. I'll definitely be adding a link to this post to our current troubleshooting article, regarding restricted user permissions.


I can't see how this would be acceptable in a secure environment at all. In fact a quick Google for "breaking microsoft script encoder" immediately returned several articles on how to get around this.

While I understand that what you are attempting to do is admirable, you are potentially causing a lot of harm in the process. You note that it is not as secure as it should be in the article.

What you don't mention is that it is hardly secure at all. Anyone that knows how to look at the script file in the first place is probably smart enough to google how to un-encode it.

What I worry about is that someone is going to see this article and say, "great idea". Then they're going to deploy it without understanding exactly how flimsy it is. Now instead of a minor nuisance, they potentially have a user (or users) on their network with local admin access instead.

I think that this article needs a huge caveat attached to it. Security through obfuscation is no security at all.

P.S. There may be slightly better ways to encrypt this, but the root issue is still there. You can't provide a user with both the encrypted file and the key and expect the result to be secure. This is the same reason why DRM solutions are never out very long before they are hacked.

The potential to be a 'great idea' I have to admit comes from my interaction with *extremely* restricted profiles in Education, who disable access to C:\Program Files\ completely in their users (/student) profiles.

For interests sake, are there any specific articles you located through google that mentioned how a user with no access to C:\Program Files\ could interfere with something located in C:\Program Files\Windows Script Encoder\screnc?


It isn't "extremely restricted" to not have write access to C:\Program Files. That is a directory that Microsoft explicitly recommends not giving access to write to. Limited users are only supposed to have write access to files in C:\Documents and Settings\[User Name]. Software that save settings per user are supposed to save them in C:\Documents and Settings\[User Name]\Application Data.

(All of these directories are assuming XP. Vista's user folder structure is the much more sensible C:\Users\[User Name] structure.)

The reason you aren't supposed to give regular users write access to C:\Program Files is because that area is supposed to be a trusted area that you can run executable files from. If I'm Mr. Disgruntled Employee, I can easily replace a common executable, like say notepad or FireFox or whatever I want with a malicious program. Then when someone with admin privileges comes along, they run that and do nasty things. Viruses, Steal Passwords, etc. Heck, it can even launch the regular program too so that you never even know it is doing it.

The general rule of thumb is that limited users should only have write access to places that only affect them. So they get their user folder and then they can also change registry settings in the Current User folder of the registry. The registration issue that Inventor is causing here (my understanding here may not be complete) is actually because it is changing registry settings in the HKey Local Machine folder of the registry. This affects everyone on the computer, so limited users shouldn't be able to do it.

Now, I would argue that the security model of XP is pretty bad and that file association registrations *should* be in a place where limited users can change them by default, but they aren't, so Inventor should really stop having their application try to yank them around automatically in my opinion, although I'm sure they have their reasons for doing so.

Okay, end lecture on limited user rights. On to your actual question Melinda. You don't have to change the file in C:\Program Files\Windows Script Encoder\, you only have to decrypt the VBE file. The VBE file has to be somewhere where the user can see it, which means they can read it, which means they can decrypt it, which means that they have the username and password of a local admin account.

If you are looking for the articles I talked about in my post. Try the first three that Google returns on that search, like this one: http://www.terrencemiao.com/Webmail/msg00896.html. Feel free to ignore the actual details on how the encryption works, unless you are interested. It has a link to a working sample of the decryptor at the bottom. That one is just a simple one that is a proof-of-concept. There are better ones that you can get from places like astalavista.

The auto-linking of typepad broke that link because I put a period at the end of the sentence. Working link should be http://www.terrencemiao.com/Webmail/msg00896.html

How about RUNAS with the /SAVECRED option? The administrator will have to type in the password once on each machine, but it will be securely stored after that.

The only thing that using the /SAVECRED option gets you is the fact that you haven't actually given the user the knowledge of what the local admin password is. You've still just given them fill admin access to any machine you use it on though.

See here for details: http://www.mcabee.org/lists/ntbugtraq/Jul-03/msg00061.html

Summary for the lazy: After you've used one command with /SAVECRED, you can run any other command you want to, just use the same user command and the /SAVECRED option and Windows will gladly go off and let you run it as that person.

I also *think* that the stored credentials are made unavailable after the user's session is over so it wouldn't be a long term solution. I don't feel like rebooting to test that theory out right now though. /SAVECRED was only meant as Microsoft's own version of SUDO, but of course even less secure.

The comments to this entry are closed.

RSS Feed

  • Subscribe

August 2017

Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

Self-Service Kiosk

Did not find what you were looking for?
Give the Inventor Self-Service Kiosk a try and hit the Start button
Note: the kiosk momentarily only works with Internet Explorer