Bugtraq mailing list archives

Re: /dev/{km,m}em worries


From: pwh () bradley bradley edu (Pete Hartman)
Date: Tue, 17 May 94 15:11:44 -0500


What exactly are the problems with having /dev/mem and /dev/kmem readable
by other? Is there any way in which our systems can be exploited by 
this?

A student pointed out to me quite graphically just this past semester
that you can do "strings /dev/kmem | less" and look for the memory images
of UNENCRYPTED passwords.  Look for strings nearby known user logins.

He was able to determine both my password and my root password on the 
machine he did the demonstration on.

Also, be aware that /etc/crash is setgid kmem and allows you to fork
a shell and DOES NOT reset the group id for that shell.  So even if
your /dev/kmem is set properly to mode 640, if users can run /etc/crash,
they can still do this.

My solution was simply chmod 700 /etc/crash on all my systems.   Root
is the only one that needs it anyway....

For the record, isis is a sun4m (two processors) and janus is a sun4c,
both running SunOS 4.1.3. Is there anything I can be watchful of, to make
sure that we haven't been compromised? Can anyone provide me with
information on how to exploit a mismatched perm on mem/kmem (if any)?

I don't know about watchful of--people could have collected passwords
this way and done very little....



Current thread: