Date: Sun, 27 Dec 1998 01:42:49 +0400 From: Casper <casper@acc.am> To: "freebsd-security@FreeBSD.ORG" <freebsd-security@FreeBSD.ORG> Subject: Re: Magic Message-ID: <36855859.5D0BD741@acc.am> References: <Pine.BSF.3.96.981226113610.16142A-100000@phoenix.aye.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Yep! Imm agree with Barret t , it's a most secure way , i think ........
Can You nd me this patches , i wonna work on it .....
What about include in some secure level facility to disable read of any file if
it begins with magic by user (may be by any user, including root) ? It will
disable read of these files ....
of course intruder can bruteforce by changing megic of file & looking to
response :) ... but itlll take a lot of time ...
Barrett Richardson wrote:
>
> On Fri, 25 Dec 1998, Robert Watson wrote:
>
> > On Thu, 24 Dec 1998, Barrett Richardson wrote:
> >
> > > On Fri, 25 Dec 1998, Casper wrote:
> > >
> > > > Did anyone tried to cjange loader's MAGIK in the exec's header and recompile
> > > > system ... I think it'll disallow to upload some executable and run it on target
> > > > system ......
> > > > So if you have recompiled system , chrooting all your network services - from
> > > > telnetd till httpd, ftpd & etc. , dont place compiler, mknod in chrooted dirs
> > > > and disallow reading of executable files ..only --x , how intruder can break
> > > > this protection ?
> > > > Of course i assume that system configured properly ......
> > >
> > > I used a different means to the same end. I used a flag bit that
> > > can only be set by root and require it to be set in imgact_aout.c,
> > > imgact_elf.c and imgact_gzip.c for non root users. Wrote a util
> > > to set the flag on files in /bin, /sbin, /usr/{bin,sbin},
> > > /usr/libexec, /usr/local/{bin,sbin}. Used the same return code
> > > for a bad magic number. Whenever you try to execute a binary
> > > that doesn't have the flag set it spits out "cannot execute
> > > binary file". A user can even copy a system binary to his directory,
> > > and the copy won't run -- and only root can set the flag to make it
> > > run. Got the idea from John Dyson.
> > >
> > > I have been thinking of incorporating the behaviour into one of the
> > > securelevels on my system.
> >
> > The problem with limitations on execve() are that it is very hard to tell
> > when a file is exec'd :). The execve() syscall is only one possible way
> > in which code can become executable (that is, might end up in the path of
> > execution, and in a process that might execute it). Some examples might
> > be--
> >
> > - Perl (or any other interpretter) interpretters, especially those with
> > optimization
> > - Shells with scripting
> > - Php3 support in apache
> > - Buffer overflows in any executable (not just suid ones)
> > - elisp in emacs
> > - Dynamically linked applications
> > - Debugging support
> >
> > The old LD_LIBRARY_PATH trick plays on the last one, but the ability to
> > change the shared library linked against is essentially equivilent to
> > being able to create an executable. Being able to attach with a debugger
> > might also be equivilent, if you can change mappings on the processes
> > address space, manipulate registers, code ordering, etc. I.e., you can
> > attach a debugger to joe process and cause it to act however you want just
> > by moving the instruction pointer around appropriately and single-stepping
> > it with argument modifications to syscalls. Needless to say, any debugger
> > that couldn't do this wouldn't be very useful :).
> >
> > As a simple example, I spent last night writing some simple trust analysis
> > modifications to my FreeBSD kernel on one of my notebooks. I added a
> > bunch of hooks around execve, chmod, etc, to monitor
> >
> > a) Execution of binaries owned by another user, or by a group if the file
> > is group writable
> > b) Creation, deletion of setuid binaries
> > c) Modification of ownership, interesting file modes
> >
> > Etc. That is, interesting situations from the point of view of a formal
> > trust model. I then added a syscall to pull down the stored records on
> > demand from the kernel. I'll post the results in a few days. But an
> > immediate conclusion was that most of the executable code on the system is
> > not executed using execve() :). Much of it is shell script executed as an
> > argument to the interpretter, instead of via the execve interpretter
> > support. Similarly, much is dynamically linked. When you log in, the
> > shell goes out and runs all kinds of scripts--none of this is visible via
> > execve. Similarly, insertion of code via buffer overflow is invisible to
> > monitoring at that level.
> >
> > To really crack down on this behavior, you'd have to:
> >
> > 1) remove dynamic linking against anything but strictly approved code
> > 2) not allow any manipulation of a process except through io
> > (specifically, not via a debugger where the instruction pointer can be
> > manipulated to cause it to jump around syscalls, modify arguments, etc)
> > 3) know that all programs do exactly what you want, and never anything
> > else (i.e., no interpretters, no exploitable programs, etc).
> >
> > I have concluded that it is essentially impossible to gain any serious
> > protection by restricting the binaries that may be run on the system. The
> > only good approach is through proper access control on syscalls, strong
> > authentication, and adequate protection of process resources.
> >
> > On the other hand, signed executables or a chflag flag will confuse the
> > hell out of joe hacker if joe hacker is really joe script-kiddie. :-)
> > I'm not above confusing script kiddies, but I think this flag may not
> > actually improve security, just perceived security without significant
> > modification of the OS.
> >
> > Robert N Watson
>
> Although an imperfect model I still think it useful. One can hardcode
> LD_LIBRARY_PATH in ld.so, shell scripts don't interpret binaries,
> user access can be removed from the debugger -- but perl,
> that is a bummer. In any event joe cracker has, as of yet, not been
> a problem for us but the dollars joe script kiddie has cost us is
> approaching six figures. To me expending resources of an attacker
> equates to more security (11 character passwords are more secure
> than 5 character passwords because it takes more resources to break)
> and I have added another hurdle for an attacker to overcome; made
> it less appealing to upload a suite of cracker utils from
> rootshell.com and attempt to run them on my system.
>
> An added bonus is that joe user cannot upload and run software
> packages of his choosing without my approval.
>
> --
>
> Barrett
>
> >
> > robert@fledge.watson.org http://www.watson.org/~robert/
> > PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C
> >
> > Carnegie Mellon University http://www.cmu.edu/
> > TIS Labs at Network Associates, Inc. http://www.tis.com/
> > SafePort Network Services http://www.safeport.com/
> >
> >
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-security" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36855859.5D0BD741>