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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ