Like a lot of people who have worked in the business, I find myself in conversations about computer security with people who are having problems or know people who have problems. I wrote this to save me from explaining the same thing over and over again to different people, and to save them the trouble of having to make notes as we talked. It was meant to be something you could give to a 'naive user' and have them be able to read and follow it more or less unaided, and while not being a complete guide, at least be something that made them more secure than before they got it.

Yes you can do this, however you need to have permission to access the other process in this way.

On Windows, the way you do this is to:
1) Open a handle to the target process
2) Allocate memory in the other process space
3) Write the path to your DLL into that memory space
4) Create a thread in the target process space with the thread proc set to LoadLibrary and the parameter set to the memory address you allocated in step 2.
5) Your dll code is now running in the other process...

This is a very well known DLL process injection attack. The OS APIs used for this attack exist to allow debuggers to function (among other things). This is just an example of how powerful tools can be used for good and for bad.

A few things to keep in mind with this attack:
1) You can be attacked in this way even if you are not running as administrator. The attack can simply choose to inject into a process that your user account owns.... like iexplore.exe.
2) You cannot inject into a process if you don't have permission to open the process and create remote threads. This would prevent even the administrator from attacking processes owned by the system without doing a bit more work.

I haven't really looked into this style of attack on Mac OS X, or variants of Linux, however I wouldn't be surprised to find that a similar attack is possible. For Mac OS previous to OS X and Windows 9x/ME/3.x would probably be rather easy to attack. IIRC they lacked protected memory so any process could access another process's memory space.

There are plenty of sources on the net that describe this sort of thing. See www.rootkit.com for some examples.

MacOS before OS X did lack memory protection. Windows 9x had a memory protection scheme, and I think it was the reason it was so unstable after a few weeks (it wasn't very good).
I don't know about 3.1. But I don't know if the hardware could have even supported a protected mode in 16bit. IIRC you needed to be using 32bit code to get that.

I'd honestly be a bit surprised to see this attack possible on Unix systems. I googled around a bit, but "injection dll" is a whole lot better than "injection so" . I kept getting junk about mysql.

I'll do some more digging using your instructions on how it's actually done.

Windows 9x IIRC had 2Gig of memory space for each user process, and a shared 2Gig space for the system. This is all you would need.

3.x was even weaker.

Protected memory on windows became possible with the i386. This is because the processor had built in components to tie to a VMM.

With Unix, I wouldn't worry about forcing another process to load a shared library. That is just a means to an end. The real goal is to get another process to execute your code. As I said, I haven't really looked into this, but I suspect that one could use the proc filesystem to adjust the memory contents of another process owned by the same user. That could get your executable code into the other process... The trick then is to convice that process to execute it. I'm not sure if there is a way to create a thread in another process on Unix (the way you can on Windows).

If I were to attack a Unix like OS, or Mac OS, I would start by looking for exploits that allow me an elevation in privilage. From there I could load a kernel module and be able to do what ever I want.

The short story here is that _every_ OS is vulnerable to exploits of some sort. CERT has many for MacOS as well as Linux. The trick is to be consious of the risks and to act in a manner that protects you from harm. I would be concened if I had a Mac or Linux user on my network who felt so secure in thier OS that they started doing risky things (like executing random downloads, visiting questionable sites, etc...). Everyone, regardless of their OS, needs to be wary in thier computing practices.