[sudo-users] [BUG] Another system (solaris 10 sparc) requires --disable-pie flag

[Christian Jullien]

Same issue with -fPIE -pie,

The notable differences between -pie and no pie are that:

1) the second call to memcntl  is high mem with pie and low mem with no pie

With pie:
memcntl(0xFF380000, 17900, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
memcntl(0xFF3E0000, 1424, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0

Without pie
memcntl(0xFF3A0000, 17900, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
memcntl(0x00010000, 1204, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0

This is probably the reason why malloc (after brk call) fails when memory is
high.

2) pie version adds 2 extra calls to mprotect:

mprotect(0xFF3E0000, 2124, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0xFF3E0000, 2124, PROT_READ|PROT_EXEC) = 0
that does not exist in the non -pie version

[jullien at pastre]src$ gcc -o foo -fPIE -pie foo.c && ./foo
malloc 0
[jullien at pastre]src$ truss ./foo
execve("foo", 0xFFBFFD0C, 0xFFBFFD14)  argc = 1
sysinfo(SI_MACHINE, "sun4u", 257)               = 6
mmap(0x00000000, 32, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON,
-1, 0) = 0xFF3C0000
mmap(0x00000000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) =
0xFF370000
mmap(0x00000000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) =
0xFF360000
mmap(0x00000000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON,
-1, 0) = 0xFF350000
memcntl(0xFF380000, 17900, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
memcntl(0xFF3E0000, 1424, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
resolvepath("/usr/lib/ld.so.1", "/lib/ld.so.1", 1023) = 12
getcwd("/export/home/jullien/sudo-1.8.7rc3/src", 1019) = 0
resolvepath("/export/home/jullien/sudo-1.8.7rc3/src/foo",
"/export/home/jullien/sudo-1.8.7rc3/src/foo", 1023) = 42
stat64("/export/home/jullien/sudo-1.8.7rc3/src/foo", 0xFFBFF7D0) = 0
open("/var/ld/ld.config", O_RDONLY)             Err#2 ENOENT
stat64("/usr/local/lib/libc.so.1", 0xFFBFEF30)  Err#2 ENOENT
stat64("./libc.so.1", 0xFFBFEF30)               Err#2 ENOENT
stat64("/lib/libc.so.1", 0xFFBFEF30)            = 0
resolvepath("/lib/libc.so.1", "/lib/libc.so.1", 1023) = 14
open("/lib/libc.so.1", O_RDONLY)                = 3
mmap(0x00010000, 32768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_ALIGN, 3, 0) =
0xFF340000
mmap(0x00010000, 1368064, PROT_NONE,
MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFF180000
mmap(0xFF180000, 1247157, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_TEXT, 3, 0) = 0xFF180000
mmap(0xFF2C2000, 35965, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_INITDATA, 3, 1253376) = 0xFF2C2000
mmap(0xFF2CC000, 1616, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1, 0) = 0xFF2CC000
munmap(0xFF2B2000, 65536)                       = 0
munmap(0xFF340000, 32768)                       = 0
close(3)                                        = 0
memcntl(0xFF180000, 146148, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
mprotect(0xFF3E0000, 2124, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0xFF3E0000, 2124, PROT_READ|PROT_EXEC) = 0
mmap(0x00010000, 24576, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFF340000
getcontext(0xFFBFF640)
getrlimit(RLIMIT_STACK, 0xFFBFF620)             = 0
getpid()                                        = 614 [613]
setustack(0xFF342A88)
brk(0xFF3F09E8)                                 Err#12 ENOMEM
ioctl(1, TCGETA, 0xFFBFEC4C)                    = 0
fstat64(1, 0xFFBFEB68)                          = 0
stat64("/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1", 0xFFBFE148) = 0
resolvepath("/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1",
"/platform/sun4u/lib/libc_psr.so.1", 1023) = 33
open("/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1", O_RDONLY) = 3
mmap(0x00010000, 16856, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_ALIGN, 3, 0) =
0xFF330000
munmap(0xFF334000, 472)                         = 0
close(3)                                        = 0
malloc 0
write(1, " m a l l o c   0\n", 9)               = 9
_exit(9)
-----Original Message-----
From: Todd C. Miller [mailto:Todd.Miller at courtesan.com] 
Sent: jeudi 23 mai 2013 22:36
To: Christian Jullien
Cc: sudo-users at sudo.ws
Subject: Re: [sudo-users] [BUG] Another system (solaris 10 sparc) requires
--disable-pie flag

On Thu, 23 May 2013 21:47:30 +0200, "Christian Jullien" wrote:

> I get:
> [jullien at pastre]src$ gcc -o foo -pie foo.c && ./foo malloc 0

That should be:

gcc -o foo -fPIE -pie foo.c && ./foo

You need to compile the objects with -fPIE and link with -pie.

> Now the question, why do you link the binaries with -pie ? as in

Because pie is Position Independent Executable.  For shared libs you only
need -fPIC.

The whole point of PIE binaries is that the entire executable, not just the
shared libraries, are position independent.  On systems that support address
space layout randomization (ASLR) this makes it harder to exploit bugs since
the addresses change with each invocation.

Now, I don't think that Solaris actually supports ASLR until version 11.1.
Unfortunately, there isn't a good way to test for whether PIE gives you a
benefit in configure.  As things stand now, if the compiler appears to
support it, sudo will attemp to use it.

 - todd