I've got a DLL which makes a call to SetDllDirectory() in its DllMain() function. The argument to SetDllDirectory() is the directory in which the DLL resides, as returned by the GetModuleFileName() function. The effect of this is that if the DLL is placed as c:/foo/bar.dll, then loading bar.dll will add c:/foo to the DLL search path of the calling process.
My question is: does this open up any form of security hole? Would it be safer to perform the SetDllDirectory() call in a function which had to be explicitly called by the process loading the library?
It isn't. Well actually not a new one. Since the application path is the first place windows looks for dlls someone could place a malicious dll in this folder. So there is a security hole without your SetDllDirectory() call.
Related
A few days back I had help from SO members in creating a safe plugins system, using interfaces to communicate between the main app and the dll's. This solved some problems I was having with Access Violations and memory leaks, and all is working perfectly now, without errors or crashes.
So, I've been creating some long due plugins for this project, which lead me to another problem: Speed
What I'm doing right now is, when the main app starts, loads all dll's in a specific folder that follow a determined name patern.
The code I'm using to load them is the following:
if FindFirst(cfg.ExePath+cPathPlugins+'\np*.npl', faAnyFile, SR)<>0
then Exit; // npl files are in fact renamed dll's
PluginHost := TPluginHost.Create as IPluginHost;
Plugins := TObjectList<TPluginInfo>.Create(True);
repeat
if (SR.Attr <> faDirectory)
then begin
dll := LoadLibrary(PChar(cfg.ExePath+cPathPlugins+SR.Name));
if dll<>0
then begin
#PluginInit := GetProcAddress(dll, 'PluginInitialize');
if Assigned(PluginInit)
then begin
Plugin := TPluginInfo.Create;
try
Plugin.Dll := dll;
Plugin.Intf := PluginInit(PluginHost);
Plugins.Add(Plugin);
except
Plugin.Free;
end;
end
else FreeLibrary(dll);
end;
end;
until FindNext(SR)<>0;
System.SysUtils.FindClose(SR);
This bit of code takes about 45s to load 7 plugins. None of these dll's have initialization code, and the PluginInitialize just passes the host interface and retrieves the plugin interface.
My questions are:
Can the number of methods on the interfaces affect the loading speed at this point? I don't believe so, but would like to confirm.
Could this loading time be cut somehow, while still loading them at startup?
I did thought of an alternative, having the names of the plugins to load in the database and loading the dll itself only upon first usage, but I'd prefer not to apply this, as some of these plugins must run automatically upon completion of some events during the app's execution, and not only though a menu option on demand.
I thought maybe this could be done loading the plugins in background, on a different thread, but I don't know if this could bring any risks, since I've never used threads.
I believe the main risk with using threads is when one tries to access variables that are being modified by the other, is this right?
In this case, that wouldn't happen, I think, as what comes after the plugin loading is grabing the plugins name (using one of its methods) and adding it to a TButtonGroup, that is created before starting the search for the dll's.
Do you believe this would be a good solution?
If not, any alternative you can point me to?
Your problem is that the DLL's are large. You need to create the DLL's using run time packages. That way, the code is only loaded once. Each DLL will include duplicates of the same code. LoadLibrary will load the DLL and call the initialization code for each DLL. This means that package X would be linked into each plugin that uses it and would be initialized when each plug in is loaded. (corrected)
For standalone EXE file, taking off runtime packages is great. It makes deployment much simpler. When you want to start using a plugin system, it's best to switch to a system that includes runtime packages.
That doesn't mean that you need to keep every runtime package separate. For example, if you only use Dev Express controls in the main application or in a single plugin then you can let Delphi compile that package into the App/DLL.
To change which runtime packages you wish to keep separate and which ones you wish to include in the project go to the "Packages-Runtime Packages" page in the project options. There is a check box that lets you choose to link with runtime packages. Underneath is a text box. In this text box you can specify the names of the packages that you want to keep separate.
I'm currently trying to load a plugin assembly dynamically in a monotouch app.
To do this, I'm referencing the plugin dll in my app project, setting the limker to 'sdk only' and then i'm trying to call Assembly.Load(filename) within my app when the plugin is required.
This is the same approach that I've previously successfully used in monodroid. However currently, this is failing in monotouch with a FileLoadException.
Is this approach possible in monotouch? Is there a special file path you need to include? Or is this not supported in the aot environment?
Note: Obviously there are other ways I can achieve a similar effect - and I do have a backup plan... but this is my preferred route (if I can make it work)
Code like:
var a = Assembly.Load ("mscorlib.dll");
Assert.NotNull (a);
works fine with both the simulator and devices. However the parameter for Load is assemblyString which is not a filename (even if the exception thrown make you think it is).
Many other overloads exists (for Load) and other methods too (e.g. LoadFrom) but they might not all work inside MonoTouch (since some runtime support might be missing).
NOTE
Handling of mscorlib.dll is special (and works in more cases than other assembles, i.e. shortcuts). However the reflection-based methods seems to work as expected in more cases, e.g.:
string filename = System.IO.Path.GetFileName (GetType ().Assembly.Location);
Assembly assembly = Assembly.ReflectionOnlyLoadFrom (filename);
Assembly.Load (or any other way of loading code dynamically) is not supported in MonoTouch.
This is an iOS restriction - all the executable code has to be in the app (and it has to be native code, which is why we use AOT to generate native code at compile time).
I have built a linux shared object which I inject into a 3rd party program to intercept some dynamic function calls using LD_PRELOAD.
The 3rd party program uses a SO "libabc.so" located at some path. My injected SO uses another SO, also called "libabc.so" located at another path (essentially identical but slight code differences).
My problem is now, that calls to a function "def" which appear in both libabc.so are always resolved by the first. (Presumably because it is loaded first?!) How can I get them to be resolved with the second libabc.so?
Many thanks!
Unless something changed since I used to do this, you will need to dlopen() the library you want to pass calls on to and call the function manually, something like;
handle = dlopen("/path/to/libabc.so", RTLD_LAZY);
otherDef = dlsym(handle, "def");
orderDef(parameter);
There is a complete example how to do this very thing at LinuxJournal.
If you only want to use one libabc.so version, you can always use LD_PRELOAD to load it along with your own shared object before anything else.
If you want to use multiple versions, you have a few alternatives:
Use dlopen() in your shared object to load that library. Since you have created a function injection object you should be familiar with this procedure. This is the more generic and powerful way - you could even mix & match functions from different library versions.
Use a different DT_SONAME for the library version your shared object links against. Unfortunately this requires (slightly) changing the build system of that library and recompiling.
Link your shared object statically against the library in question. Not always possible but it does not require modifying the library in question. The main issue with this alternative is that any change in the library should be followed by a relinking of your shared object for the changes to be pulled in.
Warning: you may need to use a custom linker script or specific linker options to avoid symbol conflicts.
I'm writing an add-on for IE using VC++ and ATL.
It's a simple DLL and I have a text file that I use as a resource. This answer helped me in doing this.
I have a question about updating resource. MSDN describes how to do it but there is a function (BeginUpdateResource) that need filename of exe or dll with resource.
Is it possible to update resource in my DLL from my DLL? I can easily read it that way, but to update I have to provide DLL's name. Is it necessary?
Also if I won't give full path to my DLL it looks for file on desktop and not where DLL is stored. I don't know why this behave like this.
I have never tried to do this so I might be wrong, but I would be surprised if a DLL could update its own resources. If the DLL file is loaded then I would expect the file containing the DLL to be locked for reading and for write attempts to that file to fail.
Still, if you want to try, just have the DLL pass its own path to the function.
You can get your DLL's path using GetModuleFileName by passing your DLL's HINSTANCE / HMODULE (they are the same thing these days) as the first argument. The HINSTNACE / HMODULE is passed to you in DllMain.
When I trace one open source, I saw someone has the following code
#prama data_seg(".XXXX")
static char *test=NULL;
FILE *f1;
#prama data_seg()
However, even after checking http://msdn.microsoft.com/en-us/library/thfhx4st(VS.80).aspx, I still not sure why we need to do so, can someone help me to understand this part?
thank you
This is usually done to share the data that's designated to be in that segment. The code you have above will normally go in a DLL. You also use a .def file that specifies that the ".XXXX" segment is going to have the "SHARED" attribute.
When you do all that, the data in that segment gets shared between all the processes that load the DLL, so those variables are shared between all those processes.