VB: get compiled DLL's calling application info; COM security

Question

Through COM, one can potentially gain absolute control over a target system. For example: using javascript's ActiveXObject object in IE, one can create certain objects which were designed to have direct access or interaction with system properties and files. One would think common sense dictates users disable ActiveX features in IE immediately after installing the browser to ensure their system is protected while surfing the net, or at least paying close attention to which websites they permit. But, I doubt many average PC users know how or why to do this, or just get tired of mirco-managing it over time. I think any PC user or admin my COM class caters to would greatly appreciate not having to deal with that. Thankfully it looks like IE versions come packaged with ActiveX disabled by default nowadays.

I've built a very versatile COM class library in VB. I didn't intend for it to be callable from any website, but that feature is just part of the COM platform. I'd like to prevent the library from being called from IE unless the website is on a white-listed domain to proactively protect the user (and ultimately their entire intranet) from harm from malicious websites. What would be the best method in VB.Net to tell which application called my DLL, to be able to tell if it was called from any command or process originating from IE? And, what domain called my dll?

Edit: I believe this might be a duplicate. See: Calling Assembly to get Application Name VB.NET

System.Environment.GetCommandLineArgs()(0) gets me the calling application path. With this info, I can compare it to a black/white-list of applications. Problem solved for now.

Flavio

"I've built a very versatile COM class library" - what does that mean? – Midland

@Mitch Wheat: it means my com class inadvertently gives the calling application complete control over the client system, including if it was spawned from javascript. – Flavio

@ bob-the-destroyer: that doesn't sound like a good idea... – Midland

@Mitch Wheat: neither does giving access to com components over the internet. But that's been a feature of Windows since their implementation of the "activexobject" javascript object. So as a courtesy to my users, I'd like to find a work-around. – Flavio

Answer 1

Don't mark the control as Safe for Scripting.

Default security settings will not allow such controls to be scripted.

Doordie

@Slaks: Not sure what you mean, "Don't mark the control as Safe for Scripting." My com class isn't really meant for calling from the internet, it's just that it can be. This is what I need to find a way to control from within the VB.Net library itself. – Flavio

@Slaks: briefly checked out IObjectSafety - but I actually really do not want this COM class callable over the internet, even if the user explicitly allows it. I'd make an exception likely by some registry key an administrator can set to bypass my arbitrary blocking, but for regular users, no. – Flavio

It means that you have to mark your control before any script under IE can access it. Unless you explicitly marked it, your users are safe. For now. – Allieallied

@wqw: users can still allow it by lowering zone security levels. – Flavio

@bob: If the user lowers security levels, malicious code will just use FileSystemObject. Once you are as secure as FileSystemObject, you're done. – Doordie

@SLaks: luckily there's almost 0 chance my code has been installed on anyone's system, and even less of a chance an attacker has ever heard of it. Still, it's not safe to have this thing accessible by IE. – Flavio

@bob: If it's accessible by IE, FSO is also accessible. Once FSO is accessible, the attacker doesn't need your object; he can use FSO to replace every EXE file on the system. – Doordie

@SLaks: that shifts the guilt and blame off me knowing there's almost 0 chance my library was used as the attack vector. Still, I'd rather implement some extra precautions. – Flavio

@bob: Your time would be better spent making more useful improvements, such as documentation. – Doordie

@SLaks: Security is nothing to dismiss. IMHO: make it secure or don't publish it under official releases. Being able to use the FSO class is great for a file-upload manager. But I'm sure folks who's PC's were turned into zombies or had their HD wiped by any COM class wish its authors were a little more security conscious. – Flavio

Answer 2

Self-answer, and possibly duplicate, I suppose. See System.Environment.GetCommandLineArgs()(0) from Calling Assembly to get Application Name VB.NET

In this case, the class never was marked as safe for scripting and the intent was already never to mark it safe. The issue was how to obtain the calling application info so I could add additional security measures in case those which the calling application had were not enough.

Flavio