[Full-Disclosure] ALERT ALERT plaintext passwords in linux ALERT ALERT

From: Michal Zalewski (lcamtuf@ghettot.org)
Date: 09/16/02

From: lcamtuf@ghettot.org (Michal Zalewski)
Date: Sun, 15 Sep 2002 19:22:33 -0400 (EDT)

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

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