Date: Thu, 27 Aug 1998 21:16:13 +0000 From: Niall Smart <rotel@indigo.ie> To: Eivind Eklund <eivind@yes.no>, rotel@indigo.ie, dyson@iquest.net, joelh@gnu.org Cc: imp@village.org, dkelly@hiwaay.net, rabtter@aye.net, hackers@FreeBSD.ORG Subject: Re: I want to break binary compatibility. Message-ID: <199808272016.VAA01420@indigo.ie> In-Reply-To: <19980825154320.29030@follo.net>; Eivind Eklund <eivind@yes.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 25, 3:43pm, Eivind Eklund wrote: } Subject: Re: I want to break binary compatibility. > On Mon, Aug 24, 1998 at 10:36:24PM +0000, Niall Smart wrote: > > On Aug 24, 1:20am, "John S. Dyson" wrote: > > > Try modifying your system so that one of the flags bits is required to > > > run a program. It would the require both the flags bit and the executable > > > bit. Make sure the system cannot allow anyone but root set the chosen > > > flags bit. Maybe you could use the immutable flag, for this so that you > > > get theoretical immutability along with the ability to run code. You > > > might want to relax the restriction for root, but maybe not (depending > > > on how your admin scheme is setup.) > > > > None of these hacks achieve security. You, of all people, should > > know better. The original poster should figure out how they are > > breaking in and close the hole, obfuscation schemes like the above > > are a waste of time. > > As I see it, this is not an obfuscation scheme - it is a security > layer blocking anybody but root from creating runnable programs (or, > if you are running at a higher secure-level, block anybody from > creating runnable programs). You're basically trying to disable chmod +x for anyone but root, but to do that properly you have to audit every program the user has permission to execute and each library which those programs use. It's _far_ easier to understand how they are getting in. > The use of mumbled syscalls is basically a form of included > password/cryptgraphic key, so it is an obfuscation scheme - just like > using passwords is an obfuscation scheme. > > If there are no readable excutables or header files (and there had > better not be), and the syscalls are totally scrambled, you have a [snip] > (1315 bits) is actually a pretty respectable number, and should > give you plenty time to detect that the attacker is testing syscalls You're talking about the process supplying some kind of a key to the OS as part of the syscall? This is somewhat more difficult to get around, perhaps 2 or 3 days worth of work needed, since when you find the buffer overflow you also need to find a way to get the code to communicate the key to you, which of course involves a syscall. Hardly secure though, especially since the size of the password is irrelevant once its large enough to withstand brute force. > For a generally deployed system, obscurity is not protection. For a > single installation, obscurity is protection, and can very often be a > valid line of defence. Sometimes, yes, I think l0pht is an example of this. But it is not the answer in this case, since the original poster has/is being hacked, turning to obscurity to fix the problem is the wrong approach. If l0pht got hacked do you think they would try and find out how it happened or would they turn up the obscurity level? Regards, Niall -- Niall Smart, rotel@indigo.ie. Amaze your friends and annoy your enemies: echo '#define if(x) if (!(x))' >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808272016.VAA01420>