u27602@uy.ncsa.uiuc.edu (Jeffrey C. Ollie) (03/19/91)
<AJN106@PSUVM.PSU.EDU> writes: >HOW CAN I BREAK SECURITY IN MINIX 1.5? IT IS FOR A PROJECT I AM DOING AS AN >INDEPENDENT STUDY. I NEED A WAY TO ACCESS SUPER-USER (ROOT USER) PRIVILEGES >SO A NORMAL USER CAN USE IT. SEND E-MAIL RESPONSES TO AJN106 PSUVM. THANKS. The book _Unix System Anministration_ by Evi Nemeth contains a short program called SUDO (SuperUser DO) that allows normal users to perform operations that normally only the root would be able to do. Basically, it is a program that runs setuid root. SUDO checks a file set up by the super-user to see if the su has given the user that runs SUDO permission to run SUDO, and if the su has given that user permission to execute the command given to su. The program was written for BSD Unix, but there are no BSD-dependent calls (as far as I know) so a port should be a type-in-and- run job. ;-) Jeff Ollie I-Net: u27602@uy.ncsa.uiuc.edu
dfs@doe.carleton.ca (David F. Skoll) (03/19/91)
In <47976@nigel.ee.udel.edu> u27602@uy.ncsa.uiuc.edu (Jeffrey C. Ollie) writes: >The book _Unix System Anministration_ by Evi Nemeth contains a short >program called SUDO (SuperUser DO) that allows normal users to perform >operations that normally only the root would be able to do. Basically, >it is a program that runs setuid root. But don't you have to have root privileges to create a setuid-root file in the first place? In principle, MINIX security should be easy to break. I've only had my system for a couple of days, and have just glanced at the code, but it seems that since the hardware (my PC-XT) does not have memory protection, it should be possible to write an assembler program which hunts around for the kernel's process table, figures out what's where, and manually changes its uid to 0. Practically, this might be quite messy. -- David F. Skoll Disclaimer: Don't try this at home, kids!
ECO861771@ecostat.aau.dk (03/19/91)
Just one very simple way to do it would be to take a disk editor, find the passwd file, and then change the password of root to nothing. This is very easy as long as the minix file system is not read/write protected on the host on which it resides. (Or encrypted). I guess this even works on big real life UNIX machines. Just take your Macintosh to the lab, disconnect the SCSI drive with the root file system and connect it to your mac. Then use a disc editor to make changes. Povl H. Pedersen eco861771@ecostat.aau.dk
mjh@cs.vu.nl (Maarten J Huisjes) (03/19/91)
ECO861771@ecostat.aau.dk writes: } Just one very simple way to do it would be to take a disk editor, find the } passwd file, and then change the password of root to nothing. This is very } easy as long as the minix file system is not read/write protected on the } host on which it resides. (Or encrypted). } I guess this even works on big real life UNIX machines. Just take your } Macintosh to the lab, disconnect the SCSI drive with the root file system } and connect it to your mac. Then use a disc editor to make changes. Yep, sure works. We just did exactly that. Connect the disk to an other Unix system and read /dev/<disk> with a binary editor. Search for "root:" -- Maarten Huisjes. mjh@cs.vu.nl (192.31.231.42) (..!uunet.uu.net!cs.vu.nl!mjh)
hp@vmars.tuwien.ac.at (Peter Holzer) (03/22/91)
ECO861771@ecostat.aau.dk writes: >Just one very simple way to do it would be to take a disk editor, find the >passwd file, and then change the password of root to nothing. This is very >easy as long as the minix file system is not read/write protected on the >host on which it resides. (Or encrypted). Hmm. All the /dev/hd* entries are mode 0600 at my system. Oh, you mean I should boot with DOS and then use Disk Repair or Norton Utilities. Now that is really a problem. But you could disable booting from disk by changing the BIOS (a friend of mine did this. Of course he kept the original BIOS for emergencies :-) On Minix, however the easiest way to become root (if you don't have the original root disk with the `secret' password) is to decrypt the passwords (Yes that can be done and a program that does this has been posted some time ago). >I guess this even works on big real life UNIX machines. Just take your >Macintosh to the lab, disconnect the SCSI drive with the root file system >and connect it to your mac. Then use a disc editor to make changes. Ok, lets try it. I go to the lab, switch off the computer, take a screwdriver to open it, three people come in: ``Why can't we read news anymore? --- WHAT ARE YOU DOING WITH THAT COMPUTER???''. I'll try it on a weekend next time :-) But if you can switch off the computer for a few minutes without being noticed there is a much easier way to get root privileges: Some (many ?) workstations allow you to choose between single- and multi-user mode soon after rebooting without asking for a password! If you enter single-user mode you have root privileges and can install all trojan horses you want. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Dept. for Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand |
waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) (03/22/91)
In article <47976@nigel.ee.udel.edu>, u27602@uy.ncsa.uiuc.edu (Jeffrey C. Ollie) wrote: > <AJN106@PSUVM.PSU.EDU> writes: > >>HOW CAN I BREAK SECURITY IN MINIX 1.5? IT IS FOR A PROJECT I AM DOING AS AN >>INDEPENDENT STUDY. I NEED A WAY TO ACCESS SUPER-USER (ROOT USER) PRIVILEGES >>SO A NORMAL USER CAN USE IT. SEND E-MAIL RESPONSES TO AJN106 PSUVM. THANKS. > > The book _Unix System Anministration_ by Evi Nemeth contains a short > program called SUDO (SuperUser DO) that allows normal users to perform > operations that normally only the root would be able to do. Basically, > it is a program that runs setuid root. SUDO checks a file set up by > the super-user to see if the su has given the user that runs SUDO permission > to run SUDO, and if the su has given that user permission to execute the > command given to su. The program was written for BSD Unix, but there are > no BSD-dependent calls (as far as I know) so a port should be a type-in-and- > run job. ;-) > > Jeff Ollie > I-Net: u27602@uy.ncsa.uiuc.edu > Every now and then, I ask system security people to have a go at my machines. Minixug is hard to crack, but even it gets cracked there's nothing to get from it. The other machine of importance here (uwalt) has lots of sources on it, and is thus a more interesting goal. Still, they were only able to get 3 bugs out of MINIX. That is very good, since MINIX is getting better and better this way :-) In Short: cracking a properly set up MINIX system _can_ be hard... Fred. -- MicroWalt Corporation, for MINIX Development waltje@uwalt.nl.mugnet.org Tel (+31) 252 230 205, Hoefbladhof 27, 2215 DV VOORHOUT, The Netherlands
waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) (03/22/91)
mjh@cs.vu.nl (Maarten J Huisjes) wrote: > ECO861771@ecostat.aau.dk writes: > > > } Just one very simple way to do it would be to take a disk editor, find the > } passwd file, and then change the password of root to nothing. This is very > } easy as long as the minix file system is not read/write protected on the > } host on which it resides. (Or encrypted). > > } I guess this even works on big real life UNIX machines. Just take your > } Macintosh to the lab, disconnect the SCSI drive with the root file system > } and connect it to your mac. Then use a disc editor to make changes. > > Yep, sure works. We just did exactly that. Connect the disk to an other > Unix system and read /dev/<disk> with a binary editor. Search for "root:" Bull. (not the brand- the curse!) Any system administrator who allows his users to access raw disks has to be shot. Also, programs like 'de(8)' SHOULD NOT be suidRoot !!!!! In most cases, system security is a matter of a system administrator's knowledge and mentality. Contest: I offer a full crate of fresh beer for anyone who cracks the "minixug" system. +31 252 218 363, daytime MET. Fred :-) :-) :-) -- MicroWalt Corporation, for MINIX Development waltje@uwalt.nl.mugnet.org Tel (+31) 252 230 205, Hoefbladhof 27, 2215 DV VOORHOUT, The Netherlands
regn@geyer.UUCP (Robert Regn) (03/22/91)
In <48053@nigel.ee.udel.edu> ECO861771@ecostat.aau.dk writes: > Just one very simple way to do it would be to take a disk editor, find the > passwd file, and then change the password of root to nothing. This is very > easy as long as the minix file system is not read/write protected on the > host on which it resides. (Or encrypted). > I guess this even works on big real life UNIX machines. Just take your > Macintosh to the lab, disconnect the SCSI drive with the root file system > and connect it to your mac. Then use a disc editor to make changes. The minix filesystem _is_ read/write protected on the minix PC. Only root can use the disk editor (e.g. de). But the easiest way is to have a root image on floppy with a known root password and rebooting the pc using this floppy -- Robert Regn University of Wuerzburg, Germany regn@informatik.uni-wuerzburg.dbp.de -- Robert Regn University of Wuerzburg, Germany regn@informatik.uni-wuerzburg.dbp.de
dfs@doe.carleton.ca (David F. Skoll) (03/23/91)
In <9103212014@uwalt.nl.mugnet.org> waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) writes: >In Short: cracking a properly set up MINIX system _can_ be hard... ... if it's running on a machine with hardware memory protection. Cracking a Minix on an 8088 or any other processor which allows anyone to access any memory address is easy. Does Minix for the '386 or the 680?0 support hardware memory protection? (I assume so.) -- David F. Skoll
ECO861771@ecostat.aau.dk (No brain in the moment) (03/23/91)
is the minixug on the net ? I want free beer. Povl H. Pedersen eco861771@ecostat.aau.dk
davep@gapos.bt.co.uk (Dave Parkinson) (03/25/91)
Security has many aspects to it. As has been mentioned here virtually all systems from Crays to pocket calculators are vulnerable where the attacker has direct physical access to the hardware. (Simply switching the power off or wielding a sledgehammer can cause denial of service!). Systems can be re-booted with alternate operating systems, or in a different mode. 'Maintenance' utilities, tools etc can be run. I would assume that the base hardware is adequately safeguarded, and the route for attack is via a user terminal or dial in modem line. Thus the questions that need answering are: 1) Can an un-authorised person log onto the system? 2) Can a user - once logged on to the system - perform actions beyond those he authorised to do? In an open *ix type system the latter depends in the first instance in how well the system is set up (what permissions are set on what files etc). - eg It should not be possible for the average user to change the password file with a text editor, or even to run 'de'. The next question is are there any underlying flaws in the operating system design that let an attacker circumvent the controls that are in place? The fact that the Minix password algorithm is apparently reversable is such a flaw (and easily correctable). Comments like 'read the hard disk on another machine', whilst accurate don't really answer the question.
waltje@minixug.mugnet.org (Fred 'The Rebel' van Kempen) (03/30/91)
bergonz@keeper.sublink.ORG (Michele Bergonzoni) wrote: > > > it should be possible to write an assembler program which hunts around > > for the kernel's process table, figures out what's where, and manually > > changes its uid to 0. Practically, this might be quite messy. > > Really not! I've seen such a program working on commercial, AT&T-licensed > versions of UNIX !!! > Ciao Close to impossible on any machine that supports protected mode. On a simple 286, it is IMPOSSIBLE to junk around in segments not belonging to the current process...: Memory fault- core dumped ! :-) ^100 Fred.
cla@dobag.in-berlin.de (Christian Lampl) (04/01/91)
waltje@minixug.mugnet.org (Fred 'The Rebel' van Kempen) writes: >bergonz@keeper.sublink.ORG (Michele Bergonzoni) wrote: >> >> > it should be possible to write an assembler program which hunts around >> > for the kernel's process table, figures out what's where, and manually >> > changes its uid to 0. Practically, this might be quite messy. >> >> Really not! I've seen such a program working on commercial, AT&T-licensed >> versions of UNIX !!! >> Ciao >Close to impossible on any machine that supports protected mode. On a simple >286, it is IMPOSSIBLE to junk around in segments not belonging to the current >process...: Memory fault- core dumped ! :-) ^100 >Fred. Yes, but even in some Unix Systems on the 386 it's junk around in segments not belonging to the current process ! For example Interactives System V R 3.. on a 386 without mathematical co-processor ! A bug like this was posted in alt.hackers some weeks ago ! Bye Christian !! -- cla@dobag.in-berlin.de | An optimist believes we live in the best world | Christian Lampl | possible; a pessimist fears this is true !! | Berlin, Germany | |
waltje@minixug.mugnet.org (Fred 'The Rebel' van Kempen) (04/06/91)
cla@dobag.in-berlin.de (Christian Lampl) wrote: >>Close to impossible on any machine that supports protected mode. On a simple >>286, it is IMPOSSIBLE to junk around in segments not belonging to the current >>process...: Memory fault- core dumped ! :-) ^100 > >>Fred. > > Yes, but even in some Unix Systems on the 386 it's junk around in segments > not belonging to the current process ! For example Interactives System V R 3.. > on a 386 without mathematical co-processor ! A bug like this was posted in > alt.hackers some weeks ago ! Interactive's IX/386 has more than one security hole. Shall we continue the IX/386 discussion on sub.os.unix, Chris? I get that too, and it would free these poor MINIX souls from talk about bad design... :-) Fred. PS: What happened to Mischi ?
cla@dobag.in-berlin.de (Christian Lampl) (04/08/91)
waltje@minixug.mugnet.org (Fred 'The Rebel' van Kempen) writes: >cla@dobag.in-berlin.de (Christian Lampl) wrote: >>>Close to impossible on any machine that supports protected mode. On a simple >>>286, it is IMPOSSIBLE to junk around in segments not belonging to the current >>>process...: Memory fault- core dumped ! :-) ^100 >> >>>Fred. >> >> Yes, but even in some Unix Systems on the 386 it's junk around in segments >> not belonging to the current process ! For example Interactives System V R 3.. >> on a 386 without mathematical co-processor ! A bug like this was posted in >> alt.hackers some weeks ago ! >Interactive's IX/386 has more than one security hole. Shall we continue the >IX/386 discussion on sub.os.unix, Chris? I get that too, and it would free >these poor MINIX souls from talk about bad design... :-) >Fred. That would be a good idea, but i think i don't know enough about ix/386 security holes ! Allthough thank you for the invitation, I'll now frequently read sub.os.unix ! See ya Christian !!! >PS: What happened to Mischi ? I don't know what happend to him, but his account at dobag.in-berlin.de was killed ! Bye !!! -- cla@dobag.in-berlin.de | An optimist believes we live in the best world | Christian Lampl | possible; a pessimist fears this is true !! | Berlin, Germany |------- George Orwell was an optimist !! -------|
wes@harem.clydeunix.com (Wes Peters) (04/08/91)
In article <dfs.669317926@scotty>, dfs@doe.carleton.ca (David F. Skoll) writes: > In principle, MINIX security should be easy to break. I've only had > my system for a couple of days, and have just glanced at the code, but > it seems that since the hardware (my PC-XT) does not have memory protection, > it should be possible to write an assembler program which hunts around for > the kernel's process table, figures out what's where, and manually changes > its uid to 0. Practically, this might be quite messy. Isn't the process uid in the uarea? This should be pretty easy to find; just look at the code that implements fork(2). Of course, on the 808[68] the uarea might not be in your default data segment, but not everything can be easy, right? Wes Peters -- #include <std/disclaimer.h> | The worst day sailing My opinions, your screen. | is much better than Raxco had nothing to do with this! | the best day at work. Wes Peters: wes@harem.clydeunix.com uunet!viusys!uxui!unislc!harem!wes