Miguel de Icaza's blog - Latest Comments in Monovation: Assembly Injection into Live Processes - Miguel de Icaza

Re: Monovation: Assembly Injection into Live Processes - Miguel de Icaza

Zoltan — Wed, 01 Oct 2008 03:05:34 -0000

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.

Re: Monovation: Assembly Injection into Live Processes - Miguel de Icaza

psantosl — Wed, 01 Oct 2008 02:55:13 -0000

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!

Re: Monovation: Assembly Injection into Live Processes - Miguel de Icaza

migueldeicaza — Tue, 30 Sep 2008 13:13:29 -0000

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.

Re: Monovation: Assembly Injection into Live Processes - Miguel de Icaza

Peter — Tue, 30 Sep 2008 12:27:15 -0000

> 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?

Re: Monovation: Assembly Injection into Live Processes - Miguel de Icaza

vsl — Tue, 30 Sep 2008 12:11:20 -0000

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.

Re: Monovation: Assembly Injection into Live Processes - Miguel de Icaza

vsl — Tue, 30 Sep 2008 12:08:58 -0000

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.

Re: Monovation: Assembly Injection into Live Processes - Miguel de Icaza

Sebastien — Tue, 30 Sep 2008 08:49:27 -0000

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.

Re: Monovation: Assembly Injection into Live Processes - Miguel de Icaza

Zoltan — Mon, 29 Sep 2008 18:06:01 -0000

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.

Re: Monovation: Assembly Injection into Live Processes - Miguel de Icaza

Tobias — Mon, 29 Sep 2008 16:15:29 -0000

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.

Re: Monovation: Assembly Injection into Live Processes - Miguel de Icaza

migueldeicaza — Mon, 29 Sep 2008 10:29:59 -0000

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.

Re: Monovation: Assembly Injection into Live Processes - Miguel de Icaza

Kamujin — Mon, 29 Sep 2008 08:35:26 -0000

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.

Re: Monovation: Assembly Injection into Live Processes - Miguel de Icaza

Hongli Lai — Mon, 29 Sep 2008 04:10:45 -0000

Good comment. This just shows that people like to get pissed off at Mono for no good reason.

Re: Monovation: Assembly Injection into Live Processes - Miguel de Icaza

Natan Yellin — Mon, 29 Sep 2008 03:53:08 -0000

Good job to everyone who worked on this. It's very neat.

Re: Monovation: Assembly Injection into Live Processes - Miguel de Icaza

migueldeicaza — Mon, 29 Sep 2008 03:32:26 -0000

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).

Re: Monovation: Assembly Injection into Live Processes - Miguel de Icaza

migueldeicaza — Mon, 29 Sep 2008 03:31:09 -0000

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.

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/CoreJa....

Miguel.

Re: Monovation: Assembly Injection into Live Processes - Miguel de Icaza

j23tom — Mon, 29 Sep 2008 03:27:27 -0000

The only thing I really miss now is file script execution (like "csharp myscript.cs")

Re: Monovation: Assembly Injection into Live Processes - Miguel de Icaza

Peter — Mon, 29 Sep 2008 01:45:31 -0000

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.