Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!rice!uw-beaver!mit-eddie!minya!jc From: jc@minya.UUCP (John Chambers) Newsgroups: comp.unix.admin Subject: Re: Kmem security (was: Re: How do you make your UNIX crash ???) Message-ID: <601@minya.UUCP> Date: 21 Mar 91 12:45:02 GMT References: <513@bria> <1991Mar12.132003.27383@cs.widener.edu> <1991Mar18.153201.23325@lth.se> Lines: 55 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