full-disclosure - ALERT ALERT plaintext passwords in linux ALERT ALERT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20020915163345.A7787@hamsec.aurora.sfo.interquest.net>
From: silvio at big.net.au (silvio@....net.au)
Subject: ALERT ALERT plaintext passwords in linux ALERT ALERT

On Sun, Sep 15, 2002 at 07:22:33PM -0400, Michal Zalewski wrote:
> 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...

yes. the point isnt that this is 100% garaunteed to work.. but probably gets
back to DOS AV days since everyone has full access to the system.

> 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).
 
correct.. CLONE_PID can do some stuff with this.  of course, gdb doesnt
support clone directly btw, but just the linuxthreads debugging api
sitting ontop of it.. likewise for strace/ltrace etc.

of course, posix gets broken by linux here in current linuxthreads
implementation (i think ngpt comes close to posix - almost fully?).

> > 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.

yah.. the theory is that daemon processes are occuping this range.

--
Silvio