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:
- /dev/{km,m}em worries rickt () gnu ai mit edu (May 17)
- Re: /dev/{km,m}em worries Rob Quinn (May 17)
- <Possible follow-ups>
- Re: /dev/{km,m}em worries H Morrow Long (May 17)
- Re: /dev/{km,m}em worries Bruce Barnett (May 17)
- Re: /dev/{km,m}em worries der Mouse (May 17)
- Re: /dev/{km,m}em worries Jim Thompson (May 17)
- Re: /dev/{km,m}em worries (now crash ) Chris Phillips (May 18)
- Re: /dev/{km,m}em worries Pete Hartman (May 17)
- Re: /dev/{km,m}em worries Bill Bogstad (May 17)
- Re: /dev/{km,m}em worries Jim Thompson (May 17)
- Re: /dev/{km,m}em worries der Mouse (May 17)