Bert JW Regeer
xistence at 0x58.com
Thu Feb 21 05:55:11 UTC 2008
On Feb 20, 2008, at 20:18 , Joerg Sonnenberger wrote:
> On Wed, Feb 20, 2008 at 09:39:03PM -0500, ari edelkind wrote:
>> Mind you, it's true that disabling core dumps with a resource limit
>> doesn't keep one from creating a core image using gcore, but since
>> generally must either attach to a process using ptrace() or access
>> mapped code segments in the original binary (depending on the
>> implementation), it won't help in such a case, either.
> What prevents me from patching the kernel (!) to just ignore the
> resource limit? Nothing.
Or for that matter ignoring the first ptrace() so that on the second
ptrace call we make we can attach without a problem?
On an open system like FreeBSD or Linux it is practically impossible
to guarantee that the binary that is encrypted can't be tampered with
in such a way, or have it's un-encrypted code dumped.
Even on Windows this is hard, since the kernel is open for so many
attack vectors, including but not limited to writing new kernel
modules that hook certain kernel functions to do what I just
mentioned. The openness of an Open Source system that allows an
attacker to easily modify the OS the executables are running on is the
biggest problem. There is no guaranteed code execution path, no
guarantee that syscall's will do what you ask them to do.
Bert JW Regeer
More information about the freebsd-hackers