ALERT ALERT plaintext passwords in linux ALERT ALERT

[lcamtuf () ghettot org (Michal Zalewski)]

On Sun, 15 Sep 2002 silvio () big net au wrote:

> a nice method to find "hidden" processes is to recognize that a process
> is a process id can be considered an exclusive resource that is
> available on request by anyone on the system.
>
> so the idea is to cycle through all the pid's, and see which ones you
> can't obtain.  if at the same time you can view such a process in the
> regular listings.. something is interesting.  in any case, it would
> appear that the task slot cannot be allocated for "some" reason(s).

Yes and no. A fair number of PIDs is not available to mere mortals. On a
typical Linux, 0-300 and 32768-65535 are protected one way or another, yet
it's perfectly possible for a hiding process to claim one of those...
plus, "exclusive" use is not really guaranteed, two processes can share a
single PID (older Linuxes, 2.0, even allowed you to do that from
user-space with clone(), now it requires some hacking).

> note that on linux recycling the pid's goes back to 300..  a sysctl
> would be nice here to set this figure.

This mechanism is fairly bogus. I imagine it is supposed to speed things
up and perhaps keep things in order - lower pids are supposed to be
occupied by daemons after boot-up. In reality, however, a typical start-up
sequence for recent Red Hat distros - and, I imagine, most other Linuxes -
is so blown up that first daemons will be started with PIDs closer to
400-500. The mechanism, as such, is quite pointless, just wasting 300
PIDs.

-- 
_____________________________________________________
Michal Zalewski [lcamtuf () bos bindview com] [security]
[http://lcamtuf.coredump.cx] <=-=> bash$ :(){ :|:&};:
=-=> Did you know that clones never use mirrors? <=-=
          http://lcamtuf.coredump.cx/photo/