Robert Simpson wrote: >> -----Original Message----- >> From: Dennis Jenkins [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, June 07, 2006 11:46 AM >> To: sqlite-users@sqlite.org >> Subject: Re: [sqlite] DLLs containing user-defined SQL functions >> >> Robert Simpson wrote: >> >>>> -----Original Message----- >>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>>> Sent: Wednesday, June 07, 2006 10:36 AM >>>> To: sqlite-users@sqlite.org >>>> Subject: Re: [sqlite] DLLs containing user-defined SQL functions >>>> >>>> >>>> >>> Pardon my ignorance about *nix, but what happens during >>> >> this whole global >> >>> symbol mapping thing if two libraries both export the same >>> >> function name? >> >>> >>> >> The PE (exe,dll,sys) file format on Windows defines an import table. >> Each entry in the import table has both a DLL name AND a >> symbol name (or >> ordinal import). It is perfectly valid for one PE file to import two >> objects from two different PEs that both have the same symbol name. >> Convincing your compiler/linker to produce such a PE import table is >> left as an exercise to the reader ;) >> > > I know how Windows works -- being a Windows programmer :) I was asking > about how *nix works. On the surface the *nix way resolving these global > symbols seemed like a keen way for some kind of injection attack or > something. > >
You are 100% correct. I misread your email. Reading way too fast.... I'm not sure how Unix works (elf or a.out file formats). It is probably well documented. It is easy to do injection attacks on either platform. Just put a hacked copy of "libc.so" on the system (in /tmp even) and modify the user's share library path environment variable before invoking the application. You can do something very similar on windows. Just dump a hacked "kernel32.dll" into the same directory as the EXE. This might not work with SP2 of XP for system DLLs. However, if the EXE uses a non-system DLL (like libJpeg.dll), then just replace that one. Put some code into the DllMain function that installs whatever hook procedure you need, and viola! You have just compromised the EXE and can do anything on that system that you want that the user running the EXE has the rights to do. On windows you can also simply "inject" a foreign DLL into a running process. I've written some code to do it. My injected DLL enumerates all of the GDI objects in the ruuning app, allowing my to capture all of the HBITMAPs that back the HDCs. ;)
