mje@olsa99.UUCP (Mark J Elkins) (10/02/89)
Is there a manual or paper on using 'fsdb'. The AT&T User Guide say's
"Do not use - unless you know how too" and the Referance Manual only
gives a few clues. It was suggested that 'fsdb' should be used to sort
out the problem of two seemingly similar files in the same directory.
I'd also like to know what else I can fix/scramble with fsdb.
--
/"""\ Mark J Elkins, Olivetti Africa, Unix Software Support
|o.o| UUCP: {ddsw1 | olgb1 | olnl1} !olsa99!mje
\_=_/ mje@olsa99.UUCP (mje@olsa99.uunet)
#define DISCLAMERcpcahil@virtech.UUCP (Conor P. Cahill) (10/03/89)
In article <82@olsa99.UUCP>, mje@olsa99.UUCP (Mark J Elkins) writes: > Is there a manual or paper on using 'fsdb'. The AT&T User Guide say's > "Do not use - unless you know how too" and the Referance Manual only > gives a few clues. It was suggested that 'fsdb' should be used to sort > out the problem of two seemingly similar files in the same directory. > I'd also like to know what else I can fix/scramble with fsdb. WARNING: fsdb can be verrrrrrry dangerous in careless hands. The biggest precursor to using fsdb is to have a basic understanding of the underlying structure of the file system. Next you should try to play with it on a file system that doesn't matter (such as a floppy disk file system) Fsdb can be used to patch (or scramble) any part of the raw file system. In addition to fixing broken file names you can use fsdb to fix things like the following: Multiple inodes referencing the same data blocks. The file type bits on a directory get messed up and it no longer appeares as a directory. With a large directory this could be a real pain when fsck puts all of the files into lost+found. fsdb will let you patch the mode bits directly. There are zillions of other things you could do (both good and bad) to the file system with fsdb so be careful out there. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
szirin@cbnewsm.ATT.COM (seth.zirin) (10/03/89)
In article <1221@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes: > >There are zillions of other things you could do (both good and bad) to >the file system with fsdb so be careful out there. Fsdb can be used to make files "private" and prevent viewing of the contents by most others. Simply change one of the characters of the basename to a slash "/" by editing the directory entry for the file. Most versions of namei() will then not be capable of returning the inode. When you want to access your private file, perhaps to update your resume, you simply convert the slash back to something else. Of course, anyone that can figure out how to use fsdb can easily read your private file without ever touching the directory entry... Remember kids, don't do this at home. seth.zirin@att.com
bill@pd1.ccd.harris.com (Bill Davis) (10/05/89)
In article <4960@cbnewsm.ATT.COM> szirin@cbnewsm.ATT.COM writes: > >Of course, anyone that can figure out how to use fsdb can easily read your >private file without ever touching the directory entry... If this were true, it would be a nasty security hole. Just by knowing fsdb, I could look anywhere in a file system and read the contents of files. This doesn't happen here. Based on information available here, I have reason to believe it doesn't happen with the major variants of Unix. Anyone care to tell me if I am wrong VIA EMAIL to avoid spreading any "how to break a Unix system" information too widely? Or better yet, if you find a version of Unix that lets someone other than root run fsdb and get information out of it (or worse yet, change it), perhaps you might want to tell your system vendor about it. You probably don't want your system to remain that way. -- * Truth comes as an enemy only to those who have lost the ability to welcome * * it as a friend. ** Be thankful for your troubles. If your job did not have * * problems, they could hire someone else to do your job at half the cost. * Bill Davis EMAIL: w.davis@ccd.harris.com (<-best) uunet!hcx1!pd1!bill
cpcahil@virtech.UUCP (Conor P. Cahill) (10/05/89)
In article <572@pd1.ccd.harris.com>, bill@pd1.ccd.harris.com (Bill Davis) writes: > In article <4960@cbnewsm.ATT.COM> szirin@cbnewsm.ATT.COM writes: > >Of course, anyone that can figure out how to use fsdb can easily read your > >private file without ever touching the directory entry... > > If this were true, it would be a nasty security hole. > Just by knowing fsdb, I could look anywhere in a file > system and read the contents of files. This is true, but it depends upon one fact: The user can read the disk device directly. Most systems do not permit this so there is no problem. If the mode of /dev/[r]dsk/* allows read permission, any program will be able to read information from any file on the system, totally bypassing the standard protections. Fsdb is just a program that already understands the underlying fs layout, so it would be easier. This should not be a problem, because all systems should limit the access to the disk device files. > This doesn't happen here. Based on information > available here, I have reason to believe > it doesn't happen with the major variants of Unix. > Anyone care to tell me if I am wrong VIA EMAIL > to avoid spreading any "how to break a Unix system" > information too widely? Or better yet, if you find > a version of Unix that lets someone other than > root run fsdb and get information out of it (or > worse yet, change it), perhaps you might want to tell > your system vendor about it. You probably don't > want your system to remain that way. This is not a function of fsdb, but a function of the access modes of the /dev/dsk files. This is true for *ALL* versions of unix (allowing for different paths to the different disk devices). -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/05/89)
In article <572@pd1.ccd.harris.com> bill@pd1.ccd.harris.com (Bill Davis) writes: >In article <4960@cbnewsm.ATT.COM> szirin@cbnewsm.ATT.COM writes: >>Of course, anyone that can figure out how to use fsdb can easily read your >>private file without ever touching the directory entry... >If this were true, it would be a nasty security hole. fsdb has to be able to access the disk device special file for this to be a problem. The two most probable ways for this to occur are for fsdb to be installed setUID, or for the special file inode to have too liberal access permissions set.
jfh@rpp386.cactus.org (John F. Haugh II) (10/05/89)
In article <572@pd1.ccd.harris.com> bill@pd1.ccd.harris.com (Bill Davis) writes: >In article <4960@cbnewsm.ATT.COM> szirin@cbnewsm.ATT.COM writes: >>Of course, anyone that can figure out how to use fsdb can easily read your >>private file without ever touching the directory entry... > >If this were true, it would be a nasty security hole. >Just by knowing fsdb, I could look anywhere in a file >system and read the contents of files. It is quite true, and you don't need fsdb [ but it sure does make things easier ;-) ] To prevent this your block devices can not be readable by normal users. >This doesn't happen here. Based on information >available here, I have reason to believe >it doesn't happen with the major variants of Unix. >Anyone care to tell me if I am wrong VIA EMAIL >to avoid spreading any "how to break a Unix system" >information too widely? Or better yet, if you find >a version of Unix that lets someone other than >root run fsdb and get information out of it (or >worse yet, change it), perhaps you might want to tell >your system vendor about it. You probably don't >want your system to remain that way. fsdb -may- have its access modes restricted to root only, but this does not prevent someone from writing an fsdb clone and posting it to the net so everyone can use it. However, any system which still has adb on it has all that is really needed for file system maintenance. I have used adb [ just yesterday in fact ] to break into UNIX systems. My floppy devices are world accessible, so I mounted a floppy and created a SUID root program. Seems I trashed /etc/shadow and couldn't login as root ;-( -- John F. Haugh II +-Things you didn't want to know:------ VoiceNet: (512) 832-8832 Data: -8835 | The real meaning of MACH is ... InterNet: jfh@rpp386.cactus.org | ... Messages Are Crufty Hacks. UUCPNet: {texbell|bigtex}!rpp386!jfh +--------------------------------------
lehners@uniol.UUCP (Joerg Lehners) (10/05/89)
Hello ! bill@pd1.ccd.harris.com (Bill Davis) writes: >In article <4960@cbnewsm.ATT.COM> szirin@cbnewsm.ATT.COM writes: >> >>Of course, anyone that can figure out how to use fsdb can easily read your >>private file without ever touching the directory entry... >If this were true, it would be a nasty security hole. >Just by knowing fsdb, I could look anywhere in a file >system and read the contents of files. No, fsdb is not a security hole. The probabaly world-readable character and block device special entries in /dev are the security holes. I know about System V.2 and System V.3. In System V.2 all device files are public readable to allow df to detremine the free block/inode count. Maybe there are some other program that need direct filesystem access. System V.3 made all these special files unreadable for the normal user. To determine the blocks/inodes count there s special systemcall. The same things happened to /dev/mem and /dev/kmem. System V.2: /dev/mem and /dev/kmem world readable; System V.3: /dev/mem and /deb/kmem protected and s-bit on /bin/ps (non-root) When fsdb is a security hole then the files in /usr/include/sys are all security holes too, and Bach's Book 'The Design Of An Operating System' is a security hole too. Almost all information to build an fsdb on your own is in /usr/include/sys/* and some books. >[a bit deleted] >..... >a version of Unix that lets someone other than >root run fsdb and get information out of it (or >worse yet, change it), perhaps you might want to tell >your system vendor about it. You probably don't >want your system to remain that way. Ok, I might be wise to protect fsdb from beeing executed by normal user's (no problem, I think) to prevent looking at protected files. But what about a copy of fsdb from somewhere else in some users directory ? Get a machine and try out protecting the special files for the disks and memory, and then do the right s-bit setting. Joerg -- / Joerg Lehners | Fachbereich 10 Informatik ARBI \ | | Universitaet Oldenburg | | BITNET/EARN: 066065@DOLUNI1.BITNET | Ammerlaender Heerstrasse 114-118 | \ UUCP/Eunet: lehners@uniol.uucp | D-2900 Oldenburg /
lehners@uniol.UUCP (Joerg Lehners) (10/05/89)
Hello again ! I forgot a final word in my previous posting: Executables without special privileges (ie. without s-bits) should never be security holes. Are such beast around ? If so if would like to hear about such things. Joerg -- / Joerg Lehners | Fachbereich 10 Informatik ARBI \ | | Universitaet Oldenburg | | BITNET/EARN: 066065@DOLUNI1.BITNET | Ammerlaender Heerstrasse 114-118 | \ UUCP/Eunet: lehners@uniol.uucp | D-2900 Oldenburg /
szirin@cbnewsm.ATT.COM (seth.zirin) (10/06/89)
In article <4960@cbnewsm.ATT.COM> szirin@cbnewsm.ATT.COM writes: >Of course, anyone that can figure out how to use fsdb can easily read your >private file without ever touching the directory entry... Sorry for the scare. It was assumed that the user of fsdb would have root access. The whole purpose of putting a slash in the filename is to prevent another root user from getting at the file text. A chmod 600 provides privacy from mortal readers. Putting a ^H into a file name also confuses people... seth zirin
clive@ixi.uucp (10/06/89)
In article <572@pd1.ccd.harris.com> bill@pd1.ccd.harris.com (Bill Davis) writes: >In article <4960@cbnewsm.ATT.COM> szirin@cbnewsm.ATT.COM writes: >>Of course, anyone that can figure out how to use fsdb can easily read your >>private file without ever touching the directory entry... >If this were true, it would be a nasty security hole. >Just by knowing fsdb, I could look anywhere in a file >system and read the contents of files. > >This doesn't happen here. Based on information available here, I have reason >to believe it doesn't happen with the major variants of Unix. Anyone care to >tell me if I am wrong VIA EMAIL to avoid spreading any "how to break a Unix >system" information too widely? There's no need to panic, and it is quite safe to post this. Yes it is true that fsdb allows you to look anywhere in a file system, and so on, but it requires access to the disc device (/dev/dsk/... on my machine). If you make these owned by root or sys with 600 permissions, then noone else can use fsdb to break security. If anyone can read these devices, then they don't need fsdb to do it - adb, or at worst, od (!) is enough. -- Clive D.W. Feather IXI Limited clive@ixi.uucp ...!uunet!ukc!ixi!clive (riskier)
cpcahil@virtech.UUCP (Conor P. Cahill) (10/06/89)
In article <890@uniol.UUCP>, lehners@uniol.UUCP (Joerg Lehners) writes: > Hello again ! > > I forgot a final word in my previous posting: > > Executables without special privileges (ie. without s-bits) should > never be security holes. > Are such beast around ? If so if would like to hear about such things. How about standard named executables without s-bits that are accidently run by non-suspecting s-people. like an "ls" in /tmp. Chances are that it will be run by another user, maybe not root, but at least another user. Then you have that user's capabilities.... -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
chris@hpgnd.HP.COM (Christian LOTITO) (10/09/89)
Is fsdb able to "undo' an rm ? Chris Lotito / Hewlett-Packard France
pa1034@sdcc13.ucsd.EDU (The Evil) (10/10/89)
In article <890@uniol.UUCP> lehners@uniol.UUCP (Joerg Lehners) writes: >Executables without special privileges (ie. without s-bits) should >never be security holes. >Are such beast around ? If so if would like to hear about such things. Any program which is publicly executable can potentially be a security hole. A program can be non-SUID and still have code like: { exec shell to cp /bin/sh /tmp/sushi. Now that the /tmp/sushi is owned by current owner, do a chmod 6777 on it. } Surprise! the user now has the privileges of whoever runs this program. if root runs it, BIG SURPRISE!!! If someone gets superuser privileges he can change, or rewrite some of the more common utilities to bestow privileged SUID bits on shell programs when the corresponding user uses the program. (e.g. whenever root does an 'ls' now, he unknowingly creats a root trap door for an intruder.) Of course, don't leave programs open to the public. (Then they don't need root privilege to do this.) >/ Joerg Lehners | Fachbereich 10 Informatik ARBI \ John Marco pa1034@iugrad2.ucsd.edu
cpcahil@virtech.UUCP (Conor P. Cahill) (10/11/89)
In article <4420001@hpgnd.HP.COM>, chris@hpgnd.HP.COM (Christian LOTITO) writes: > > Is fsdb able to "undo' an rm ? No and yes. fsdb does have the capability to make all of the modifications to the file system to "create" a new file out of blocks of information from a previously removed file, however due to UNIXs cleaning up after itself this is not a real option. The problems you would run into in trying to do this would include: 1. The inode number in the directory is cleared, so you don't know what inode the file used. 2. If you by some unknown reason, know the inode number that the file had used, it wont help because the inode is cleared and all of the block addresses are set to 0 (and indirect blocks are returned to the free list). 3. If, by some unbelievable stroke of luck, just happen to have recorded the blocks used by the file on a scrap of paper next to your terminal, you will still have a problem as the kernel wrote the free list linkage info into the data blocks (I *think*). 4. If you are able to reconstruct this far, then you are a miracle worker and won't need to worry about what the actual size of the file was (since that info is also lost from the inode and the file was probably not a multiple of a block). Thats all I can of off of the top of my head. Oh yeah, being able to do even this, relys on the fact that the file system the file in question resides on is quiet from the time the file is removed to the time you are trying to restore the file. Good luck -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
jc@minya.UUCP (John Chambers) (10/13/89)
In article <Oct89.064644.7768@ixi.uucp>, clive@ixi.uucp writes: > There's no need to panic, and it is quite safe to post this. Yes it is true > that fsdb allows you to look anywhere in a file system, and so on, but it > requires access to the disc device (/dev/dsk/... on my machine). If you make > these owned by root or sys with 600 permissions, then noone else can use fsdb > to break security. If anyone can read these devices, then they don't need fsdb > to do it - adb, or at worst, od (!) is enough. You'll likely have to do a bit more than that. Some utilities (df is a good example) read the device, so if you put 600 permissions on the device, you must make /bin/df setuid to the device's owner. Sys/V seems to come with df setuid-root, presumably for this reason. Alternatively, if you don't like setuid-root programs lying about, you can make the device 640, and make /bin/df setgid to whatever group you put the devices in (sys is a good choice). That's what I've done here, and it works just fine. There are a couple of other programs, too, but their names escape me at the moment. -- #echo 'Opinions Copyright 1989 by John Chambers; for licensing information contact:' echo ' John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)' echo '' saying