Kmem security (was: Re: How do you make your UNIX crash ???)

[Dave Turner]

In article <14090 at vpk2.UUCP> craig at vpk2.ATT.COM (Craig Campbell) writes:
>In article <6093 at ptsfa.PacBell.COM> dmturne at 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