cjc@ulysses.att.com (Chris Calabrese) (03/13/91)
brendan@cs.widener.edu (Brendan Kehoe) writes: >In <513@bria>, uunet!bria!mike writes: >>In an article, tndsyd.oz.au!berny (Berny Goodheart) writes: >>>I am interested in finding out known ways to make your version of UNIX >>>crash. >> if ( (fd = open("/dev/kmem",O_RDWR)) == -1 ) > > If your sysadmin (much less the vendor itself) left /dev/kmem world > WRITABLE, they're begging for this kind of thing. Readable, possibly; > writable, c'mon. Allowing any access to /dev/kmem is asking for trouble. It's possible to become root on a system which has a readable /dev/kmem without too much trouble. After that, it's all over. If you want certain programs to access kmem (ps, top, etc), make them sgid to group kmem and make kmem readable to group kmem. Name: Christopher J. Calabrese Brain loaned to: AT&T Bell Laboratories, Murray Hill, NJ att!ulysses!cjc cjc@ulysses.att.com Obligatory Quote: ``pher - gr. vb. to schlep. phospher - to schlep light.philosopher - to schlep thoughts.''
tchrist@convex.COM (Tom Christiansen) (03/14/91)
From the keyboard of cjc@ulysses.att.com (Chris Calabrese): :Allowing any access to /dev/kmem is asking for trouble. :It's possible to become root on a system which :has a readable /dev/kmem without too much trouble. With just read access? How do you do that? I can understand being able to read other people's data, but I really don't know how you would use this to become the superuser. Reading su passwds? This is much harder in raw mode. --tom
rmk@rmkhome.UUCP (Rick Kelly) (03/16/91)
In article <1991Mar13.180300.17697@convex.com> tchrist@convex.COM (Tom Christiansen) writes: >From the keyboard of cjc@ulysses.att.com (Chris Calabrese): >:Allowing any access to /dev/kmem is asking for trouble. >:It's possible to become root on a system which >:has a readable /dev/kmem without too much trouble. > >With just read access? How do you do that? I can understand >being able to read other people's data, but I really don't know >how you would use this to become the superuser. Reading su passwds? >This is much harder in raw mode. Think about it. Look at the UNIX tools you have available. Consider the fact that /dev/kmem is a file. When anyone logs in, even root, login has to decrypt the password in /etc/password to compare it to the password typed it. This password in memory lays around for a while. It is extremely easy to grab passwords out of kmem, and match them to ANY user, including root. Rick Kelly rmk@rmkhome.UUCP frog!rmkhome!rmk rmk@frog.UUCP
richard@aiai.ed.ac.uk (Richard Tobin) (03/18/91)
In article <9103152251.41@rmkhome.UUCP> rmk@rmkhome.UUCP (Rick Kelly) writes: >Think about it. Look at the UNIX tools you have available. Consider the fact >that /dev/kmem is a file. When anyone logs in, even root, login has to decrypt >the password in /etc/password to compare it to the password typed it. This >password in memory lays around for a while. Though the user's password is stored in memory temporarily, it is *not* the case that the encoded password in /etc/password is decrypted. After all, if login could decrypt it, so could you. The password the user types is used as a key to encrypt a fixed string (all zeros) and the result is compared with the data from the password file. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
magnus%thep.lu.se@Urd.lth.se (Magnus Olsson) (03/18/91)
In article <9103152251.41@rmkhome.UUCP> rmk@rmkhome.UUCP (Rick Kelly) writes: >When anyone logs in, even root, login has to decrypt >the password in /etc/password to compare it to the password typed it. This >password in memory lays around for a while. It is extremely easy to grab >passwords out of kmem, and match them to ANY user, including root. Sorry, but this is bogus. login does *not* have to decrypt the password from /etc/passwd - indeed, I don't think there's any way it could do that! (The encryption function is not invertible - several different passwords acan have the same encrypted from). Instead, it encrypts the typed-in password and compares it to the one in /etc/passwd. That doesn't mean, of course, that you can't get passwords from /dev/kmem - login has to keep the entered password somewhere before it encrypts it! Magnus Olsson | \e+ /_ Dept. of Theoretical Physics | \ Z / q University of Lund, Sweden | >----< Internet: magnus@thep.lu.se | / \===== g Bitnet: THEPMO@SELDC52 | /e- \q
jco@crane.cis.ufl.edu (Dumpmaster John) (03/19/91)
In article <9103152251.41@rmkhome.UUCP> rmk@rmkhome.UUCP (Rick Kelly) writes:
When anyone logs in, even root, login has to decrypt
^^^^^^^
Excuse me? Since when does it decrypt the password? Read Password
Security: A case history encryption computing by Robert Morris, and Ken
Thompson.
the password in /etc/password to compare it to the password typed it. This
password in memory lays around for a while. It is extremely easy to grab
passwords out of kmem, and match them to ANY user, including root.
Now what the person typed is in memory so you could grab that and be useful.
later
jco
--
"BSD the strongest Operating System avaible today without a prescription."
John C. Orthoefer Internet: jco@smuggler.cis.ufl.edu
University of Florida Floyd Mailing List: eclipse-request@reef.cis.ufl.edu
CIS Department >>>>>>New Address<<<<<<-------------^^^^cjc@ulysses.att.com (Chris Calabrese) (03/19/91)
rmk@rmkhome.UUCP (Rick Kelly) writes: >tchrist@convex.COM (Tom Christiansen) writes: >>From the keyboard of cjc@ulysses.att.com (Chris Calabrese): >>:Allowing any access to /dev/kmem is asking for trouble. >>:It's possible to become root on a system which >>:has a readable /dev/kmem without too much trouble. >> >>With just read access? How do you do that? I can understand >>being able to read other people's data, but I really don't know >>how you would use this to become the superuser. Reading su passwds? >>This is much harder in raw mode. > >Think about it. Look at the UNIX tools you have available. Consider the fact >that /dev/kmem is a file. When anyone logs in, even root, login has to decrypt >the password in /etc/password to compare it to the password typed it. This >password in memory lays around for a while. It is extremely easy to grab >passwords out of kmem, and match them to ANY user, including root. Actually, modern versions of login (especially System V) take great pains to trash the plain-text copy of passwords ASAP, so they really only hang around for a second at most. However, this is still time enough. Older versions of login (v7, and older BSD varieties) really did keep the password in memory for a good long time (at least through the life of the login program, if not longer (depending on whether the kernel clears memory pages when they're freed or when they're allocated). In any event, there are plenty of other programs which read passwords and don't take such precautions (various screen lock programs, for instance). What it all comes down to is this: kmem is a gaping security hole if mortals have access to it. It's also trivially simple to plug that hole. Don't whine about it, just do it... Name: Christopher J. Calabrese Brain loaned to: AT&T Bell Laboratories, Murray Hill, NJ att!ulysses!cjc cjc@ulysses.att.com Obligatory Quote: ``pher - gr. vb. to schlep. phospher - to schlep light.philosopher - to schlep thoughts.''
tritsche@Informatik.TU-Muenchen.DE (Stefan Tritscher) (03/21/91)
In article <9103152251.41@rmkhome.UUCP> rmk@rmkhome.UUCP (Rick Kelly) writes: |In article <1991Mar13.180300.17697@convex.com> tchrist@convex.COM (Tom Christiansen) writes: |>From the keyboard of cjc@ulysses.att.com (Chris Calabrese): |>:Allowing any access to /dev/kmem is asking for trouble. |>:It's possible to become root on a system which |>:has a readable /dev/kmem without too much trouble. |> |>With just read access? How do you do that? I can understand |>being able to read other people's data, but I really don't know |>how you would use this to become the superuser. Reading su passwds? |>This is much harder in raw mode. | | | | |Think about it. Look at the UNIX tools you have available. Consider the fact |that /dev/kmem is a file. When anyone logs in, even root, login has to decrypt |the password in /etc/password to compare it to the password typed it. This |password in memory lays around for a while. It is extremely easy to grab |passwords out of kmem, and match them to ANY user, including root. | NO - NO - NO Think about it. If login could decrypt a password then evryone could do that too. Passwords cannot be decrypted. Login ENcrypts the password from the user and compares it with the ENcrypted password in the password file. | |Rick Kelly rmk@rmkhome.UUCP frog!rmkhome!rmk rmk@frog.UUCP
rmk@rmkhome.UUCP (Rick Kelly) (03/21/91)
In article <1991Mar18.153201.23325@lth.se> magnus@thep.lu.se (Magnus Olsson) writes: >In article <9103152251.41@rmkhome.UUCP> rmk@rmkhome.UUCP (Rick Kelly) writes: >>When anyone logs in, even root, login has to decrypt >>the password in /etc/password to compare it to the password typed it. This >>password in memory lays around for a while. It is extremely easy to grab >>passwords out of kmem, and match them to ANY user, including root. > >Sorry, but this is bogus. > >login does *not* have to decrypt the password from /etc/passwd - indeed, >I don't think there's any way it could do that! (The encryption function >is not invertible - several different passwords acan have the same >encrypted from). Instead, it encrypts the typed-in password and compares >it to the one in /etc/passwd. > >That doesn't mean, of course, that you can't get passwords from /dev/kmem - >login has to keep the entered password somewhere before it encrypts it! Your right. I typed without thinking. However, I have used standard UNIX commands to find the password that a user typed in at the prompt. It's trivial. Rick Kelly rmk@rmkhome.UUCP frog!rmkhome!rmk rmk@frog.UUCP
jc@minya.UUCP (John Chambers) (03/21/91)
In article <1991Mar18.153201.23325@lth.se>, magnus%thep.lu.se@Urd.lth.se (Magnus Olsson) writes: > In article <9103152251.41@rmkhome.UUCP> rmk@rmkhome.UUCP (Rick Kelly) writes: > >When anyone logs in, even root, login has to decrypt > >the password in /etc/password to compare it to the password typed it. This > >password in memory lays around for a while. It is extremely easy to grab > >passwords out of kmem, and match them to ANY user, including root. > > Sorry, but this is bogus. > > login does *not* have to decrypt the password from /etc/passwd - indeed, > ... > > That doesn't mean, of course, that you can't get passwords from /dev/kmem - > login has to keep the entered password somewhere before it encrypts it! Sorry, but this is bogus. True, login has to keep the password somewhere, but that somewhere isn't in /dev/kmem; it is in login's address space. What is true is that it has to get it from somewhere, and it does that via a read(), meaning that the somewhere it gets it from is inside /dev/kmem. [Picky, picky, picky! ;-] There have been some claims that getting passwords from the kernel is "easy". I'd like to see an example of how easy it is. It strikes me as being not very easy at all. Well, sure, I can read all of kmem into my own address space, and if I do it long enough, then I'll know that at some point in time there has been a passwords somewhere in all those megabytes. But that's not very interesting; to make it useful, you have to be able to point at a set of N bytes, where n <= 8, and say "That is the password for user `foo'." Have you ever tried to read through the kernel's ibufs and try to identify anything there? Remember that the kernel is madly changing them beneath you, and a pointer that you just got has a significant possibility of being invalid by the time you read the thing that it pointed at. The serial-port clists are especially tricky to read out of kmem, because the data structures change so fast. Note that I'm not saying it can't be done; I'm just questioning how easy it is to get anything useful this way. I've been working on some network management tools (e.g., snmp agents) that get their data from kmem, and I'm rather well aware of how much error checking must be done to avoid "finding" total garbage by following pointers that were valid 60 milliseconds ago. Even relatively static lists like the routing tables can move around as you try to read them, leading you off into limbo. If you can do it "easily", you obviously know something I don't; I'd like to learn how to do it the easy way. -- All opinions Copyright (c) 1991 by John Chambers. Inquire for licensing at: Home: 1-617-484-6393 Work: 1-508-486-5475 Uucp: ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc
torek@elf.ee.lbl.gov (Chris Torek) (03/22/91)
In article <601@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >There have been some claims that getting passwords from the kernel is >"easy". I'd like to see an example of how easy it is. It strikes me >as being not very easy at all. It is not `easy' in the sense of being trivial, but it is not all that difficult, either: back in the days of 4.1BSD, at the University of Maryland, we had a student% who wrote a little `kmem reading' program that scanned clists. >The serial-port clists are especially tricky to read out of kmem, >because the data structures change so fast. The forementioned program did exactly that, with a success rate running around 80 to 90 percent. That is, it usually lost 1 or 2 out of every ten characters. >Note that I'm not saying it can't be done; I'm just questioning how >easy it is to get anything useful this way. Said student certainly got a number of useful tidbits... plus a number of wrist-slappings. :-) ----- % No, it was not me. *My* days were in high school. :-) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
ts@cup.portal.com (Tim W Smith) (03/23/91)
A lot depends on how your terminal driver works. For instance, there was one version of Unix (32V, I believe), whose terminal driver used a global buffer for canonicalization. On this system, you would just do something like yes "_canonb/S" | adb /unix /dev/kmem and sit back and wait. Sure, you got a lot of garbage. But every so often, you would see something like: _canonb: root followed by _canonb: foobar where foobar would be a pretty good thing to try for the root password. Sometimes it was wrong, but sometimes it was right, and that's enough. Tim Smith
rmk@rmkhome.UUCP (Rick Kelly) (03/24/91)
In article <4331@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >In article <9103152251.41@rmkhome.UUCP> rmk@rmkhome.UUCP (Rick Kelly) writes: >>Think about it. Look at the UNIX tools you have available. Consider the fact >>that /dev/kmem is a file. When anyone logs in, even root, login has to decrypt >>the password in /etc/password to compare it to the password typed it. This >>password in memory lays around for a while. >Though the user's password is stored in memory temporarily, it is >*not* the case that the encoded password in /etc/password is >decrypted. After all, if login could decrypt it, so could you. The >password the user types is used as a key to encrypt a fixed string >(all zeros) and the result is compared with the data from the password >file. Yes, I have already posted that I was thinking backwards that day. However, when you type in your passwd, it sits around in memory, and stock UNIX tools can be used to equate your login name with your passwd. I have done it on demand for people who wanted to know why kmem should't be world readable. I'm extremely sorry for posting without my mind engaged. I will probably hear about it for the next 2 months. At least Jonathan Kamens hasn't sent me any mail yet. Rick Kelly rmk@rmkhome.UUCP frog!rmkhome!rmk rmk@frog.UUCP
tts@ttank.ttank.com (Karl Bunch) (03/25/91)
In <601@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >In article <1991Mar18.153201.23325@lth.se>, magnus%thep.lu.se@Urd.lth.se (Magnus Olsson) writes: >> In article <9103152251.41@rmkhome.UUCP> rmk@rmkhome.UUCP (Rick Kelly) writes: >> >When anyone logs in, even root, login has to ... >[Picky, picky, picky! ;-] >There have been some claims that getting passwords from the kernel is >"easy". I'd like to see an example of how easy it is. It strikes me >as being not very easy at all. Well, sure, I can read all of kmem into.. Try this.. Login as root: time strings /dev/kmem | grep rootpassword | wc -l You'll be surprised. Mind you you shouldn't have anyone running on the system or have a history file (ksh or csh) that will save the root password into a file. If anyone is on during the test a ps might show them what grep is looking for.... :-( Safer would be: strings /dev/kmem | tr ' ' '^J' | sort -u | more and do a /rootpassword On our local system with 10Mb of memory it took 3 seconds and returned 5 matches! Some of them where were we had used 'cu' to call another host and use the password and the last say 256 characters were all together: Welcome to somewhere.... login: ... root rootpassword.. Etc! And: strings /dev/kmem | tr ' ' '^J' | sort -u | wc -l Only returned 2000 or so words! Not bad! You know "SOMEBODY'S" password is in there.. Just run a guessing program.. At even just 5 guesses per second I would have the account in 7 mins! Just wait for root to login and then run the above.. Save the list of "words" (And this could be cut better than with just tr) and do a guess at root later when he logges out... No problem.. PLEASE PLASE leave your /dev/kmem world readable.. Hey why not world writable! yes > /dev/kmem Enough sarcasm.. Let's just say it's dangerous in sooo many ways we can't count them with our current computing ability. :-) Karl -- % ---------------------------------------------------------------------------- % Karl Bunch ||| UUCP: ..!uunet!zardoz!ttank!karl % Think Tank Software ||| INTERNET: karl@ttank.com % "...you'd be suprised how far a hug will go with Geordi, even Worf!" -- Riker
magnus%thep.lu.se@Urd.lth.se (Magnus Olsson) (03/26/91)
In article <601@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >In article <1991Mar18.153201.23325@lth.se>, magnus%thep.lu.se@Urd.lth.se (Magnus Olsson) writes: >> That doesn't mean, of course, that you can't get passwords from /dev/kmem - >> login has to keep the entered password somewhere before it encrypts it! > >Sorry, but this is bogus. > >True, login has to keep the password somewhere, but that somewhere isn't >in /dev/kmem; it is in login's address space. > >What is true is that it has to get it from somewhere, and it does that via >a read(), meaning that the somewhere it gets it from is inside /dev/kmem. > >[Picky, picky, picky! ;-] To be *really* picky, I didn't say that login *did* keep passwords in /dev/kmem, but only that it wasn't necessarily true that it didn't. :-) Seriously, I thought the entire virtual memory of the machine was accessible through /dev/kmem. Why isn't login's address space? Magnus Olsson | \e+ /_ Dept. of Theoretical Physics | \ Z / q University of Lund, Sweden | >----< Internet: magnus@thep.lu.se | / \===== g Bitnet: THEPMO@SELDC52 | /e- \q
torek@elf.ee.lbl.gov (Chris Torek) (03/27/91)
In article <1991Mar26.113637.24279@lth.se> magnus@thep.lu.se (Magnus Olsson) writes: >Seriously, I thought the entire virtual memory of the machine was >accessible through /dev/kmem. Why isn't login's address space? (NB: the following are generalisations that may not apply to your particular Unix system.) /dev/kmem gives access to kernel virtual address space. If login's address space happens to be mapped in to kernel virtual space at the time, it could be found there. If not, it could not. /dev/mem gives access to physical memory. In conjunction with /dev/kmem, this can be used to locate any in-core pages of any process. (First one reads the mapping structures from the kernel, in order to locate the page locators, then one reads the locators, then the pages. The total number of indirections involved is machine- and implementation-dependent.) The /proc file system, where it exists, gives access to the virtual address spaces of individual processes. This is an interesting place to find covert channels (want to read kernel memory? run a setgid- kmem program and open its /proc file, if the system permits). -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
jc@minya.UUCP (John Chambers) (04/03/91)
In article <1991Mar24.203327.18426@ttank.ttank.com>, tts@ttank.ttank.com (Karl Bunch) writes: > In <601@minya.UUCP> jc@minya.UUCP (John Chambers) writes: > >There have been some claims that getting passwords from the kernel is > >"easy". I'd like to see an example of how easy it is. It strikes me > >as being not very easy at all. Well, sure, I can read all of kmem into.. > > Try this.. Login as root: > > time strings /dev/kmem | grep rootpassword | wc -l > > You'll be surprised. I tried it; I wasn't at all surprised. It gave me no output at all. What was it supposed to do? This is a Sys/V.3 system. I tried it on some BSD and Ultrix and Sun systems at work, and got nothing from any of them, either. I also tried just the "strings /dev/kmem"; it gave me a few strings, but nothing that was even vaguely recognizable as a password. I didn't see the root password anywhere, although I'd just done a "su - root". I also decided to try "strings /dev/mem". This time I was surprised. The system hung, and had to be rebooted. Such a pity, too; this system was heading for some sort of record, since the last boot was some time late in November. Who ever heard of a Unix system (especially one owned by a notorious Unix hacker ;-) surviving so long? Anyone know why feeding /dev/mem to strings should crash a system? This seems rather demented to me. But it does get us back to the original topic. > Safer would be: > strings /dev/kmem | tr ' ' '^J' | sort -u | more > and do a /rootpassword OK; that didn't crash the system; I just got a few random-looking strings, followed by:: /rootpassword: Command not found. What was it supposed to do? Maybe I'm not a real Unix hacker, after all; I haven't even heard of a "rootpassword" command. Am I missing something good? I also looked around on some of the BSD and Ultrix systems at work, and there was nothing called "rootpassword" anywhere in any of their filesystems. It seems I'm missing something somewhere. Nothing here has turned up even a single password, root or otherwise. And it was supposed to be so easy... -- All opinions Copyright (c) 1991 by John Chambers. Inquire for licensing at: Home: 1-617-484-6393 Work: 1-508-486-5475 Uucp: ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc
cgd@ocf.Berkeley.EDU (Chris G. Demetriou) (04/03/91)
In article <638@minya.UUCP> jc@minya.UUCP (John Chambers) writes: In article <1991Mar24.203327.18426@ttank.ttank.com>, tts@ttank.ttank.com (Karl Bunch) writes: > Safer would be: > strings /dev/kmem | tr ' ' '^J' | sort -u | more > and do a /rootpassword OK; that didn't crash the system; I just got a few random-looking strings, followed by:: /rootpassword: Command not found. What was it supposed to do? Maybe I'm not a real Unix hacker, after all; I haven't even heard of a "rootpassword" command. Am I missing something good? I also looked around on some of the BSD and Ultrix systems at work, and there was nothing called "rootpassword" anywhere in any of their filesystems. Umm, it would seem that the original author assumed that strings |...|more would get more than a page of strings piped into more.... if this was the case, /rootpassword (where rootpassword is the root pw) would search for the password in the text, and find the first occurrence of it in the rest of the text. this has several problems: first, if the text is longer than a page, you never get to the "--MORE--" line (or whatever more says to you at the end of a page). second, if the root pw is on the first page, searching for it won't find it unless it occurs again later; /blah searches for "blah" in the portion of the file not yet displayed. Chris Demetriou cgd@ocf.berkeley.edu
dmturne@PacBell.COM (Dave Turner) (04/05/91)
In article <638@minya.UUCP> jc@minya.UUCP (John Chambers) writes: .In article <1991Mar24.203327.18426@ttank.ttank.com>, tts@ttank.ttank.com (Karl Bunch) writes: .> In <601@minya.UUCP> jc@minya.UUCP (John Chambers) writes: .> >There have been some claims that getting passwords from the kernel is .> >"easy". I'd like to see an example of how easy it is. It strikes me .> >as being not very easy at all. Well, sure, I can read all of kmem into.. .> .> Try this.. Login as root: .> .> time strings /dev/kmem | grep rootpassword | wc -l .> .> You'll be surprised. . .I tried it; I wasn't at all surprised. It gave me no output at all. .What was it supposed to do? This is a Sys/V.3 system. I tried it I'd be surprised if a least one user didn't learn your rootpassword by typing a ps (ps -ef on system v) while you were running this command. The security exposure of running a grep with root's clear password is much greater than someone getting it from /dev/kmem. -- Dave Turner 415/823-2001 {att,bellcore,sun,ames,decwrl}!pacbell!dmturne
boyd@nu.cs.fsu.edu (Mickey Boyd) (04/09/91)
In article <638@minya.UUCP>, jc@minya.UUCP (John Chambers) writes: > >> Safer would be: >> strings /dev/kmem | tr ' ' '^J' | sort -u | more >> and do a /rootpassword > >OK; that didn't crash the system; I just got a few random-looking strings, >followed by:: > /rootpassword: Command not found. >What was it supposed to do? Maybe I'm not a real Unix hacker, after >all; I haven't even heard of a "rootpassword" command. Am I missing >something good? I also looked around on some of the BSD and Ultrix >systems at work, and there was nothing called "rootpassword" anywhere >in any of their filesystems. > This was to invoke a search for the string "rootpassword" in more. It is not a standalone command, it is a modifier within more. It could be argued that it is one of the more useful features of more. My question is why the string "rootpassword" would be anywhere (perhaps the poster intended for the real root password to be substituted, just to show how easy it can be found. A potential intruder would have to try all the strings found, but this is still a drastically reduced searchspace). -- ---------------------------------+------------------------------------- Mickey R. Boyd | "Kirk to Enterprise. All clear FSU Computer Science | down here. Beam down Technical Support Group | yeoman Rand and a six-pack . ." email: boyd@fsucs.cs.fsu.edu | ---------------------------------+-------------------------------------
rmk@rmkhome.UUCP (Rick Kelly) (04/12/91)
In article <1991Apr8.213109.1949@mailer.cc.fsu.edu> boyd@nu.cs.fsu.edu writes: >In article <638@minya.UUCP>, jc@minya.UUCP (John Chambers) writes: >>> Safer would be: >>> strings /dev/kmem | tr ' ' '^J' | sort -u | more >>> and do a /rootpassword >>OK; that didn't crash the system; I just got a few random-looking strings, >>followed by:: >> /rootpassword: Command not found. >>What was it supposed to do? Maybe I'm not a real Unix hacker, after >>all; I haven't even heard of a "rootpassword" command. Am I missing >>something good? I also looked around on some of the BSD and Ultrix >>systems at work, and there was nothing called "rootpassword" anywhere >>in any of their filesystems. >This was to invoke a search for the string "rootpassword" in more. It is >not a standalone command, it is a modifier within more. It could be argued >that it is one of the more useful features of more. My question is why >the string "rootpassword" would be anywhere (perhaps the poster intended >for the real root password to be substituted, just to show how easy it >can be found. A potential intruder would have to try all the strings >found, but this is still a drastically reduced searchspace). One avenue is to search for "root" or any other login in memory in such a way that you know it's offset in /dev/kmem. Do an ASCII dump of kmem at that offset, and you will soon find the password. I have done this, but for obvious reasons I leave this as an exercise for the reader. Rick Kelly rmk@rmkhome.UUCP frog!rmkhome!rmk rmk@frog.UUCP
craig@attcan.UUCP (Craig Campbell) (04/15/91)
In article <6093@ptsfa.PacBell.COM> dmturne@PacBell.COM (Dave Turner) writes: >In article <638@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >I'd be surprised if a least one user didn't learn your rootpassword >by typing a ps (ps -ef on system v) while you were running this command. > >The security exposure of running a grep with root's clear password is >much greater than someone getting it from /dev/kmem. >Dave Turner 415/823-2001 {att,bellcore,sun,ames,decwrl}!pacbell!dmturne Huh??!! Whose SysV Rel 3 are you running? P.S. -ef will only display the command line. The password is prompted for by the su program. I am speaking with intimate knowledge of AT&T SysV Release 3.1.1 -> SysV Rel 4.0.2.1. Who is this rootpasswd person anyway? Some dangerously stupid add on shell script?? The functionality of ps has been well known and documented for a longgggg time. Unix, being Unix, will of course, cheerfully help you pull the trigger, if you insist on shooting yourself in the foot.... craig
craig@attcan.UUCP (Craig Campbell) (04/15/91)
In article <14090@vpk2.UUCP> craig@vpk2.ATT.COM (Craig Campbell) writes: >In article <6093@ptsfa.PacBell.COM> dmturne@PacBell.COM (Dave Turner) writes: >Huh??!! Whose SysV Rel 3 are you running? P.S. -ef will only display the ^^^^^^^^^ Gads!!! That should, of course read as "ps -ef"..... Sorry.... (Quick, get me MORE COFFEE!!!! Monday is closing in!!!! :-)) >command line. The password is prompted for by the su program. I am speaking >with intimate knowledge of AT&T SysV Release 3.1.1 -> SysV Rel 4.0.2.1. er, ummm, ahhh craig, yeah, that's it, craig
dmturne@PacBell.COM (Dave Turner) (04/18/91)
In article <14090@vpk2.UUCP> craig@vpk2.ATT.COM (Craig Campbell) writes: >In article <6093@ptsfa.PacBell.COM> dmturne@PacBell.COM (Dave Turner) writes: >>I'd be surprised if a least one user didn't learn your rootpassword >>by typing a ps (ps -ef on system v) while you were running this command. >> >>The security exposure of running a grep with root's clear password is >>much greater than someone getting it from /dev/kmem. > >Huh??!! Whose SysV Rel 3 are you running? P.S. -ef will only display the >command line. The password is prompted for by the su program. I am speaking >with intimate knowledge of AT&T SysV Release 3.1.1 -> SysV Rel 4.0.2.1. > >Who is this rootpasswd person anyway? Some dangerously stupid add on shell >script?? The functionality of ps has been well known and documented for a >longgggg time. Unix, being Unix, will of course, cheerfully help you pull >the trigger, if you insist on shooting yourself in the foot.... > It's been several weeks since this discussion started but it went something like this: If /dev/kmem is readable by everyone then anyone could look through it to try to find the current rootpassword. It was suggested that someone knowing the rootpassword who also has read permission on /dev/kmem could use a grep to determine if the rootpassword (in clear) was somewhere therein. The suggested command was: grep rootpassword /dev/kmem Depending upon the speed of the cpu, the size of memory and the system load this may take several minutes. During this time any user who typed ps -ef would see the grep command line which will clearly display the rootpassword in the clear. My post was to point out that anyone who grepped /dev/kmem as above would (un)knowingly announce the rootpassword to any users who were lucky enough to type a ps -ef during the time the password grep were running. This has nothing to do with SysV Rel 3; it has been this way since Edition 6 at least. (The ps command options may be different but the result will be the same.) -- Dave Turner 415/823-2001 {att,bellcore,sun,ames,decwrl}!pacbell!dmturne