FS#12434 - PAX and OpenSSL (libcrypto.so)

Attached to Project: Arch Linux
Opened by Cristian C. (ckristi) - Saturday, 13 December 2008, 00:49 GMT
Last edited by Pierre Schmitz (Pierre) - Sunday, 28 December 2008, 20:14 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Pierre Schmitz (Pierre)
Architecture i686
Severity Very Low
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
OpenSSL does not play well with security enhanced kernels (PaX/grsecurity).

Additional info:
* openssl-0.9.8i-2


Steps to reproduce:

I applied the PaX patch to my custom kernel empowering Arch Linux. And I had the surprise that OpenSSL (libcrypto.so to be more precise) requested executable stack to run. After 2 days of "playing" around with PaX specific tools (user-level apps like paxctl/chpax) and reconfigurations at the kernel level... I found out a simple solution to this problem on a Debian or Debian-related forum (can't remember the link). The solution was to compile openssl using "-Wa,--noexecstack" on the config line.
So, I patched the PKGBUILD for openssl to do this, and now everything is working fine. Do you think you can enable this patch for the future builds of the openssl package? I'll attach the diff from the original PKGBUILD.
This task depends upon

Closed by  Pierre Schmitz (Pierre)
Sunday, 28 December 2008, 20:14 GMT
Reason for closing:  Implemented
Comment by Glenn Matthys (RedShift) - Saturday, 13 December 2008, 09:11 GMT
This is not a "small change" and can have serious consequences. Did you at least run the regression tests in the Makefile?
Comment by Glenn Matthys (RedShift) - Saturday, 13 December 2008, 09:20 GMT
Some more research indicates it could have effects on NX technology: http://en.wikipedia.org/wiki/NX_bit#PaX_2
Comment by Pierre Schmitz (Pierre) - Saturday, 13 December 2008, 13:38 GMT
I wont change openssl for anything that is not supported by us. Openssl is much too critical to play with.
Comment by Cristian C. (ckristi) - Saturday, 13 December 2008, 14:47 GMT
Debian has this patch added to their packages even if the user does not want to use PaX. Not requiring an executable page for running is good programming practice, AFAIK. New CPUs have the NX bit which can be enabled on a custom kernel with PAE enabled without using PaX. I'm afraid, those users are affected, too. And besides, it does not make openssl unstable.
Comment by Glenn Matthys (RedShift) - Saturday, 13 December 2008, 15:12 GMT
I don't trust it. If it's really better it would be enabled by default. You don't know if it makes openssl unstable or not. And like Pierre says, this is really an edge case, it's easy to build your own variant.
Comment by Cristian C. (ckristi) - Saturday, 13 December 2008, 19:09 GMT
Well.. I'm running it. And I am running apache, openssh and bind... all of them using openssl. None is broken by this change. Also, as I stated before Debian is using this flag for their package. And if Debian is unstable, then Arch should never exist. Why does Arch claims to be "bleeding edge" then? I think Arch should know that many people adhere to its simplicity, and after a period of accomodation would like to run Arch as a server. What's so wrong in hardening Arch? Gentoo offers hardened packages, Slackware is playing fine with PaX or the default kernel implementation of NX. I'm not asking you to find a solution, I did my research and I found it... I even created a new PKGBUILD and I'm not wining... "please, please, mister developer... do this for me!"... I just did it and provide it as is. I don't even want credit for it, but it's a good thing to have. I think I'll just get back to Slackware. I'm already starting to feel sorry that I try to make things better.
Comment by Glenn Matthys (RedShift) - Saturday, 13 December 2008, 19:20 GMT
A "works for me" doesn't mean "works for all".
Comment by Cristian C. (ckristi) - Saturday, 13 December 2008, 19:31 GMT
There was a testing repository for this purpose if I'm recalling well. An "I don't want to do a thing because it might break things" it's not a developer attitude. But that's just me.
Comment by Cristian C. (ckristi) - Saturday, 13 December 2008, 19:37 GMT
I request a fork of this package and I'm offering to maintain it. But for an admin is great to use the package manager to update, without playing every time with the PKGBUILD. If you are able to understand this, it's ok, if not... there's no problem with me. I'll just switch. I was happy with Slackware for servers, but happier with Arch. Now I am not anymore. Ah.. and about the "works for me" statement. Do you wanna count Debian users and compare it to the Arch number of users? They use openssl packages built with "-Wa,--noexecstack". I think it works for more people than Arch has at this moment. And I am not a Debian fan. That's just a fact.
Comment by Jan de Groot (JGC) - Saturday, 13 December 2008, 20:09 GMT
Redhat also compiles OpenSSL with these flags:
# Add -Wa,--noexecstack here so that libcrypto's assembler modules will be
# marked as not requiring an executable stack.
Comment by Cristian C. (ckristi) - Saturday, 13 December 2008, 20:49 GMT
Thanks Jan for your support.
Comment by Glenn Matthys (RedShift) - Saturday, 13 December 2008, 20:50 GMT
I'm pretty conservative when it comes to changes like these. Anyway, ckristi, did you run the regression tests?
Comment by Cristian C. (ckristi) - Saturday, 13 December 2008, 21:09 GMT
I just did. Here you are. I attached the tests.log gzipped file (obtained running make test > tests.log 2>&1).


(application/octet-stream)    tests.log.gz (15.6 KiB)
Comment by Johannes Krampf (wuischke) - Sunday, 14 December 2008, 01:05 GMT
I would like to second the request.

The Gentoo page on this (http://www.gentoo.org/proj/en/hardened/gnu-stack.xml) states: "If an assembler source contains no GNU-stack note, the system by default assumes that an executable stack may be required. However, usually if there's no GNU-stack note, this is simply because the author didn't include one, rather than the code actually needing an executable stack."

As it works on other systems, I would assume that the assembler parts don't contain the GNU-stack note and don't require an executable stack.
Comment by Cristian C. (ckristi) - Sunday, 14 December 2008, 05:55 GMT
Linux From Scratch (http://wiki.linuxfromscratch.org/hlfs/wiki/openssl) states:
The as assembler program will incorrectly mark libcrypto.so as needing an executable stack, if OpenSSL is built with its assembly code. The following command adds an assembler option to mark the library correctly:

find crypto/ -name Makefile -exec \
sed 's/^ASFLAGS=/&-Wa,--noexecstack /' -i.orig {} \;

Also, there's a 5 year testing on Fedora (http://lwn.net/Articles/211328/):
* Tue Sep 30 2003 Nalin Dahyabhai <nalin@redhat.com> 0.9.7a-22
- add -Wa,--noexecstack to RPM_OPT_FLAGS so that assembled modules get tagged
as not needing executable stacks
Comment by Pierre Schmitz (Pierre) - Sunday, 14 December 2008, 14:47 GMT
This is all fine, but what's the benefit if we don't use the PAX patchset?
Comment by Cristian C. (ckristi) - Sunday, 14 December 2008, 16:13 GMT
Users of PaX (or people with newer processors who would like to enable the NX/XD bit) will benefit, while the others will see no change (either good or bad). Nobody loses, so I really don't get the reason why you would not apply this patch. It's just a question of marking what libcrypto.so is going to expect. If it does not expect the stack to be executable, if it is executable it's not affected. But if it is expecting to be executable, when it's not exececutable, all services depending on openssl will fail.
Comment by Pierre Schmitz (Pierre) - Sunday, 14 December 2008, 16:58 GMT
Well, I think this discussion got somehow out of controll. I only mentioned that I don't see the point if only users of unofficial packages are affected by this problem. Of course this is different if this chagne would be effective for all NX-capable CPUs; all amd64 and newer P4s support this technique.

I'll put a new openssl package into [testing].
Comment by Cristian C. (ckristi) - Sunday, 14 December 2008, 17:11 GMT
Well, the NX/XD bit would have to be enabled in the kernel too, not only in BIOS. For that, the kernel needs to be compiled with support for 64G of memory and PAE enabled (in case of 32bit systems). This is not enabled in the default Arch kernel. One needs to compile a custom kernel for this. But for a sysadmin this is not at all improbable. I do compile custom kernels for almost all the servers I manage. Unfortunately, for my homeserver I only have an old P4, that's why I was using the PaX patch and not NX. Thanks in advance for the change and sorry if I got too ballistic at some points.
Comment by Johannes Krampf (wuischke) - Sunday, 14 December 2008, 22:33 GMT
Thank you for applying this change. I have installed openssl 0.9.8i-3 from testing. I have not yet found any problems when using ssh/scp with higher bandwidth transfers. The CPU usage on a (throttled) 800 MHz notebook C2D is reported by top as 0 percent (indicating usage of the assembler routines) and I have found no functionality problems so far.

As I use wpa2, my wireless connection depends on openssl, so I'll complain in time if there are any problems. ;-)
Comment by Markus Dittrich (markusle) - Monday, 15 December 2008, 15:24 GMT
The removal of executable stacks especially in a package like openssl is definitely a good thing.
I've tested the new 0.9.8i-3 and it has been working flawlessly so far. Thanks much.
Comment by Glenn Matthys (RedShift) - Monday, 15 December 2008, 21:24 GMT
I was too soon to judge this, I was too conservative. If the test in [testing] goes fine I see no more reason why this shouldn't go through.

Loading...