NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/38982: PaX ASLR makes some programs crash



The following reply was made to PR kern/38982; it has been noted by GNATS.

From: Thomas Galliano <maillistthom%googlemail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
netbsd-bugs%netbsd.org@localhost, 
        Christian Biere <christianbiere%gmx.de@localhost>
Subject: Re: kern/38982: PaX ASLR makes some programs crash
Date: Thu, 2 Sep 2010 22:03:37 +0200

 Fix by
 http://mail-index.netbsd.org/source-changes/2010/08/23/msg012847.html
 Tested on netbsd-5 with daily build 201009010000Z
 
 --
 Thom
 
 2009/12/12 Jean-Yves Migeon <jym%netbsd.org@localhost>:
 > The following reply was made to PR kern/38982; it has been noted by GNATS=
 .
 >
 > From: Jean-Yves Migeon <jym%NetBSD.org@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc:
 > Subject: Re: kern/38982: PaX ASLR makes some programs crash
 > Date: Sat, 12 Dec 2009 22:06:51 +0100
 >
 > =A0I tracked down the issue a bit, and it is related to the setrlimit()
 > =A0usage for the stack size. When setting the value to an insanely big si=
 ze
 > =A0(or infinity), all programs will end with a SIGABRT.
 >
 > =A0In the case of useradd/vipw/libutil binaries, the:
 >
 > =A0(void)setrlimit(RLIMIT_STACK, &rlim);
 >
 > =A0found inside pw_init() (in lib/libutil/passwd.c) does the trick. If yo=
 u
 > =A0comment out the line, or at least, set the rlimit to a smaller size,
 > =A0libutil functions start working again.
 >
 > =A0From a more general PoV, using ulimit(3):
 >
 > =A0# sysctl -w security.pax.aslr.enabled=3D1
 > =A0# ls
 > =A0CVS =A0 =A0 =A0 =A0conf =A0 =A0 =A0 fs =A0 =A0 =A0 =A0 modules =A0 =A0=
 netinet6 =A0 netsmb =A0 =A0 sys
 > =A0Makefile =A0 crypto =A0 =A0 gdbscripts net =A0 =A0 =A0 =A0netipsec =A0=
  nfs =A0 =A0 =A0 =A0tags
 > =A0altq =A0 =A0 =A0 ddb =A0 =A0 =A0 =A0ipkdb =A0 =A0 =A0net80211 =A0 neti=
 sdn =A0 =A0opencrypto ufs
 > =A0arch =A0 =A0 =A0 dev =A0 =A0 =A0 =A0kern =A0 =A0 =A0 netatalk =A0 neti=
 so =A0 =A0 rump =A0 =A0 =A0 uvm
 > =A0coda =A0 =A0 =A0 dist =A0 =A0 =A0 lib =A0 =A0 =A0 =A0netbt =A0 =A0 =A0=
 netkey =A0 =A0 secmodel
 > =A0compat =A0 =A0 external =A0 miscfs =A0 =A0 netinet =A0 =A0netnatm =A0 =
 =A0stand
 > =A0# ulimit -s unlimited
 > =A0# ls
 > =A0Abort
 > =A0# vi
 > =A0Abort
 >
 > =A0... and so forth. I guess that the gmake issue is the same, as it star=
 ts
 > =A0by altering the stack ressource:
 >
 > =A0[...]
 > =A0 17022 =A0 =A0 =A01 gmake =A0 =A0CALL =A0getrlimit(3,0xbf0b6644)
 > =A0 17022 =A0 =A0 =A01 gmake =A0 =A0RET =A0 getrlimit 0
 > =A0 17022 =A0 =A0 =A01 gmake =A0 =A0CALL =A0setrlimit(3,0xbf0b6644)
 > =A0 17022 =A0 =A0 =A01 gmake =A0 =A0RET =A0 setrlimit 0
 > =A0 17022 =A0 =A0 =A01 gmake =A0 =A0CALL =A0issetugid
 > =A0 17022 =A0 =A0 =A01 gmake =A0 =A0RET =A0 issetugid 0
 > =A0[...]
 >
 > =A0setrlimit(3, 0xbf0b6644) =3D> setrlimit(RLIMIT_STACK, max) (called at =
 the
 > =A0beginning of the main of gmake). FWIW, max =3D=3D 67108864 (65k). If y=
 ou
 > =A0invoke gmake from a simple user and not from superuser, it will work a=
 s
 > =A0expected.
 >
 > =A0--
 > =A0Jean-Yves Migeon
 > =A0jym%NetBSD.org@localhost
 >
 >
 


Home | Main Index | Thread Index | Old Index