SCEF0003%WSUVM1.BITNET@cornellc.cit.cornell.edu (James N. Petersen) (09/07/90)
Recently, we had a graduate student leave, after having changed the password for root on our UNIX V/3.2.2 system (AT&T UNIX/386). Is there any way we can get in and reset the password to a known value?
bzs@cs.bu.edu (Barry Shein) (09/07/90)
Well, you might consider putting the hard disk as a second disk on
another system and just edit the password file.
-Barry Shein
Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD2307GILLV%MUCSD.BITNET@cunyvm.cuny.edu (09/07/90)
Hmm, I believe not. If there were such a backdoor, it would be internal to AT&T. They would *not* make it public. I suggest that you use the backup account and backup, then reload the system and restore.
vu0310@bingvaxu.cc.binghamton.edu (R. Kym Horsell) (09/07/90)
In article <24411@adm.BRL.MIL> SCEF0003%WSUVM1.BITNET@cornellc.cit.cornell.edu (James N. Petersen) writes: >Recently, we had a graduate student leave, after having changed the >password for root on our UNIX V/3.2.2 system (AT&T UNIX/386). Is there >any way we can get in and reset the password to a known value? The only sure-fire (unless you want to hack in & I'm not going to send _anyone_ info like that) method is to boot the system from floppy, tape, whatever, and mount the filesystem of interest & then edit the /etc/passwd file. -Kym Horsell =====
ESANCHEZ@udlapvms.pue.udlap.mx (esanchez) (09/07/90)
I don't know if the following solution works for you, but in a SUN machine you boot in single user mode and the machine gives you the root prompt without asking you for the password (of course, this works if the C2 security level is not installed). It is to say, try to boot your machine in singl;e user mode and good luck... __________________________________________ Enrique Sanchez Lara internet: esanchez@udlapvms.PUE.UDLAP.MX P.S. If your machine is connected to a network, maybe you can do a "rlogin" as root from other machine that has a hosts.equiv or .rhosts entry giving free access to the root of that machine _____________________________________________
yenal%TRBILUN.BITNET@cunyvm.cuny.edu (Yenal Gogebakan) (09/07/90)
What about booting in single user mode.If your system is not secure enough :-) you con login as root.
aeba-im-o-e2@berlin-emh1.army.mil ( Kendrick Gibson) (09/07/90)
Maybe you can boot from a backup tape. Either the original or a recent backup tape that you know the password of. Just a suggestion- we have a sector on our hard drive that has root without a password. We could boot from it if necessary. Of course we have to trust anyone with physical access to our computer not to reboot it and set themself up as superuser. If/when you do get in, you might consider copying root to an unmounted slice. Ken Gibson aeba-im-o-e2@berlin-emh1.army.mil I'd rather be telecommuting. DISCLAIMER: The opinions stated herein may coincidentaly corelate with the opinions of some organization somewhere.
amoss@huji.ac.il (Amos Shapira) (09/07/90)
SCEF0003%WSUVM1.BITNET@cornellc.cit.cornell.edu (James N. Petersen) writes: >Recently, we had a graduate student leave, after having changed the >password for root on our UNIX V/3.2.2 system (AT&T UNIX/386). Is there >any way we can get in and reset the password to a known value? Well, I have never operated a UNIX on a PC, but in general, there should be a way to boot the system to single user, this should give you a root shell without having to know the password (at least on the CCI and the VAX I operated here). But maybe because anyone could access the machine physically, this option is not avialable in this case. Hope this helps, Amos Shapira amoss@batata.huji.ac.il
bdsz@cbnewsl.att.com (bruce.d.szablak) (09/07/90)
If memory serves, you should be able to boot off of the boot floppy provided in the base distribution, mount the root file system and edit the password file. I did something like this when I clobbered /unix and had to rebuild it (you should always keep a backup copy; say: /ounix). You could also accomplish the same thing from MSDOS using Norton utilities, but that might be a little more adventuresome (but more educational). By the way, this is a good reason to ALWAYS lock your PC when the console is not in use.
ron@cs.athabascau.ca (Ron Haukenfrers) (09/07/90)
SCEF0003%WSUVM1.BITNET@cornellc.cit.cornell.edu (James N. Petersen) writes: >Recently, we had a graduate student leave, after having changed the >password for root on our UNIX V/3.2.2 system (AT&T UNIX/386). Is there >any way we can get in and reset the password to a known value? One of the quickest ways is to boot off disk 1 in the distribution disks, halt the install and get the micro kernel running. You then can mount the root file system and modify the passwd file. This does work as I've had to perform this little operation myself. Instructions for booting off the flop are in the Admin Guide, 6-23, Recovery From Major Hard Disk Damage. Ron Haukenfrers {alberta,cbmvax,decwrl}!atha!ron Educational Computing or ron@cs.AthabascaU.CA Athabasca University
hliao%opus@calstatela.edu (Henry Liao) (09/08/90)
Here is the easiest way to reset root's password on UNIX V/3.2.2.
boot UNIX from floppy (base system 1 of 7)
press <DEL> to interrupt INSTALL script
mount /dev/dsk/0s1 on /mnt
modify root entry in /mnt/etc/shadow with ed
sync disk
umount /mnt
-Henry Liao
California State University, Los Angeles
Networking Distributed & Systems Group
BitNET: ketaiak@calstate.bitnet, hliao@csula.bitnet
InterNET: hliao@{atss,csulavax,neptune,opus}.calstatela.edu
ATTMAIL: attmail!atss!hliaotag@mtunf.ATT.COM (Tom Gillespie) (09/08/90)
In article <24411@adm.BRL.MIL> SCEF0003%WSUVM1.BITNET@cornellc.cit.cornell.edu (James N. Petersen) writes: >Recently, we had a graduate student leave, after having changed the >password for root on our UNIX V/3.2.2 system (AT&T UNIX/386). Is there >any way we can get in and reset the password to a known value? The following procedure assumes that you have the first disk of the Base System Package readily available, that your root disk is 0s1 and your /usr disk is 0s3: 1) shut the machine down -- use the "FACE" system administration menu, assuming that you have another login which has sysadm privileges (look in /etc/.useradm) if not, hit the reset switch and hope for little filesystem damage 2) insert the first disk of the Base System Package and reboot 3) wait for the "Strike ENTER to install the UNIX System on your hard disk" prompt. 4) Press the <del> key. After a few moments, a # prompt will appear. 5) execute the following: fsck -y /dev/dsk/0s1 fsck -y /dev/dsk/0s3 mount /dev/dsk/0s1 /mnt mount /dev/dsk/0s3 /usr <<=== if this fails, do "mkdir /usr" and try again PATH=$PATH:/mnt/bin:/mnt/etc:/usr/bin TERM=at386 6) edit the following files: /etc/shadow -- delete the password (second filed of the line) for root /etc/default/login -- if there is a line that reads PASSREQ=YES, remove it 7) execute: umount /dev/dsk/0s3 umount /dev/dsk/0s1 8) hit the reset switch and remove the diskette 9) when the machine comes up, login as root (there should be no password now) and set a new password (and fiex /etc/default/login, if desired) Tom Gillespie att!mtunf!tag tag@mtunf.att.com
saus@media-lab.media.mit.edu (Mark Sausville) (09/08/90)
Date: Thu, 6 Sep 90 18:10:22 -0400
From: Barry Shein <bzs@cs.bu.edu>
Well, you might consider putting the hard disk as a second disk on
another system and just edit the password file.
-Barry Shein
Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
Very much to the point. By the way, have you heard from Max (Alix) lately?
I haven't and I'm a bit worried about her.
Mark.
Mark Sausville MIT Media Laboratory
617-253-0325 Room E15-354
Fax: 617-258-6264 20 Ames Street
saus@media-lab.media.mit.edu Cambridge, MA 02139tims%com@uunet.uu.net (Tim Sesow (Rocky Mntn)) (09/08/90)
The only way to get back into root once you have lost the password is to boot the system in single-user mode. The UNIX installation manual for your system probably tells how to do this. It varies from system to system. Once you are in single user mode, edit the /etc/password file to remove the password (second field in line that starts with "root"). Then just type a CONTROL-D to start up in multi-user mode, login as root (no password required), and set a new password.
pjh@mccc.uucp (Pete Holsberg) (09/08/90)
Get the distribution diskettes and boot from number 1 (of 7). At the first prompt, hit DEL. This gives you a root prompt for the OS on the floppy. fsck /dev/dsk/0s1 and then mount it. Copy /mnt/etc/passwd to /mnt/etc/tmp.passwd. Copy /etc/passwd to /mnt/etc/passwd. Do the same shuffle with the shadow password file. Now unmount the HD, give a couple of syncs, and run uadmin 2 2 to reboot. I had to do a similar thing just this morning! Pete -- Prof. Peter J. Holsberg Mercer County Community College Voice: 609-586-4800 Engineering Technology, Computers and Math UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690 Internet: pjh@mccc.edu Trenton Computer Festival -- 4/20-21/91
art@pilikia.pegasus.com (Art Neilson) (09/09/90)
In article <24411@adm.BRL.MIL> SCEF0003%WSUVM1.BITNET@cornellc.cit.cornell.edu (James N. Petersen) writes: >Recently, we had a graduate student leave, after having changed the >password for root on our UNIX V/3.2.2 system (AT&T UNIX/386). Is there >any way we can get in and reset the password to a known value? If you have a bootable UNIX on diskette, you can boot from your floppy drive and mount the harddisk on the floppy filesystem. Then it's easy to cd onto the harddisk and modify etc/passwd. You may be able to do this using your UNIX installation boot disk by breaking out of the install with the interrupt (DEL usually) key as soon as the first question is asked. I know this is possible with ISC UNIX, which is AT&T UNIX V/3.2 based. -- Arthur W. Neilson III | ARPA: art@pilikia.pegasus.com Bank of Hawaii Tech Support | UUCP: uunet!ucsd!nosc!pegasus!pilikia!art
tin@smsc.sony.com (Tin Le) (09/09/90)
In article <24411@adm.BRL.MIL> SCEF0003%WSUVM1.BITNET@cornellc.cit.cornell.edu (James N. Petersen) writes: >Recently, we had a graduate student leave, after having changed the >password for root on our UNIX V/3.2.2 system (AT&T UNIX/386). Is there >any way we can get in and reset the password to a known value? Since it's on an 386 system, I assume you can boot MSDOS. I've had it happened to me where the passwd file got erased (Microport V/286) but the file systems were fine. The fix is to boot DOS, run a sector/disk edior like Norton, search for /etc. It's should be easier for you to fix things as your passwd file is still there. Search for that file, by looking for "root:" without the quotes Then erase the encoded password by retyping that line, moving all other information from the right side over. That's all there is to it. In my case, I was lucky enough to have an old password file laying around call /etc/opasswd. Good luck! -- Tin Le -- . --------------------------------------------------------------- . tin@smsc.sony.com | {uunet,mips}!sonyusa!tin . (408) 944-4157
ars@PacBell.COM (Andy Soravilla) (09/11/90)
Is this something that should be bandied about on the net?? Or am I being too picky? Andy
lau@efi.com (Garrett Lau) (09/12/90)
In article <7961@pbhyf.PacBell.COM> ars@PacBell.COM (Andy Soravilla) writes: >Is this something that should be bandied about on the net?? Or am I >being too picky? Well, it is common knowledge, as you can tell by the number of replies. The real question is: Why is this in comp.unix.internals? Isn't there a newsgroup called comp.unix.admin? It seems like the reorganization of comp.unix.* didn't accomplish anything besides alienating a lot of wizards. -- Garrett Lau lau@efi.com uunet!efi!lau Electronics for Imaging, Inc. San Bruno, California
ray@ctbilbo.UUCP (Ray Ward) (09/12/90)
In article <7961@pbhyf.PacBell.COM>, ars@PacBell.COM (Andy Soravilla) writes: > > Is this something that should be bandied about on the net?? Or am I > being too picky? Yes, you are being too picky. Lighten up... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ray Ward Email: uunet!ctbilbo!ray Voice: (214) 991-8338x226, (800) 331-7032 Fax : (214) 991-8968 =-=-=-=- There _are_ simple answers, just no _easy_ ones. -- R.R. -=-=-=-=
SCEF0003%WSUVM1.BITNET@cornellc.cit.cornell.edu (James N. Petersen) (09/12/90)
Thanks for all who offered suggestions as to how to get to root when the password has been lost. The solution lies in booting into the single user version, then mounting the disks and editing the shadow file. Again, thanks to all.
bill@twg.wimsey.bc.ca (Bill Irwin) (09/16/90)
In <7961@pbhyf.PacBell.COM> ars@PacBell.COM (Andy Soravilla) writes: >Is this something that should be bandied about on the net?? Or am I >being too picky? >Andy You are right..it shouldn't be. Why don't we start talking about hot wiring cars and picking locks? -- Bill Irwin - TWG The Westrheim Group - Vancouver, BC, Canada ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ uunet!van-bc!twg!bill (604) 431-9600 (voice) | UNIX Systems bill@twg.wimsey.bc.ca (604) 431-4329 (fax) | Integration
flee@dictionopolis.cs.psu.edu (Felix Lee) (09/17/90)
>You are right..it shouldn't be. Why don't we start talking about hot >wiring cars and picking locks? Wrong newsgroup. They talk about those things in misc.security. -- Felix Lee flee@cs.psu.edu
mboen@nixpbe.UUCP (Martin Boening) (09/18/90)
In <253@twg.wimsey.bc.ca> bill@twg.wimsey.bc.ca (Bill Irwin) writes: >In <7961@pbhyf.PacBell.COM> ars@PacBell.COM (Andy Soravilla) writes: >>Is this something that should be bandied about on the net?? Or am I >>being too picky? >>Andy >You are right..it shouldn't be. Why don't we start talking about hot >wiring cars and picking locks? Why shouldn't it be. Where else would you get the information (unless it says in the manuals). Besides, why would you want to restrict the flow of commonly known information? As for the other: that rather belongs into rec.auto.* and has nothing to do in this group, so there I'm being picky :-). So long, Martin -- Email: in the USA -> mboening.pad@nixdorf.com outside USA -> mboening.pad@nixdorf.de Paper Mail: Martin Boening, Nixdorf Computer AG, PSD-C63 Pontanusstr. 55, 4790 Paderborn, W.-Germany (Phone: +49 5251 146155)
jak@sactoh0.SAC.CA.US (Jay A. Konigsberg) (09/21/90)
>Is this something that should be bandied about on the net?? Or am I >being too picky? >Andy > >>You are right..it shouldn't be. Why don't we start talking about hot >>wiring cars and picking locks? > While there are several ways of busting root that shouldn't be public, there _is_ one way normally available _only_ available to the System Administrator. Do a partial restore of the OS. -- ------------------------------------------------------------- Jay @ SAC-UNIX, Sacramento, Ca. UUCP=...pacbell!sactoh0!jak If something is worth doing, its worth doing correctly.
cooper@hpsrad.enet.dec.com (cooper in the shadows) (10/05/90)
In article <4029@sactoh0.SAC.CA.US>, jak@sactoh0.SAC.CA.US (Jay A. Konigsberg) writes... >While there are several ways of busting root that shouldn't be public, >there _is_ one way normally available _only_ available to the System >Administrator. >Do a partial restore of the OS. Unless the procedure has changed in the last 6 years you shouldn't have to go this far. You should just be able to reboot the system as standalone and you are automagically logged in as root from the booting terminal. Please note that I didn't see the original message so I could definitely be missing something here. shades ============================================================================ | He paid too high a price for living | Geoffrey D. Cooper | | too long with a single dream..... | cooper@hpsrad.enet.dec.com | |-------------------------------------| business (508) 467-3678 | | decwrl!hpsrad.enet.dec.com!cooper | home (617) 925-1099 | ============================================================================ Note: I'm a consultant. My opinions are *MY* opinions.
sarima@tdatirv.UUCP (Stanley Friesen) (10/09/90)
In article <15807@shlump.nac.dec.com> cooper@hpsrad.enet.dec.com (cooper in the shadows) writes: >>Do a partial restore of the OS. >Unless the procedure has changed in the last 6 years you shouldn't >have to go this far. You should just be able to reboot the system as >standalone and you are automagically logged in as root from the >booting terminal. Things *have* changed in the last 6 years. Many (or most) vendors now deliver a UNIX that requires the root password to enter single-user mode. Thus, without the root password, you cannot get into the standalone mode. The partial resore may indeed be the only 'legitimate' way back in. x x x -- --------------- uunet!tdatirv!sarima (Stanley Friesen)
wdh@holos0.uucp (Weaver Hickerson) (10/10/90)
I missed the first part of this thread, but it appears that someone is trying to be root but nobody knows the root passwd. Happened to me one time on an NCR Tower due to the fact that, if /etc/passwd had a blank line as line one, nobody could login (or was it that everybody could login as root, or...) anyway, I did a find and found a file that was setuid, belonged to root, and was writable by me. I wrote a small 'C' program to change the permissions on /etc/passwd to rw-rw-rw (temporarily, of course), linked the program, cat'ted that into the setuid file, and voila. Edit the passwd file, fix it, chmod, away we go... Luckily I was on a development system, and some of the software used root setuid. Maybe you're as lucky. Good luck Weaver -- -Weaver Hickerson Voice (404) 496-1358 : ..!edu!gatech!holos0!wdh
jik@athena.mit.edu (Jonathan I. Kamens) (10/14/90)
In article <1990Oct10.150848.3143@holos0.uucp>, wdh@holos0.uucp (Weaver Hickerson) writes: |> anyway, I did a find and found a file that was setuid, |> belonged to root, and was writable by me. I wrote a small 'C' program to |> change the permissions on /etc/passwd to rw-rw-rw (temporarily, of course), |> linked the program, cat'ted that into the setuid file, and voila. From the man page write(2) on my BSD 4.3 (well, actually, IBM AOS, but it's close enough) system: If the real user is not the super-user, then write clears the set-user-id bit on a file. This prevents penetration of system security by a user who captures a writable set-user- id file owned by the super-user. I consider this to be a very important security feature; the fact that you were able to use its absence to break into root, after obtaining only access to a generic non-root account, is good evidence of this. Does the NCR Tower not have this in its kernel (if so, I would complain to your vendor!!)? -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
skdutta@cs.tamu.edu (Saumen K Dutta) (10/15/90)
In article <1990Oct14.132119.27827@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes:
->|> anyway, I did a find and found a file that was setuid,
->|> belonged to root, and was writable by me. I wrote a small 'C' program to
->|> change the permissions on /etc/passwd to rw-rw-rw (temporarily, of course),
->|> linked the program, cat'ted that into the setuid file, and voila.
->
->From the man page write(2) on my BSD 4.3 (well, actually, IBM AOS, but it's
->close enough) system:
->
-> If the real user is not the super-user, then write clears
-> the set-user-id bit on a file. This prevents penetration of
-> system security by a user who captures a writable set-user-
-> id file owned by the super-user.
->
->I consider this to be a very important security feature; the fact that you
->were able to use its absence to break into root, after obtaining only access
->to a generic non-root account, is good evidence of this. Does the NCR Tower
->not have this in its kernel (if so, I would complain to your vendor!!)?
->
In a different context I found that this feature is not implemented in
uucp. Sometime back I used to work on SCO-XENIX 2.2.1 and while sending
mails through UUCP, I noticed that if the sender machine sends a file
with set-uid on, the file is stored in the destination machine with
set-uid on. This may be considered as a security breach as an ordinary
user can have access to all uucp files on the remote machine. I would like
to know if other unix versions also permits the same.
Thanks
--
_ ||Internet: skdutta@cssun.tamu.edu
( /_ _ / --/-/- _ ||Bitnet : skd8107@tamvenus.bitnet
__)_/(_____(_/_(_/_(_(__(_/_______ ||Uucp : uunet!cssun.tamu.edu!skdutta
.. ||Yellnet: (409) 846-8803wdh@holos0.uucp (Weaver Hickerson) (10/16/90)
In article <1990Oct14.132119.27827@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: >In article <1990Oct10.150848.3143@holos0.uucp>, wdh@holos0.uucp (Weaver Hickerson) writes: >|> anyway, I did a find and found a file that was setuid, >|> belonged to root, and was writable by me. I wrote a small 'C' program to >|> change the permissions on /etc/passwd to rw-rw-rw (temporarily, of course), >|> linked the program, cat'ted that into the setuid file, and voila. > >From the man page write(2) on my BSD 4.3 (well, actually, IBM AOS, but it's >close enough) system: > [ Stuff about how BSD write(2) turns off setuid bit deleted ] >I consider this to be a very important security feature; the fact that you >were able to use its absence to break into root, after obtaining only access >to a generic non-root account, is good evidence of this. Does the NCR Tower >not have this in its kernel (if so, I would complain to your vendor!!)? > Interesting. I've never seen any mention of this in SysV documentation. I just checked SCO Xenix -- no mention. I did the deed on my Xenix box, voila SUID file owned by root, rwsrwxrwx, now contains my own program. (First I had to use root privilege to create the file, of course. None lying around, by any means :) My account is "generic non-root", since my UID is not 0. Is that security feature part of SVID at all, or just BSD?? (It is a good idea, since it protects some administrators from themselves) Postscript is a trademark of Adobe Systems... Weaver -- -Weaver Hickerson Voice (404) 496-1358 : ..!edu!gatech!holos0!wdh
greywolf@unisoft.UUCP (The Grey Wolf) (10/18/90)
In article <12@tdatirv.UUCP> sarima@tdatirv.UUCP (Stanley Friesen) writes: # In article <15807@shlump.nac.dec.com> cooper@hpsrad.enet.dec.com (cooper in the shadows) writes: # # >>Do a partial restore of the OS. # # >Unless the procedure has changed in the last 6 years you shouldn't # >have to go this far. You should just be able to reboot the system as # >standalone and you are automagically logged in as root from the # >booting terminal. # # Things *have* changed in the last 6 years. Many (or most) vendors now # deliver a UNIX that requires the root password to enter single-user mode. # Thus, without the root password, you cannot get into the standalone mode. # The partial resore may indeed be the only 'legitimate' way back in. Do most vendors deliver a UNIX which requires a password when booting from portable media (tape, cd, etc...)? I haven't seen one come in here or leave here (we port UNIX). My guess is that all one would need to do is boot the miniroot, which comes up single-user, mount the root disk partition on, say, /mnt, and edit the passwd file whichever way works, be it mv/echo, ed, or whatever. I don't recall any installation procedure being so menu-driven as not to *grant* a single-user shell at some point -- if there are some of those out there, while it is certainly more "secure", it also closes up an avenue through which a desperate system administrator has his last recourse, i.e., if you need to selectively add files on a file-by-file basis (as opposed to a categorical basis), menu-driven is not likely to grant this flexibility. # x # x # x # -- # --------------- # uunet!tdatirv!sarima (Stanley Friesen) -- "This is *not* going to work!" "Well, why didn't you say so before?" "I *did* say so before!" ...!{ucbvax,acad,uunet,amdahl,pyramid}!unisoft!greywolf