Miguel de Icaza's blog: Monovation: Assembly Injection into Live Processes - Miguel de Icaza
Natan Yellin
· 1 year ago
Good job to everyone who worked on this. It's very neat.
j23tom
· 1 year ago
The only thing I really miss now is file script execution (like "csharp myscript.cs")
migueldeicaza
· 1 year ago
Yeah, still wondering about that one; It is trivial to implement, if you look at the csharp source code, you will see that it already loads your ~/.config/csharp script, changing that to also load files would be easy, but I have mixed feelings about what the input files should be: statements/expressions (as it does now) or classes (which still need some work).
Seth
· 1 year ago
Wow. This is exciting stuff.
I second most of the security concerns. Just pointing at similar capabilities in competing technologies doesn't mean it is secure. It just means they are all flawed for the same pragmatic reasons (productivity). I do think the truth is not so dramatic as some of the commenters make it sound, but hey: it is a concern.
Dll-injection on Win32 has proven to be the backspine of all spy-ware. Yes it is powerful. Lot's of powerful things are dangerous.
My most important fear here, is actually more on the conceptual level. Using this for debugging is ok. Using it for auditing might be ok. [provided adequate privileges are required for each task]. However, the examples lean in the direction of (oh - no - here it comes) automation.
It is just another 'interoperability' route going the promiscuous/incestuous way: we have had DDE (oh no), OLE (mmm) COM(+) Application Servers (ok-ish), Office Automation (Noooooooooooooooooooo(2)), Dll-Injection (whoaaaaa), Bonobo (mmm), DBus (ok-ish); etc. etc. etc. All quite different in many respects, but the main thing that has stood out to me is that (a) desktop environments stop mingling together(1), (b) there is a significant performance penalty (bonobo, DCopserver, Dbus - they all grow and have their slightly obese backends running at all times) (c) most importantly applications get tightly bound, where there should have been no need to.
In my mind this is the 'easy' way to integrate from dev standpoint. But it is the type of lazy easy that comes with heavy costs - in the long run.
E.g. DBus has got over this new 'mono attach' design, that it is easy (necessary) to specify *exactly* what interface surface you'd like to expose. If you wanted plugins: define a plugin interface and just explicitely load these things. This was already exceedingly simple by design in .NET/Java. In my opinion any layer on top of simple text-file/socket protocols has the obvious advantages over these strategies (decoupling, portability (try mono attach using perl; try mono attach from our AIX server - oops?), transparency (try remote attach? try attach across virtual machine boundaries?), security (reduced surface, explicit POSIX permissions, optional ACLs to name a few).
Now, I happen to really like features like this one, but I have this worry that the (Gnome) desktop will become the same muddy clutter that we have seen in all other OS-es that couldn't resist adding every feature they could think of.
My boot time is already up there with Windows 2003 running Ubuntu 8.04; I'd like to think we let Microsoft hold pole position in that area... Starting Thunderbird is already starting to take scary amounts of time.
In the mean time: both csharp and 'mono attach' are very nice tools and valuable 'firsts' for the mono community. If handled with care, lot's of good will come of it !
Cheers
(1) no that app cannot be saved as part of the session, it doesn't speak bonobo, sorry (2) get me right: VBA = good (the feature, not the language), office automation = bad (see: installing Outlook on servers; launching Word to inspect document contents by automation - eeeeeeeeeeeeeeck)
PS. Would it be possible to attach to a process, while creating a separate AppDomain in the target process? This could be a help in keeping things as secure as possible
migueldeicaza
· 1 year ago
If you can run code as a user, running code in a separate AppDomain is not going to help you.
Sure, it will "protect" the target application for all of 10 seconds, the 10 seconds it takes you to call system("rm -rf ~") which would have been a simpler, more effective attack.
psantosl
· 1 year ago
Amazing guys!!! I really like all this stuff about dynamic code loading. It only makes Mono better.
Beyond all the "dangerous" stuff (hey, evil is just there), I think it opens up a whole world of great possibilities... Now it's our turn (app developers) to really make sure we get the best out of this!
Congratulations!
Kamujin
· 1 year ago
Really cool stuff. I agree that this raises some questions about security and code obfuscation.
Sadly, this is not immediately applicable to the type of work that I do, so I will have to be satisfied with admiring this from afar.
Sebastien
· 1 year ago
Source wise the two racy spots I see are handled correctly. Design wise it's better to reuse an existing design (e.g. Java), even if not proven secure, than invent our own. Feature wise I think this is exciting mainly because we've been lacking great debugging tools for too long.
Peter
· 1 year ago
What the HELL were you guys smoking?! So now any process ran by user foo (say, something not entirely trusted -- users are users, that's why we have so many security advisories with "user-assisted" in their title) can manipulate ANY OTHER MONO PROCESS of the same user. Great thinking here -- and that's despite people who actually get security explaining this to you in your other blog post's comments.
Yes, I'm pissed off -- that's because I rely on Mono on two platforms under the assumption that it is at least so-so secure code, only to learn that its developers are security-incompetent after investing hundreds of hours of development time into Mono-based app :-(
For the slower ones among us, here's the (trivial and *obvious*, mind you) attack scenario:
1. attacker dupes user into running some piece of code ("look, shiny Banshee plugin!"; this step is standard procedure, really) 2. this piece of code creates /tmp/.mono_attach_pidN for the process it wishes to attack 3. it then sends SIGQUIT (it can, it's running under *the same user*) 4. it now injects whatever piece of malicious code it pleases into the attacked process
Great job, Novell.
mind
· 1 year ago
gdb --pid is a gaping security hole?
if you're relying on an attackers laziness to keep them from modifying a process, you've already lost.
migueldeicaza
· 1 year ago
If you have a rogue user process, you have worse problems than this feature.
For one, if you have a rogue user process you can ptrace any other process you have access to and inject any code you want. This is how debuggers work, and you do not need Mono for this, it works with plain old system calls. Its all there in /lib/libc.so and in your kernel.
As for the security issues raised in the previous post: they had to do with how a *different* user could get access to the feature from a different process. The answer is: they can not with our design, but we would like it peer reviewed by serious developers, someone that actually saw the source code and actually considered the issues, clearly this does not apply to you.
As for the paranoid, you can run any mono process, with a flag: --attached=disabled (you would know this if you had bothered to look at the source code).
As for your scenario, it merely proves that if you have a gun and a bullet, you can shoot yourself in the foot.
A simpler scenario is: "Attacker dupes user into running some piece of code, `look shiny XXXX plugin" as you say, this step is standard procedure.
At this point, the user has full control over everything you have control over: every file you have rights to read, write and running processes. They can wipe out all your files, back them up with a background thread to a remote location, infect every Linux binary with a virus (if they chose to write one) and scramble our files.
None of the above require the Mono.Attach functionality, and in my opinion, it is a lot simpler to do without requiring "Mono 2.2 or higher, with X, Y and Z installed" which would also be a minor target for an attack, you are much better off attacking the aliases in the ~/.bashrc of a user.
Good comment. This just shows that people like to get pissed off at Mono for no good reason.
Tobias
· 1 year ago
I agree, but rather than having to explicitly disable the attaching of processes, wouldn't it be more secure to do it the other way around? That is to say, you need to explicitly enable the attaching of processes to yours? That way, you can use it to debug, but normal processes (distributed binaries started via menus etc) aren't vulnerable because they will reject attaching by defaut.
Zoltan
· 1 year ago
attaching _is_ disabled by default, you have to create a trigger file, and send a SIGQUIT signal to the process to enable it, something most users are not likely to do.
vsl
· 1 year ago
Attaching _is not_ disabled by default -- all you have to do instead of simply attaching is 1. create trigger, 2. send signal, 3. attach. Whoever can do step 3 can do steps 1+2 as well.
vsl
· 1 year ago
Attaching _is not_ disabled by default -- all you have to do instead of simply attaching is 1. create trigger, 2. send signal, 3. attach. Whoever can do step 3 can do steps 1+2 as well.
Zoltan
· 1 year ago
To send a signal to a process you have to be its owner or root, this is enforced by the kernel. So only the owner of the process can start the attach functionality.
Peter
· 1 year ago
> actually considered the issues, clearly this does not apply to you
Being arrogant and dismissive doesn't change the facts, as much as you would like it. Yes, you are secure (hopefully) against other users, but some people consider security implications *other* than what you were able to came up with. That's the thing about security, somebody always comes up with something you didn't expect. People that are good at security understand that and don't get offended when somebody points out a flaw in their reasoning -- clearly this does not apply to you.
I *did* have a look at that code to verify it's as stupid as I suspected. If *you* did bother to re-read the code you linked to before accusing me of not reading it, you would know that this code does not, in fact, handle --attached flag. Must be done elsewhere.
Moreover:
1. You make it *much easier* to inject code, in portable, arch- and platform-independent way. Lower barrier to entry => easier attack. How hard is it to get this?! 2. Being able to disable the hole is not the same thing as being secure by default (you know, the time-honored security principle that gives you a chance to be secure against something you didn't anticipate) 3. No, you cannot "infect every Linux binary with a virus" -- permissions, you know. That's the dangerous thing -- I may suspect a binary I run, but not that it will sneak into other processes and get access to things the _other_ process can access. For example, you make it possible to inject code into an app that was already authenticated to access the keyring. 4. "Others do it, so it must be OK" -- seriously?! When you see two men jump from a bridge, will you follow them?
migueldeicaza
· 1 year ago
We make it much easier to inject code, Wooo! Who cares? Of all the things that you can do once you are running at full trust as a user, this is an incredible waste of time. This is why nobody uses "ptrace" for injecting code into applications for "evil", its just not good bang for the buck.
Even if the feature was not implemented, guess what, ptrace on Linux exists and you could inject the code *ANYWAYS*. We made it easier, but even if it was not there, anyone could build a library to inject the code with existing Linux syscalls.
And until you understand that the status quo did not change, you will not be able to grasp why it is a non-issue.
You have failed to show any case where this is a new security hole, until then, you seem to be speaking out of lack of proper information and understanding.
Your example about "two men jumping off the bridge" is inadequate. A more adequate example is that inside your house you do not place locks between the bedroom and the kitchen, and other seem to think that securing rooms in your house is mostly a waste of time.
All Comments
I second most of the security concerns. Just pointing at similar capabilities in competing technologies doesn't mean it is secure. It just means they are all flawed for the same pragmatic reasons (productivity). I do think the truth is not so dramatic as some of the commenters make it sound, but hey: it is a concern.
Dll-injection on Win32 has proven to be the backspine of all spy-ware. Yes it is powerful. Lot's of powerful things are dangerous.
My most important fear here, is actually more on the conceptual level. Using this for debugging is ok. Using it for auditing might be ok. [provided adequate privileges are required for each task]. However, the examples lean in the direction of (oh - no - here it comes) automation.
It is just another 'interoperability' route going the promiscuous/incestuous way: we have had DDE (oh no), OLE (mmm) COM(+) Application Servers (ok-ish), Office Automation (Noooooooooooooooooooo(2)), Dll-Injection (whoaaaaa), Bonobo (mmm), DBus (ok-ish); etc. etc. etc. All quite different in many respects, but the main thing that has stood out to me is that
(a) desktop environments stop mingling together(1),
(b) there is a significant performance penalty (bonobo, DCopserver, Dbus - they all grow and have their slightly obese backends running at all times)
(c) most importantly applications get tightly bound, where there should have been no need to.
In my mind this is the 'easy' way to integrate from dev standpoint. But it is the type of lazy easy that comes with heavy costs - in the long run.
E.g. DBus has got over this new 'mono attach' design, that it is easy (necessary) to specify *exactly* what interface surface you'd like to expose. If you wanted plugins: define a plugin interface and just explicitely load these things. This was already exceedingly simple by design in .NET/Java.
In my opinion any layer on top of simple text-file/socket protocols has the obvious advantages over these strategies (decoupling, portability (try mono attach using perl; try mono attach from our AIX server - oops?), transparency (try remote attach? try attach across virtual machine boundaries?), security (reduced surface, explicit POSIX permissions, optional ACLs to name a few).
Now, I happen to really like features like this one, but I have this worry that the (Gnome) desktop will become the same muddy clutter that we have seen in all other OS-es that couldn't resist adding every feature they could think of.
My boot time is already up there with Windows 2003 running Ubuntu 8.04; I'd like to think we let Microsoft hold pole position in that area...
Starting Thunderbird is already starting to take scary amounts of time.
In the mean time: both csharp and 'mono attach' are very nice tools and valuable 'firsts' for the mono community. If handled with care, lot's of good will come of it !
Cheers
(1) no that app cannot be saved as part of the session, it doesn't speak bonobo, sorry
(2) get me right: VBA = good (the feature, not the language), office automation = bad (see: installing Outlook on servers; launching Word to inspect document contents by automation - eeeeeeeeeeeeeeck)
PS. Would it be possible to attach to a process, while creating a separate AppDomain in the target process? This could be a help in keeping things as secure as possible
Sure, it will "protect" the target application for all of 10 seconds, the 10 seconds it takes you to call system("rm -rf ~") which would have been a simpler, more effective attack.
Beyond all the "dangerous" stuff (hey, evil is just there), I think it opens up a whole world of great possibilities... Now it's our turn (app developers) to really make sure we get the best out of this!
Congratulations!
Sadly, this is not immediately applicable to the type of work that I do, so I will have to be satisfied with admiring this from afar.
Design wise it's better to reuse an existing design (e.g. Java), even if not proven secure, than invent our own.
Feature wise I think this is exciting mainly because we've been lacking great debugging tools for too long.
Yes, I'm pissed off -- that's because I rely on Mono on two platforms under the assumption that it is at least so-so secure code, only to learn that its developers are security-incompetent after investing hundreds of hours of development time into Mono-based app :-(
For the slower ones among us, here's the (trivial and *obvious*, mind you) attack scenario:
1. attacker dupes user into running some piece of code ("look, shiny Banshee plugin!"; this step is standard procedure, really)
2. this piece of code creates /tmp/.mono_attach_pidN for the process it wishes to attack
3. it then sends SIGQUIT (it can, it's running under *the same user*)
4. it now injects whatever piece of malicious code it pleases into the attacked process
Great job, Novell.
if you're relying on an attackers laziness to keep them from modifying a process, you've already lost.
For one, if you have a rogue user process you can ptrace any other process you have access to and inject any code you want. This is how debuggers work, and you do not need Mono for this, it works with plain old system calls. Its all there in /lib/libc.so and in your kernel.
As for the security issues raised in the previous post: they had to do with how a *different* user could get access to the feature from a different process. The answer is: they can not with our design, but we would like it peer reviewed by serious developers, someone that actually saw the source code and actually considered the issues, clearly this does not apply to you.
As for the paranoid, you can run any mono process, with a flag: --attached=disabled (you would know this if you had bothered to look at the source code).
As for your scenario, it merely proves that if you have a gun and a bullet, you can shoot yourself in the foot.
A simpler scenario is: "Attacker dupes user into running some piece of code, `look shiny XXXX plugin" as you say, this step is standard procedure.
At this point, the user has full control over everything you have control over: every file you have rights to read, write and running processes. They can wipe out all your files, back them up with a background thread to a remote location, infect every Linux binary with a virus (if they chose to write one) and scramble our files.
None of the above require the Mono.Attach functionality, and in my opinion, it is a lot simpler to do without requiring "Mono 2.2 or higher, with X, Y and Z installed" which would also be a minor target for an attack, you are much better off attacking the aliases in the ~/.bashrc of a user.
This injector is not any different than mach_inject, which is used extensively in MacOS or the *gasp* exact same functionality available in Java (http://blogs.sun.com/CoreJavaTechTips/entry/the...).
Miguel.
to the process to enable it, something most users are not likely to do.
the kernel. So only the owner of the process can start the attach functionality.
Being arrogant and dismissive doesn't change the facts, as much as you would like it. Yes, you are secure (hopefully) against other users, but some people consider security implications *other* than what you were able to came up with. That's the thing about security, somebody always comes up with something you didn't expect. People that are good at security understand that and don't get offended when somebody points out a flaw in their reasoning -- clearly this does not apply to you.
I *did* have a look at that code to verify it's as stupid as I suspected. If *you* did bother to re-read the code you linked to before accusing me of not reading it, you would know that this code does not, in fact, handle --attached flag. Must be done elsewhere.
Moreover:
1. You make it *much easier* to inject code, in portable, arch- and platform-independent way. Lower barrier to entry => easier attack. How hard is it to get this?!
2. Being able to disable the hole is not the same thing as being secure by default (you know, the time-honored security principle that gives you a chance to be secure against something you didn't anticipate)
3. No, you cannot "infect every Linux binary with a virus" -- permissions, you know. That's the dangerous thing -- I may suspect a binary I run, but not that it will sneak into other processes and get access to things the _other_ process can access. For example, you make it possible to inject code into an app that was already authenticated to access the keyring.
4. "Others do it, so it must be OK" -- seriously?! When you see two men jump from a bridge, will you follow them?
Even if the feature was not implemented, guess what, ptrace on Linux exists and you could inject the code *ANYWAYS*. We made it easier, but even if it was not there, anyone could build a library to inject the code with existing Linux syscalls.
And until you understand that the status quo did not change, you will not be able to grasp why it is a non-issue.
You have failed to show any case where this is a new security hole, until then, you seem to be speaking out of lack of proper information and understanding.
Your example about "two men jumping off the bridge" is inadequate. A more adequate example is that inside your house you do not place locks between the bedroom and the kitchen, and other seem to think that securing rooms in your house is mostly a waste of time.