Security and Code Injection on Windows OS

[Grok]

What purpose does code injection provide?  By the OS allowing another process to attach and insert a DLL into its address space, and run as that process, trojans and virii can get around firewall rules.

If I were a trojan, I would enumerate the firewall rules, find which applications are allowed to create outgoing connections, load that process hidden, inject my own code and execute it, performing whatever malicious duties I wanted.  The firewall would only detect that IExplore.exe was connecting outbound on port 80, and have no objections or warnings to the user.

Does Linux allow this process hijacking/riding?

[Skywing]

Barring exploitable flaws in a particular program, you can generally only put code into a process running as your account unless you are an administrator, so there isn't really a problem.  The same goes for unix-based systems.

Note that once you have hostile code running as you, all bets are off anyway, for virtually any operating system I know of.

[Grok]

Right -- so, what is the supposed benefit of an OS allowing code injection?

[Skywing]

Right -- so, what is the supposed benefit of an OS allowing code injection?

I think the problem is more like how would you prevent it?

Are you going to require programs to run as admin to be debuggers or use IPC?

[Adron]

Right -- so, what is the supposed benefit of an OS allowing code injection?

The question is: What is the supposed benefit of an OS not allowing code injection between processes with the same privileges (i.e. run by the same user)?

[iago]

Linux allows users to modify their own processes, or root to modify any, so I would imagine there is some way to do it there.  But I don't know of any specific API calls.

The thing about Windows is that only administrators can do it to key processes, but at the same time every home user (well, at least 99% of them) do everything as administrator.  

Modifying other processes is important for virus scanners, as well as other debugging and development tools.  I know TSearch (memory editor) injects a dll rather than using ReadProcessMemory on a foreign process, though I'm not sure why.

But in the end, I can't think of any good reason for dll injection.  So to answer your original question, perhaps it isn't vital?

[iago]

Barring exploitable flaws in a particular program, you can generally only put code into a process running as your account unless you are an administrator, so there isn't really a problem.  The same goes for unix-based systems.

Note that once you have hostile code running as you, all bets are off anyway, for virtually any operating system I know of.

I'm not quite clear on what you mean here -- that it's possible to get Admin/root once you have a user account, or just that all bets are off on your own stuff?

[Skywing]

Barring exploitable flaws in a particular program, you can generally only put code into a process running as your account unless you are an administrator, so there isn't really a problem.  The same goes for unix-based systems.

Note that once you have hostile code running as you, all bets are off anyway, for virtually any operating system I know of.

I'm not quite clear on what you mean here -- that it's possible to get Admin/root once you have a user account, or just that all bets are off on your own stuff?

As in all bets are off for trying to authenticate code running as that user as 'good', like Grok wants the firewall to do.

[Grok]

As in all bets are off for trying to authenticate code running as that user as 'good', like Grok wants the firewall to do.

No, I didn't say that.  I was pointing out that even if a firewall rule were to allow only specified applications to use the specified rule, those applications could be comprimised by code injection.

What I was trying to gather is why the OS designers would have added process code injection as a possibility.  For what purpose was that ability created?  What OS requirement does it solve?

[Skywing]

As in all bets are off for trying to authenticate code running as that user as 'good', like Grok wants the firewall to do.

No, I didn't say that.  I was pointing out that even if a firewall rule were to allow only specified applications to use the specified rule, those applications could be comprimised by code injection.

What I was trying to gather is why the OS designers would have added process code injection as a possibility.  For what purpose was that ability created?  What OS requirement does it solve?

I don't think the OS designers said "let's add ways for people to put dlls into other people's processes" -- instead they went and designed something that allowed processes to cooperate by sharing memory, or reading/writing process memory to pass information (e.g. how command line arguments are copied between Win32 processes when you start a new Win32 process), and so on.

Note also that NT is designed to be able to implement a POSIX compliant environment, an OS/2 compliant environment, etc.  These environments require such capabilities.

[Adron]

No, I didn't say that.  I was pointing out that even if a firewall rule were to allow only specified applications to use the specified rule, those applications could be comprimised by code injection.

The security boundaries are based on users, not on processes...

What I was trying to gather is why the OS designers would have added process code injection as a possibility.  For what purpose was that ability created?  What OS requirement does it solve?

One class of purposes is UI extensions: changing the look and feel of Windows, adding options to menus, shortcuts on title bars, supporting mice with extra buttons and so on.

I think the OS requirement you seek is "extensibility".