Re: Patching an application (long)
Re: Patching an application (long)
- Subject: Re: Patching an application (long)
- From: "Sven A. Schmidt" <email@hidden>
- Date: Fri, 17 Jan 2003 11:43:36 +0100
On Freitag, Januar 17, 2003, at 01:48 Uhr, Jeff Disher wrote:
As far as I can tell, they are not modifying the behavior of an
arbitrary application, just the one that they are writing.
I know nothing about the behavior of APE but I know that categories
(and derivative ideas like the mentioned "MethodSwizzling") only
affect the application that they are loaded into.
But you can load it into any/all application/s. With my current setup,
I identify a target process by name and patch into that. I could patch
them all.
This makes sense since you cannot just start manipulating the memory
of arbitrary programs at run-time in a protected memory system.
Categories only modify the implementation pointers maintained by the
runtime which is a per-application structure (which calls into shared
memory blocks). Modifying the runtime does not modify the shared
memory that it makes calls to.
Thus, it is not a security in the slightest since you are always free
to make your own programs insecure (but there are much more efficient
ways to do that).
Like I said, I don't think this works for root's (or any other user's)
processes, but still there are evil things possible: Write a useful
shareware app to introduce it to a target machine and have patching
code in there that hooks into all text fields. This would work for
'Keychain Access' for example, which runs as a user process, and has
'interesting' text fields.
The only way, that I know of, that you can manipulate the behavior of
all programs is by changing the code that it links to, to do something
else. I am not even sure if that is possible given the way that
Mach-O linking occurs in the two-level namespace it now uses (but I
could be wrong, anyone?). Even if it can be done, however, you would
have to write this malicious code to the read-only Frameworks
directory where the other programs are expecting to see the code.
Since only root can write to that directory, you would have to
deliberately run a malicious installer of some sort with super use
privileges.
Having "signed" application is a bad idea, in my opinion. Also, as
far as I can tell, you already have that functionality with the
built-in protected memory of the OS.
I might be incorrect in any of these things (especially that linking
one, it is sort of a guess) but everyone seems to worry about this
whenever someone explains runtime hacking to them for the first time,
and this seems like another one of those.
Does that sound right?
AFAIK right now, APE (and libPatch?) use features similar to gdb to
attach to running code. What's good in one case (debugging) can be
turned to evil purposes in other cases.
But what would you rather have, no debugger, no WindowShade haxies or
TextExtras and instead a patch safe machine? It's like computer
security: the safest box is the one powered off. As soon as you power
it on, you're making yourself available to crashing programs and kernel
panics. Plugging it into the network takes you to the next set of
problems.
Since the patching mechanism (I believe) relies on features of the gnu
linker/debugger toolset it's nothing particular to OSX. You could
probably do similar things on Linux.
People on Windows are patching all kinds of running processes: Many
online games store game information on the servers only to prevent
cheating -- now the running program is patched to cheat. OSX doesn't
sport many online games so people have to patch productivity apps :-)
What I'm trying to say is, patching is not a 'problem' native to OSX.
Due to the features of the objc runtime system it's probably a lot
easier, though. In fact, I'm the best proof.
I don't think there's a way to automatically safe guard against evil
patching. Users have to be careful what programs they start, even more
so on important machines like servers. Trojans are usually spotted by
the community pretty quickly. Be careful who you trust and quarantine
apps before you deploy them on important systems.
Sven
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.