Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!rochester!uhura.cc.rochester.edu!ub!dsinc!widener!ukma!memstvx1!utkcs2!emory!swrinde!ucsd!ucrmath!nuchat.sccsi.com
From: kevin@nuchat.sccsi.com (Kevin Brown)
Newsgroups: comp.os.minix
Subject: Re: Curses
Message-ID: <15235@ucrmath.ucr.edu>
Date: 13 Jun 91 12:51:15 GMT
References: <}0K*`?+@cck.cov.ac.uk> <33563@usc.edu>
Sender: news@ucrmath.ucr.edu
Reply-To: kevin@nuchat.sccsi.com (Kevin Brown)
Organization: Teenage Mutant Ninja NiceGuys [tm] :-)
Lines: 55

In article <33563@usc.edu> kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes:
>In article <}0K*`?+@cck.cov.ac.uk> csg020@uk.ac.cov.cck (***CURTIS***) writes:
>>Also, has anyone noticed that if you strings /dev/kmem it shows up everyones
>>decrypted password who has logged on since the bring up of the system?!

I just tried this and found nothing.  However, you might find something if you
do a "strings /dev/mem"...

If you remove world read permissions from /dev/kmem, you'll have to setuid
or setgid ps (and probably mu).

I'm running Minix-386, so this may be one of the reasons I don't see 
anything.  Has anyone else confirmed the above problem?

>This is bad.  Not only because ordinary users may be able to find out
>the root password (if the superuser isn't so smart), but also because
>the superuser is able to find out other users passwords (if he is).

I must say, I'm a bit perplexed about how this happens to begin with.  I
was under the impression that /dev/kmem was supposed to show kernel memory
ONLY.  What are user passwords, decrypted or otherwise, doing in kernel
memory at all??  The only place I can think of where they might show up is
in the tty buffer, and that gets overwritten with use, so I don't see where
or how it stores *all* passwords since boot time.

>This is a most serious security hole.  It also means that on PC's that
>aren't running in protected mode, and maybe Macs, have no security at
>all.

This is already the case, for those systems that have write access (and,
perhaps, read access) to /dev/mem and /dev/kmem.

>Perhaps an easy solution is to have the login program, and the su
>program, go and scribble over each copy of entered passwords after they
>are used.  Both login and su should be able to do this since they are
>both suid.  Any comments on this idea?  Should it go into 1.6.* right
>away?

The version of login.c I'm using is the original one that came with 1.5.10
(from PH), and I don't see anything in /dev/kmem, so I don't know if that
will work or not because I don't know where the passwords are being stored
or why.


>favourite oxymorons:   student athlete, military justice, mercy killing
>Ken Hendrickson N8DGN/6       kjh@usc.edu      ...!uunet!usc!pollux!kjh



--
Kevin Brown						    Disclaimer: huh?
kevin@nuchat.sccsi.com				kevin@taronga.hackercorp.com
...!uunet!nuchat!kevin			      ...!uunet!nuchat!taronga!kevin

Minix -- the Unix[tm] of the 90's.  System V -- the Multics of the 90's.  :-)