Date: Wed, 20 Feb 2008 22:54:33 -0700 From: Bert JW Regeer <xistence@0x58.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: encrypted executables Message-ID: <07F059CA-D46C-4B2E-B047-FE65E7FAA6FD@0x58.com> In-Reply-To: <20080221031856.GA17599@britannica.bec.de> References: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> <47BA3334.4040707@andric.com> <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> <20080219040912.GA14809@kobe.laptop> <f8e3d83f0802200451r463f188bn881268b9b2768846@mail.gmail.com> <47BCD34F.7010309@freebsd.org> <20080221023902.GI79355@episec.com> <20080221031856.GA17599@britannica.bec.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail-1--219709801 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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 --Apple-Mail-1--219709801--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?07F059CA-D46C-4B2E-B047-FE65E7FAA6FD>