Date: Tue, 25 Aug 1998 15:43:20 +0200 From: Eivind Eklund <eivind@yes.no> To: 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: <19980825154320.29030@follo.net> In-Reply-To: <199808242136.WAA00657@indigo.ie>; from Niall Smart on Mon, Aug 24, 1998 at 10:36:24PM %2B0000 References: <199808240620.BAA04415@dyson.iquest.net> <199808242136.WAA00657@indigo.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
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). 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 password with 241111005450527600328717895291292670443358181333262746781391518619604\ 665145591729660171722514729263966207029657274760829969835101821556548\ 304978870053886400523066523749566624313465787285119981924269527998407\ 383954685993679028640869483407606883707438996687240258706499417535241\ 226013998982887860608092391831248604598572478575586384534131326320640\ 0000000000000000000000000000000000000000000000000 possibilities. 396 digits (1315 bits) is actually a pretty respectable number, and should give you plenty time to detect that the attacker is testing syscalls (even if he does not need to get a perfect match, and even though he can probably find parts of the keys quickly, he will still leave traces. To get him to spend more time, also change some other parts of the calling conventions, like which numbers the different error return codes are assigned). 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. This does not mean one should rely on it, but deploying it can be helpful. If you are on the lookout, the extra 12 hours you get from breakin to the traces are hid can be a lifesaver. Eivind. 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?19980825154320.29030>