12492 2011-02-15 14:44:00 +0000 dl: RELRO handling crashes when kernel enforces MPROTECT restrictions 2012-03-29 14:56:50 +0000 1 1 1 Unclassified glibc dynamic-link 2.11 All All REOPENED P2 normal --- 1 linkfanel drepper.fsp atoth ireopenit kees pageexec thoger 47078 5242 linkfanel 2011-02-15 14:44:32 +0000 Created attachment 5242 Proposed fix See Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611195 When dlopen'ing a library that needs to make the stack executable, the RELRO section is made writable again to modify the __stack_prot variable. However, the return value of the mprotect() call is not checked; so if mprotect() fails, instead of gracefully handling the error, the dynamic loader tries to write to __stack_prot anyway, which results in a segmentation fault. And this mprotect() call *will* fail on PaX kernels that enforce restrictions on it. The simple fix is to check the return value and simply fail to load the problematic library, instead of crashing the whole process. And it's just good programming practice. 47081 drepper.fsp 2011-02-15 19:30:30 +0000 Just use a supported kernel. 47084 pageexec 2011-02-15 20:03:46 +0000 mprotect() can fail on supported kernels (what are they anyway?), so it is simply bad programming practice to not check the return value. 47097 drepper.fsp 2011-02-17 05:45:00 +0000 No, it cannot fail in these situations. 47098 pageexec 2011-02-17 10:02:59 +0000 merging and splitting vma structures require memory allocation that can fail. 47099 pageexec 2011-02-17 10:25:43 +0000 i almost forgot, you didn't answer my question: what is your definition of a supported kernel? 47114 drepper.fsp 2011-02-18 16:40:41 +0000 Stop reopening the bug. If you have to redefine what your own OS does then maintain your own version of everything else as well. 47115 ireopenit 2011-02-18 16:53:35 +0000 Do you have any real reason not to apply the submitted patch? Childish spite doesn't count. 47116 kees 2011-02-18 17:08:11 +0000 The stock Linux kernel can fail the mprotect call. The LSM mediates this routine. Even SELinux has hooks to reject certain calls. It seems prudent to check the return code since LSMs are being improved/changed all the time. 47119 pageexec 2011-02-18 19:43:01 +0000 since this bug affects any kernel, including those of your own employer, it will stay open until it gets fixed. it's also obvious that failing the second mprotect in the same block of code means you've left ld.so's RELRO region writable and that's a security bug itself so you'd better check its return value as well and ask for a CVE. 47132 linkfanel 2011-02-21 04:05:59 +0000 First of all, I'm sorry for all of this that I started :( I'm sorry to use up so much of your time, I imagine that dealing with bug reports and trivial issues must be boring and sometimes frustrating. I'm just trying to help by taking care some of the dull janitor job like checking return values: a patch is all ready and it only needs someone to commit it. glibc is a great piece of software and I'm sure people look at it as a coding model, so it would be a shame to leave examples that could look like bad practice, even if that part of the code is not so important in itself. I'd love to see this matter just resolved. If you don't mind. Please please accept my humble apology along with this patch. 47294 linkfanel 2011-03-02 22:12:09 +0000 The patch was merged into eglibc (http://www.eglibc.org/archives/commits/msg01710.html). I guess than rather than "just use a supported kernel", I'll have to just use a supported libc :( Pax Team, any suggestion about what should be done if the second mprotect() fails? 47295 pageexec 2011-03-02 22:30:32 +0000 probably the same as with the first mprotect failure. 47297 linkfanel 2011-03-03 02:09:51 +0000 But it still leaves the RELRO region writable, and I doubt the calling application is going to do anything about it 47298 pageexec 2011-03-03 08:40:54 +0000 by default the code after call_lose_errno won't return to the application ;). 47502 charliesheen 2011-03-15 15:54:27 +0000 __stack_prot |= PROT_READ|PROT_WRITE|PROT_EXEC; Whoever wrote this, you are rwx-winning. You win at reads, you win at writes and you win at execution. I couldn't have done it better even if I banged a seven gram text-relocating rock. 5242 2011-02-15 14:44:00 +0000 2011-02-15 14:44:32 +0000 Proposed fix dl.patch text/plain 585 linkfanel LS0tIGVsZi9kbC1sb2FkLmMJMjAxMS0wMS0yNiAyMjowMjowMi4wMDAwMDAwMDAgKzAxMDAKKysr IGVsZi9kbC1sb2FkLmMJMjAxMS0wMS0yNiAyMjozMDoyMi4wMDAwMDAwMDAgKzAxMDAKQEAgLTEz OTgsNyArMTM5OCwxMSBAQAogCSAgaWYgKF9fYnVpbHRpbl9leHBlY3QgKHAgKyBzIDw9IHJlbHJv X2VuZCwgMSkpCiAJICAgIHsKIAkgICAgICAvKiBUaGUgdmFyaWFibGUgbGllcyBpbiB0aGUgcmVn aW9uIHByb3RlY3RlZCBieSBSRUxSTy4gICovCi0JICAgICAgX19tcHJvdGVjdCAoKHZvaWQgKikg cCwgcywgUFJPVF9SRUFEfFBST1RfV1JJVEUpOworCSAgICAgIGlmIChfX21wcm90ZWN0ICgodm9p ZCAqKSBwLCBzLCBQUk9UX1JFQUR8UFJPVF9XUklURSkgPCAwKQorCQl7CisJCSAgZXJyc3RyaW5n ID0gTl8oImNhbm5vdCBjaGFuZ2UgbWVtb3J5IHByb3RlY3Rpb25zIik7CisJCSAgZ290byBjYWxs X2xvc2VfZXJybm87CisJCX0KIAkgICAgICBfX3N0YWNrX3Byb3QgfD0gUFJPVF9SRUFEfFBST1Rf V1JJVEV8UFJPVF9FWEVDOwogCSAgICAgIF9fbXByb3RlY3QgKCh2b2lkICopIHAsIHMsIFBST1Rf UkVBRCk7CiAJICAgIH0K