[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.42.0209151908330.848-100000@nimue.bos.bindview.com>
From: lcamtuf at ghettot.org (Michal Zalewski)
Subject: ALERT ALERT plaintext passwords in linux ALERT
ALERT
On Sun, 15 Sep 2002 silvio@....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@....bindview.com] [security]
[http://lcamtuf.coredump.cx] <=-=> bash$ :(){ :|:&};:
=-=> Did you know that clones never use mirrors? <=-=
http://lcamtuf.coredump.cx/photo/
Powered by blists - more mailing lists