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
gcore
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.
Joerg
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
