This rule indicates that P/Invokes should not be made public. My question is why? A caller can trivially create their own declaration within their own assembly to make the exact same call. A caller could just write a C library to call the API. What benefit, security or otherwise, is gained by making these declarations internal?
Well, in the .NET security model, it's possible for your assembly to have permission to do P/Invokes, but for your caller not to have. (AllowPartiallyTrustedCallersAttribute, which permits code running as partially trusted to call into an assembly that is fully trusted, exists to enable this.)
Which is, essentially, what you want when the library you are writing exists to provide safe access, or limited access, to some system facility that you don't want sandboxed applications of one type or another to have arbitrary access to.
On another note, it's politeness as well as security. P/Invokes are de facto unsafe, inasmuch as calling them badly can result in all kinds of interesting ways to crash that you generally don't run into in the comfortable .NET world. Wrapping some error-checking and general safety code around them, along with such things as mangling input data into the Win32 API (or whatever's) format, translating its error codes into the appropriate .NET exceptions, etc., etc., is just plain courtesy to your library's future users, IMO.
Related
I am writing an open source cross-platform application written in C++ that targets Windows, Mac, and Linux on x86 CPUs. The application produces a stream of data (integers) that needs to be validated, and my application will perform actions depending on the validation result. There are multiple validators, which we shall call "modules", and they can be swapped out for one another.
Anybody can write and share modules with other users, so my application has to ensure that maliciously-written modules cannot harm the user in any way (perhaps except via high CPU usage, in which case my application should be able to kill the module after some amount of time - this can be done by using a surrogate process). Furthermore, the stream of data is being sent at a high rate (up to 100kB/s).
Fortunately, the code in these modules are usually simple arithmetic operations on data in the stream (usually processing each incoming integer in constant time), and they do not need to make any system calls (not even heap allocation).
I've considered the following possibilities (all of them with some drawbacks):
Kernel-based sandboxing
On Linux, we can use secure computing (seccomp), which prevents a process from making any system calls except for reading and writing with already-open file destriptors. Module creators would write their modules as a single function that takes in input and output file descriptors (in a language like C or C++) and compile it into a shared object, then distribute that shared object.
My application will probably prepare input and output file descriptors, then fork() itself or exec() a surrogate process, and this child process uses dlopen() and dlsym() to get a pointer to the untrusted function. Then strict secure computing mode will be enabled, before executing the untrusted function.
Drawbacks: There's the problem that dlopen() will actually run the constructor function from the shared library. This would have to be properly sandboxed as well, and I can't think of a way to do so. Also, of course, this thing will only work on Linux. As far as I know, there is no way to ban WinNT system calls on Windows, so a similar solution on Windows won't be very secure.
Application-level sandboxing
[[ Any form of application-level sandboxing means that we cannot run untrusted machine code of any form. An untrusted function can overwrite its return value or data outside its call stack, thereby compromising the whole application (and effectively acquiring any permissions that the original application had). ]]
Make modules use a simple scripting language that does not support any system calls - just pure arithmetic operations and perhaps the ability to read an input stream. My application would contain an interpreter for this language.
Drawbacks: Unfortunately I have not found this scripting language. Many scripting languages have extensive functionalities (e.g. Python) and a sandbox (e.g. PyPy's sandbox) simply filters OS system calls. I would be shipping a lot of useless interpreter code with my application, and it arguably is more prone to security issues due to bugs in the intepreter than a language with simply no functionality to do things other than simple calculations and control flow instructions (basically a function that does not make any system calls). Furthermore, marshalling the data between C++ (machine code) and the scripting language is usually a slow process.
Distribute modules with a 'safe' compiled language that again does not support any system calls. My application would contain a JIT for this language.
Marshalling won't be necessary because my application would call into the JITted machine code of the untrusted module, so performance across this boundary should be fast. The untrusted module now won't be able to corrupt the stack, attempt return-oriented programming, or perform any other malicious actions, due to the language restrictions and checks of the 'safe' language. WebAssembly is the first and only language that comes to mind (if it can be called a language). (As far as I can tell, WebAssembly seems to provide the security guarantees for my use case, right?)
Drawbacks: The existing implementations of WebAssembly seem to be all browser-based, so I would have to steal an implementation from an open source browser. This does seem like a lot of work, considering that I would have to uncouple it from all the JavaScript and other browser bits. However, a standalone WebAssembly JIT based on LLVM seems to be under development.
Question:
What is the best way to execute an untrusted function efficiently that works on Windows, Mac, and Linux?
Right now, I think that the scripting language way would probably be the safest, and be the easiest for module writers. But for a more efficient solution, WebAssembly is probably better. Am I right, or are there better or easier solutions that I have not thought of?
(Remark: I think several pairs of tags used in this question have never been seen together before!)
Regarding WebAssembly:
Unfortunately, there is no production-quality stand-alone implementation yet. I expect some to show up in the future, but it hasn't happened yet.
For historical reasons, existing production implementations are all part of a JavaScript VM. Fortunately, none of these VMs is tied to a browser. If you don't mind including some unused JS baggage, you can embed them as they are (ripping out the JS would be very hard). One problem, though, is that these VMs don't yet provide embedding interfaces for Wasm specifically. You have to go through JS, which is stupid.
There is an initial design for a C and C++ API for WebAssembly, which would give direct access to an embedded Wasm VM. It is meant to be VM-neutral, i.e., could be implemented by any existing VM (the repo contains a prototype implementation on top of V8). This may evolve into a standard, but I cannot promise any timeline. Right now it's only for the brave.
I intend to add a COM interface to an existing application (which, by the way, is written in C++ using Win32). I have some experience using COM objects, so I know the basic COM concepts of interfaces, etc., but this is the first time I'm actually implementing a component.
Ultimately I want to be able to use the COM interface to automate my application from scripts such as VB. I understand that there are two steps:
My application must act as an out-of-process server (i.e. I have to use MIDL and generate code for a proxy DLL and a stub DLL).
Once I have the server I can add automation capabilities by implementing the IDispatch interface.
Since the server-in-an-EXE thing with MIDL and what not is already a bit steep, I wanted to get a grasp on all that first before moving on to IDispatch.
I am reading the book "Inside COM" by Dale Rogerson and have completed the chapter on servers in EXEs (the following chapter will cover Automation).
The "Servers in EXEs" chapter provides example code that implements a server and a client. But it is necessary to start the server manually. This confuses me. Obviously, when my application (= server) is used by a client process, this extra manual step should not be necessary. Is there no mechanism to start the server automatically? Or is automation necessary to achieve that? At the moment, the prospect of having to start my server manually (once I even have one) makes me doubt I am moving in the right direction.
Hopefully someone with more knowledge of this can see what information I'm missing and point me in the right direction.
No, COM servers are not normally started by hand. Not sure why the book proposed it, possibly because it wanted to avoid talking about the registry keys you need to allow COM to automatically start the EXE. It isn't otherwise very complicated, you register the Application coclass of your app with the LocalServer32 key value giving the path to the EXE.
It is however not completely uncommon, especially with an existing program. One design decision to make is whether you let the client code completely control your program. Or if your program already has an existing user interface but you also want to expose services to other code. In the latter case it makes sense to let the user start the app by hand, like she'd normally does.
When your application is registered as LocalServer32, it will be invoked with the commandline specified there if no running process has registered a factory object for your CLSID yet.
This way, you can get the best of both worlds -- if the application is running already, this instance can provide the server side, and if it isn't, it will be started.
Automation is completely orthogonal to that -- your component becomes Automation compatible by implementing IDispatch.
My scenario is as follows, a .NET 4.0 Solution with several projects (one host and some dlls), one (dll) in particular making use of the MySQL .NET Connector in order to only call upon stored procedures. I've also signed all my assemblies with a private key.
I'm curious if a hacker could somehow obtain the password to the database user from the connection string (even though that user only has permission to EXECUTE).
Also I'm curious whether a hacker would be able to find out the stored procedures I call on and whether he could Select/Insert/Delete arbitrarily with the use of my stored procedures.
All this with the presumption that the hacker only has a copy of the compiled solution.
If you have hard-coded the user name and password in your code, or even if you store the credentials in an encrypted file, but the encryption key is hard-coded in your code, it is easily hackable because .NET assemblies are not compiled to machine code. When you build a .NET assembly, it converts your VB.NET code into MSIL code, which is just a lower level programing language which is still easily readable. Microsoft provides a free tool (as part of the .NET Framework SDK) called MSIL Disassembler which allows you to easily view all the MSIL code for any compiled assembly. There are many tools available which allow you to easily take the MSIL code and "decompile" it to VB or C# code. You'd be amazed at how easy it is to reproduce your original code with a .NET decompiler. If the PDB's are available, the output is shockingly similar to the original code. So, unless you are using some third-party code obfuscation or assembly encryption tool, your "compiled" assemblies are very easily reverse engineered. Usually this isn't a big deal, but if avoiding hacking is a high concern, you certainly shouldn't be putting any secrets in your code.
Are you confident that all of the code in the project is safe from things like SQL Injection vulnerabilities and Local File Inclusion vulnerabilities (and will remain so, as it evolves)?
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.
Don't mark the control as Safe for Scripting.
Default security settings will not allow such controls to be scripted.
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.
Since HTA applications are hosted within MSHTA.exe how does one provide a manifest? Plus I assume providing a MSHTA.exe.manifest could potentially break other HTA apps?
On Vista+, MSHTA.exe has an embedded manifest, which takes priority over external manifests, so your suggestion is not an option.
On XP/2003, yes, your suggestion would work, although it would be bad form, as is dropping files in System32 to modify the behavior of a system binary (especially make sure that any registration you put in the manifest are objects you are the only one to care about).
The proper solution, available on Win2003 and above, is to use the Microsoft.Windows.ActCtx object to instantiate your object given an explicit manifest reference.
For example:
var actCtx = WScript.CreateObject("Microsoft.Windows.ActCtx");
actCtx.Manifest = "myregfree.manifest";
var obj = actCtx.CreateObject("MyObj");
Perhaps, if this must work on XP as well, a path you may take is a combination of both solutions.
Edit: My answer is wrong, but I'll leave it here to avoid any similar wrong answers :)
If you question is can you access a COM object without registering it on the machine, then I think the answer is a tentative yes. However the work you would need to do would be substantial and would mean implementing a lot of the low level code that most development tools provide for you as a matter of course (Delphi, .NET, JAVA). You would need to interface with the dll directly (like you would a normal dll ), query its interfaces and call your methods.
If you have C, C++ knowledge, the way COM is accessed from these languages would give you some pointers.
Sorry I cant be of any more help.