I few clients starting calling me saying they are unable to login to Webmail (horde)

Looking in the maillog I found the following entries:

Apr 7 19:48:43 sa1 imapd-ssl: /usr/bin/couriertls: error while loading shared libraries: libresolv.so.2: failed to map segment from shared object: Cannot allocate memory
Apr 7 19:48:46 sa1 imapd-ssl: /usr/bin/couriertls: error while loading shared libraries: libkrb5support.so.0: failed to map segment from shared object: Cannot allocate memory
Apr 7 19:48:50 sa1 imapd-ssl: /usr/bin/couriertls: error while loading shared libraries: libc.so.6: failed to map segment from shared object: Cannot allocate memory
Apr 7 19:48:52 sa1 imapd-ssl: /usr/bin/couriertls: error while loading shared libraries: libc.so.6: failed to map segment from shared object: Cannot allocate memory
imapd /bin/sh: error while loading shared libraries: libdl.so.2

When i tried to restart courier-imap (/etc/init.d/courier-imap restart)
Failed to start with the following.

/usr/lib/courier-imap/authlib/authpsa: error while loading shared libraries: libfreebl3.so: failed to map segment from shared object: Cannot allocate memory
imapd /bin/sh: error while loading shared libraries: libdl.so.2: failed to map segment from shared object: Cannot allocate memory

var log messages

kernel: grsec: denied resource overstep by requesting 160133120 for RLIMIT_AS against limit 67108864 for /bin/env[env:3163] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/courier-imap/imapd.rc[imapd.rc:3160] uid/euid:0/0 gid/egid:0/0

Temp Solution

I rebooted the server into the previous kernel - 2.6.32.57-14.art.x86_64
courier-imap Now starts without any problems & webmail is working.

System Info
CentOS release 6.2 (Final)
ASL Version 3.0.22: CentOS 6 (SUPPORTED)

Please send a false positive report via ASL-Gui to Atomicorp so that they can react quickly.
I would do that all the time in that kind of cases. By a report the guys get all infos the need which they would have to ask for in the forum each time.
Thanks

I am having the same problem with users not able to access webmail. This started after booting into the latest kernel Linux 2.6.32.59-15.art.x86_64 this morning. This is the message in the maillog:

Apr 7 20:59:30 server8 imapd: Connection, ip=[::ffff:127.0.0.1]
Apr 7 20:59:30 server8 imapd: /usr/lib/courier-imap/authlib/authpsa: error while loading shared libraries: libstdc++.so.6: failed to map segment from shared object: Cannot allocate memory

I am using Plesk 10.4.4 Update 24 with Atomic Secured Linux 3.0.22 Centos

Same issue for me... just tagging along to get any updates on this - the reboot to the previous kernel is my solution for now...

I can confirm that the new kernel 2.6.32.59-16.art.x86_64 has resolved the issue.
Users can now login to Webmail (Horde)

No more errors after I restart courier-imap



Thanks guys!!

Hi,

Thought I'd stop by to give you some extra information about what caused this problem.

PaX's ASLR is implemented differently from that of the vanilla kernel. The vanilla kernel implements what is referred to as a "detached" heap. Normally the heap begins at the end of the binary image as mapped in memory. The vanilla kernel separated this, leaving a random-sized gap in the middle. The gap is actually security-relevant and one reason why PaX's implementation is different: with allocations above a certain size, glibc will switch to using mmap to satisfy allocation requests instead of extending the brk()-managed heap. Under memory pressure and with such an allocation, glibc could thus be forced under a vanilla kernel to allocate in the gap adjacent to the beginning of the brk()-managed heap. If an overflow were to occur in that allocation, it would then overflow into an area of the heap that would otherwise be inaccessible were it not for vanilla's ASLR implementation.

PaX has never introduced a gap below the heap and instead implemented its heap randomization by simply extending the existing mapping below the heap by a random amount. The randomization (on x86) was applied to bits 4-16 of the address, while vanilla (introducing multiple pages of gaps and needing page-alignment) applied it to bits 12-25.

Since upstream established that entropy up to bit 25th could be withstood by userland, the PaX team decided to increase the amount of randomization provided for the heap by PaX's ASLR, making it apply to bits 4-25. That's 21 bits of entropy compared to the 13 of a vanilla kernel. The way PaX increased its amount was by essentially creating a gap of its own, but then filling it with a NOACCESS mapping, as you can see from some recent maps output:



Back to the problem at hand here, we found that the courier imap daemon was implementing its own resource limits -- RLIMIT_AS in this case, which is a limit on the amount of address space used. The mapping that filled the gap between the binary image and the randomized base of the heap ended up being counted against this address space limit. After this was discovered, the fix was somewhat simple: just treat the heap "gap" mapping as unusable space and don't count it towards the address space limit.

Sorry for the temporarily problem, but know that you're benefiting now from even greater heap randomization as a result of this work.

Thanks!
-Brad

Everybody get that? Its going to be on the test.

Question 1: How many additional bits of entropy does the patched kernel provide compared to the vanilla kernel?
Question 2: Multiple choice: Does the grsec kernel make things () more secure () as secure () less secure
Question 3: .....

Pass mark: 90/100