[Full-Disclosure] ALERT ALERT plaintext passwords in linux ALERT ALERT
From: Michal Zalewski (lcamtuf@ghettot.org)
Date: 09/16/02
- Next message: silvio@big.net.au: "[Full-Disclosure] ALERT ALERT plaintext passwords in linux ALERT ALERT"
- Previous message: Michal Zalewski: "[Full-Disclosure] Re: C initialization of static objects (was: ALERT ALERT ALERT! google under attack ALERT ALERT ALERT!)"
- In reply to: silvio@big.net.au: "[Full-Disclosure] ALERT ALERT plaintext passwords in linux ALERT ALERT"
- Next in thread: silvio@big.net.au: "[Full-Disclosure] ALERT ALERT plaintext passwords in linux ALERT ALERT"
- Reply: silvio@big.net.au: "[Full-Disclosure] ALERT ALERT plaintext passwords in linux ALERT ALERT"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
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
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/
- Next message: silvio@big.net.au: "[Full-Disclosure] ALERT ALERT plaintext passwords in linux ALERT ALERT"
- Previous message: Michal Zalewski: "[Full-Disclosure] Re: C initialization of static objects (was: ALERT ALERT ALERT! google under attack ALERT ALERT ALERT!)"
- In reply to: silvio@big.net.au: "[Full-Disclosure] ALERT ALERT plaintext passwords in linux ALERT ALERT"
- Next in thread: silvio@big.net.au: "[Full-Disclosure] ALERT ALERT plaintext passwords in linux ALERT ALERT"
- Reply: silvio@big.net.au: "[Full-Disclosure] ALERT ALERT plaintext passwords in linux ALERT ALERT"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]