From: Brad Spengler Subject: [grsec] grsecurity 2.1.0 release / 5 Linux kernel advisories Date: Fri, 7 Jan 2005 12:20:49 -0500 grsecurity 2.1.0 release / Linux Kernel advisories -------------------------------------------------------------------- Table Of Contents: 1) grsecurity 2.1.0 announcement and changelog 2) Linux Kernel advisory introduction 3) 2.4/2.6 random poolsize sysctl handler integer overflow 4) 2.6 scsi ioctl integer overflow and information leak 5) 2.2/2.4/2.6 moxa serial driver bss overflow 6) 2.4/2.6 RLIMIT_MEMLOCK bypass and (2.6) unprivileged user DoS 7) Attachments, including patches for all vulns, a POC for #3, and a working exploit for #6 1) grsecurity 2.1.0 announcement and changelog I'm happy to announce the release of grsecurity 2.1.0. It is being released initially for the 2.4.28 and 2.6.10 kernels and will be ported immediately to the next kernel versions when released. It can be downloaded at http://www.grsecurity.net. We are still actively seeking sponsorship, so if you benefit from using grsecurity and like the changes you see in 2.1.0, please consider sponsoring the future development and maintenance of the project. Changes in this release include: * New configuration file for full learning: /etc/grsec/learn_config * Learning heuristics have been optimized to better detect temporary file usage and reduce appropriately. * Learning heuristics have been modified to weight against reducing certain additional important directories. * User/group ID transitions have been added to the learning system. Any subject transitioning to less than 3 different users or 3 different groups that has CAP_SETUID or CAP_SETGID will have ID transitions added. This is useful to automatically secure applications that only transition to one or few users/groups like nobody/nogroup. * /proc/<pid>/* accesses are automatically rewritten as /proc by grlearn before being cached and written to disk * The inherit-based learning usable through the learning configuration file is usable through a regular policy as well simply by adding "i" instead of "l" to a subject for learning. * Inheritance is preserved whenever possible across uid/gid changes when the role resulting from the uid/gid change is no different from that before the change. * A complete ~95-99% efficient LFU-hash hybrid caching system has been added that greatly reduces the number of full object lookups by caching the result. The cache essentially mimics the filesystem around where applications are operating: nearly equivalent to having an object for every file and directory on the system, but without the wasted memory. The cache is invalidated on creates and deletes that cause a change in policy (through policy re-creation) and on renames of directories or symlinks. * Memory usage for non-full learning has been significantly reduced and all memory leaks have been plugged. * A new object mode has been added for hardlinks for more fine-grained permissions. See the sample policy file for information on what permissions are required to create a hardlink. Its corresponding audit flag has been added as well. * Destruction of unused shared memory feature added and included in the sysctl framework of grsecurity. This feature was ported from Openwall (http://www.openwall.com/linux). * A new option was added to the sysctl feature that enables at boot all features enabled in the kernel configuration, while allowing them to be changed via the sysctl interface until grsec_lock is set. * Policy statistics have been added to gradm that provide useful, security-relevant information on the policy you are loading into the kernel. You can view these statistics when enabling the system by running gradm -V -E. * Interactive performance of full-learning has improved by ~15% by reducing the number of context switches caused by grlearn doing small disk writes by using a write buffer (writing more once instead of less 1000 times) and keeping track of log entry lengths for quicker string matching. A signal handler was added to grlearn so that when learning is stopped, the write buffer is flushed to disk. * Kernel headers are no longer used for gradm * Updates from the PaX project (http://pax.grsecurity.net) * Bugfixes for things mentioned on the list, etc When patching your kernel for the 2.4.28 and 2.6.10 kernels, since they contain several vulnerabilities, make sure to also apply the secfix patches located on the website. 2) Linux Kernel advisory introduction Let me begin by giving you a timeline: December 15th: I send Linus a mail with a subject line of "RLIMIT_MEMLOCK bypass with locked stack" December 27th: The PaX team sends Linus a mail with a subject line of "2.6.9+ mlockall/expand_down DoS by unprivileged users" January 2nd: The PaX team resends the previous mail to Linux and Andrew Morton Between December 15th and today, Linus has committed many changes to the kernel. Between January 2nd and today, Andrew Morton has committed several changes to the kernel. 3 weeks is a sufficient amount of time to be able to expect even a reply about a given vulnerability. A patch for the vulnerability was attached to the mails, and in the PaX team's mails, a working exploit as well. Private notification of vulnerabilities is a privilege, and when that privilege is abused by not responding promptly, it deserves to be revoked. Using 'advanced static analysis': "cd drivers; grep copy_from_user -r ./* | grep -v sizeof", I discovered 4 exploitable vulnerabilities in a matter of 15 minutes. More vulnerabilities were found in 2.6 than in 2.4. It's a pretty sad state of affairs for Linux security when someone can find 4 exploitable vulnerabilities in a matter of minutes. Since there was no point in sending more vulnerability reports when the first hadn't even been responded to, I'm including all four of them in this mail, as well as a POC for the poolsize bug. The other bugs can have POCs written for just as trivially. The poolsize bug requires uid 0, but not any root capabilities. The scsi and serial bugs depend on the permissions of their respective devices, and thus can possibly be exploited as non-root. The scsi bug in particular has a couple different attack vectors that I haven't even bothered to investigate. Some of these bugs have gone unfixed for several years. The PaX team discovered the mlockall DoS. It has been fixed in PaX for 2 years. I have attached their mail and exploit code. I'd really like to know what's being done about this pitiful trend of Linux security, where it's 10x as easy to find a vulnerability in the kernel than it is in any app on the system, where isec releases at least one critical vulnerability for each kernel version. I don't see that the 2.6 development model is doing anything to help this (as the spectrum of these vulnerabilities demonstrate), by throwing experimental code into the kernel and claiming it to be "stable". Hopefully now these vulnerabilities will be fixed in a timely manner. 3) 2.4/2.6 random poolsize sysctl handler integer overflow In drivers/char/random.c: at poolsize_strategy(): > int len; ^ signed integer > > sysctl_poolsize = random_state->poolinfo.POOLBYTES; > > /* > > /* > * We only handle the write case, since the read case gets > * handled by the default handler (and we don't care if the > * write case happens twice; it's harmless). > */ > if (newval && newlen) { > len = newlen; ^ unsigned int converted to signed > if (len > table->maxlen) ^ comparison of two signed integers > len = table->maxlen; > if (copy_from_user(table->data, newval, len)) ^ copy_from_user with len possibly > table->maxlen 4) 2.6 scsi ioctl integer overflow and information leak In drivers/block/scsi_ioctl.c: at sg_scsi_ioctl(): > struct request *rq; > int err, in_len, out_len, bytes, opcode, cmdlen; ^ in_len, out_len are signed int > char *buffer = NULL, sense[SCSI_SENSE_BUFFERSIZE]; > > /* > * get in an out lengths, verify they don't exceed a page worth of data > */ > if (get_user(in_len, &sic->inlen)) ^ in_len is user-controlled > return -EFAULT; > if (get_user(out_len, &sic->outlen)) ^ out_len is user-controlled > return -EFAULT; > if (in_len > PAGE_SIZE || out_len > PAGE_SIZE) ^ signed int only has upper bound checked > return -EINVAL; > if (get_user(opcode, sic->data)) > return -EFAULT; > bytes = max(in_len, out_len); ... > rq->cmd_len = cmdlen; > if (copy_from_user(rq->cmd, sic->data, cmdlen)) > goto error; > > if (copy_from_user(buffer, sic->data + cmdlen, in_len)) ^ copy_from_user with size possibly > PAGE_SIZE > goto error; ... > if (copy_to_user(sic->data, buffer, out_len)) ^ copy_to_user with size possibly > PAGE_SIZE > err = -EFAULT; 5) 2.2/2.4/2.6 moxa serial driver bss overflow In drivers/char/moxa.c: >static unsigned char moxaBuff[10240]; In MoxaDriverIoctl(): > if(copy_from_user(&dltmp, argp, sizeof(struct dl_str))) > return -EFAULT; ^ dltmp.len is user-controlled > if(dltmp.cardno < 0 || dltmp.cardno >= MAX_BOARDS) > return -EINVAL; > > switch(cmd) > { > case MOXA_LOAD_BIOS: > i = moxaloadbios(dltmp.cardno, dltmp.buf, dltmp.len); ^ called with no length checking > return (i); > case MOXA_FIND_BOARD: > return moxafindcard(dltmp.cardno); > case MOXA_LOAD_C320B: > moxaload320b(dltmp.cardno, dltmp.buf, dltmp.len); ^ called with no length checking > default: /* to keep gcc happy */ > return (0); > case MOXA_LOAD_CODE: > i = moxaloadcode(dltmp.cardno, dltmp.buf, dltmp.len); ^ called with no length checking In moxaloadbios(): >static int moxaloadbios(int cardno, unsigned char __user *tmp, int len) >{ > void __iomem *baseAddr; > int i; > > if(copy_from_user(moxaBuff, tmp, len)) ^ copy_from_user with no length checking > return -EFAULT; In moxaloadcode(): > static int moxaloadcode(int cardno, unsigned char __user *tmp, int len) > { > void __iomem *baseAddr, *ofsAddr; > int retval, port, i; > > if(copy_from_user(moxaBuff, tmp, len)) ^ copy_from_user with no length checking > return -EFAULT; In moxaload320b(): >static int moxaload320b(int cardno, unsigned char __user *tmp, int len) >{ > void __iomem *baseAddr; > int i; > > if(len > sizeof(moxaBuff)) ^ signed int has only upper-bound checked > return -EINVAL; > if(copy_from_user(moxaBuff, tmp, len)) ^ copy_from_user with len possibly > sizeof(moxaBuff) > return -EFAULT; 6) 2.4/2.6 RLIMIT_MEMLOCK bypass and (2.6) unprivileged user DoS Taken from the mail from the PaX team to Linus and Andrew Morton: the 'culprit' patch is how the default RLIM_MEMLOCK and the privilege to call mlockall have changed in 2.6.9. namely, the former has been reduced to 32 pages while the latter has been relaxed to allow it for otherwise unprivileged users if their RLIM_MEMLOCK is bigger than the currently allocated vm. which is normally good enough, except as you now know there's a path that can increase the allocated vm without checking for RLIM_MEMLOCK. i'm attaching a small i386-specific demonstration, use the makefile to create the small self-contained executable, e.g., 'make alloc=0x100000' to have it allocate 1MB of stack and lock all of it. for demonstrating the full effect of locking down arbitrary amounts of memory, you'll have to set your stack rlimit to infinity (ulimit -s unlimited) and allocate as much memory as your memory overcommit policy allows (this may mean that you'll have to run multiple instances, if you have lots of memory). surprisingly, in my tests the kernel survived pretty well, it just crawled to a snail's speed as every mapped page access required disk i/o ;-). i didn't play with overcommit policies nor any special workloads, so there may very well be worse effects with that much locked memory. in any case, this may warrant 2.6.10.1 because as soon as the fix goes into -bk, anyone reading the logs can easily figure it out and reproduce the 'exploit'. the attached patch is the excerpt from PaX that survives the exploit, so i think it's good to go.
http://grsecurity.net/linux-2.4.28-secfix-200501071141.patch
http://grsecurity.net/linux-2.6.10-secfix-200501071130.patch
06:40PM <spender> my patch won't work on processor's without an mmu 06:40PM <spender> for the isec bug 06:40PM <spender> err processors 06:40PM <spender> but it wasn't a problem for my case 06:40PM <spender> just for yours, you might want to add the missing function and export_symbol to mm/nommu.c 06:41PM <ms> no success with 2.6.8... 06:41PM <ms> however I notice 2.6.8 really sucks ;) <solar> so this and this are no good? http://bugs.gentoo.org/attachment.cgi?id=47891&action=view <solar> http://bugs.gentoo.org/attachment.cgi?id=47865&action=edit 06:42PM <spender> oh, no the 2.4 one is fine 06:42PM <spender> it's just the 2.6 06:43PM <spender> btw 06:43PM <spender> if grsec sources includes pax 06:43PM <spender> you need to use my patch for binfmt_elf.c 06:43PM <spender> because you need to hold the semaphore around both the do_brk and pax's do_mmap_pgoff 06:43PM <spender> can't just lock both separately 06:44PM <spender> but yea that patch you have there looks fine, just i think you have to export the do_brk_locked symbol 06:44PM <spender> well, if do_brk is exported in there already <solar> can I add this as a comment to that bug? 06:44PM <spender> yea 06:45PM <spender> but that 2.6 patch is better than the one i saw on lkml at least 06:45PM <spender> it has the sparc64 change
grsec 2.4.28.2.0.1-200501051112 is in the tree, but will be -* masked for a little while pending testing and waiting/watching for upstream changes. Adds linux-2.4.28-CAN-2004-0814.patch & linux-2.4.28-random-poolsize.patch
06:44PM <spender> but yea that patch you have there looks fine, just i think you have to export the do_brk_locked symbol In mmap.c, do_brk is exported, and our patch adds do_brk_locked and exports it. In nommu.c, do_brk is not exported, and our patch adds do_brk_locked and does not export it. I think this is ok, see the next thing he said: 06:44PM <spender> well, if do_brk is exported in there already ...which its not.
3) 2.4/2.6 random poolsize sysctl handler integer overflow #3 is fixed in grsec-sources and in the 2.6.x -ac branch. 4) 2.6 scsi ioctl integer overflow and information leak should be fixed in -ac branch. 5) 2.2/2.4/2.6 moxa serial driver bss overflow Brads Patch does not apply to 2.4.x (already in grsec I think) fixed in -ac 6) 2.4/2.6 RLIMIT_MEMLOCK bypass and (2.6) unprivileged user DoS This is fixed directly by the PaX patch. (fixed in -ac) Tim do you have any of this broken out and can attach here or other bugs?
Yeah it was fixed in -ac7 2.6.10-ac7 + Fix failure at boot with some setups and ac6 (Alan Cox) | Dumb bug indeed o Fix random poolsize sysctl (Brad Spengler) o Fix scsi_ioctl leak (Brad Spengler) o Fix rlimit memlock (Brad Spengler) o Fix Moxa serial (Alan Cox) | While moxa won't actually even build on 2.6 the grsecurity fix | is wrong (for 2.2, 2.4 as well). Without it being CAP_SYS_RAWIO | a user can insert alternative bios firmware into the card.
Created attachment 48020 [details, diff] patch-2.6.10-ac-6-7.interdiff interdiff patch-2.6.10-ac6 patch-2.6.10-ac7
Here are the broken out patches: http://dev.gentoo.org/~dsd/gentoo-dev-sources/release-10.04/dist/1115_sys-uselib-fix.patch http://dev.gentoo.org/~dsd/gentoo-dev-sources/release-10.04/dist/1120_moxa-overflow.patch http://dev.gentoo.org/~dsd/gentoo-dev-sources/release-10.04/dist/1125_random-poolsize-overflow.patch http://dev.gentoo.org/~dsd/gentoo-dev-sources/release-10.04/dist/1130_rlimit-memlock-dos.patch http://dev.gentoo.org/~dsd/gentoo-dev-sources/release-10.04/dist/1135_scsi-ioctl-overflox.patch gentoo-dev-sources is fixed, btw.
dsd thanks. Can you please chmod 644 1130_rlimit-memlock-dos.patch I getting no permission to access atm.
@Solar, you can get the exact same patch from this tarball: http://seclists.org/lists/bugtraq/2005/Jan/att-0068/exploits_and_patches.tgz. or the genpatches tarball from a mirror, or from here (albeit as a patch to genpatches ;): http://genpatches.bkbits.net:8080/genpatches/cset@41e038bcWgRXUZFr9okc0cOZhtwNNg?nav=index.html|ChangeSet@-2d @dsd, I notice that you have asked for gentoo-dev-sources-2.6.10-r4 to be tested pending a move to stable. I'm about to reboot my production box with it so I'll post a works-for-me(tm) when I can.
Fixed permissions. 2.6.10-r4 is also stable already, hence me noting it as fixed :)
> 2.6.10-r4 is also stable already, hence me noting it as fixed :) Excellent.
Created attachment 48045 [details, diff] 2.6 Compound Patch
Created attachment 48046 [details, diff] 2.4 Patch (*WARNING* Read comment below!) For 2.4 kernels you also need to apply the updated CAN-2004-0814 patches in addition to the 2.4 patch attached on this bug. For 2.4.28, link to and use http://dev.gentoo.org/~plasmaroo/patches/kernel/misc/security/linux-2.4.28-CAN-2004-0814.patch For 2.4.27, link to and use http://dev.gentoo.org/~plasmaroo/patches/kernel/misc/security/linux-2.4.27-CAN-2004-0814.2.patch For 2.4.26, link to and use http://dev.gentoo.org/~plasmaroo/patches/kernel/misc/security/linux-2.4.26-CAN-2004-0814.2.patch
All done, following externally maintained sources still need fixing: hardened-(dev-)sources -- Adding hardened herd... hppa-sources -- Adding GMSoft... mips-sources -- Adding Kumba... openmosix-sources -- Adding cluster herd... pegasos-dev-sources -- Adding dholm... rsbac-(dev-)sources -- Adding kang... sparc-sources -- Adding Joker.
Done in hppa-sources-2.6.10_p10.
done for openMo6-sources.
dsd: Applying the random poolsize overflow patch from: http://dev.gentoo.org/~dsd/gentoo-dev-sources/release-10.04/dist/1125_random-poolsize-overflow.patch generates Hunks because the line does not match with the 2.6.10 source. Albeit this is nothing serious I did a proper patch wich is attaches. You may want to apply it.
Created attachment 48178 [details, diff] Random poolsize overflow patch without hunk As described above
~x86 hardened-dev-sources-2.6.10 patched
rsbac-sources (2.6) patched
hardened-sources-2.4.28-r2 patched in ~x86
We got 2.6.9 and 2.6.8.1 versions of this patch available? I've tweaked the current 2.6 patch for 2.6.9, but 2.6.8.1 is more interesting, in that net/ipv4/netfilter/ip_conntrack_proto_tcp.c is vastly different than what the patch expects.
pegasos-sources fixed
fixed in sparc-sources-2.4.28-r6
gentoo-dev-sources is done
mips-sources patched
rsbac-sources 2.4 is also fixed in ~x86
CAN-2005-0504 is for : Buffer overflow in the MoxaDriverIoctl function for the moxa serial driver (moxa.c) in Linux 2.2.x, 2.4.x, and 2.6.x allows local users to execute arbitrary code via a certain modified length value.
CAN-2005-0179 is for: Linux kernel 2.4.x and 2.6.x allows local users to cause a denial of service (CPU and memory consumption) and bypass RLIM_MEMLOCK limits via the mlockall call. CAN-2005-0180 is for: Multiple integer signedness errors in the sg_scsi_ioctl function in scsi_ioctl.c for Linux 2.6.x allow local users to read or modify kernel memory via negative integers in arguments to the scsi ioctl, which bypass a maximum length check before calling the copy_from_user and copy_to_user functions. The last one has no CVE apparently
Mass-Ccing kern-sec@gentoo.org to make sure Kernel Security guys know about all of these...
kang: Have you patched 2.6? I can't see any reference in the ChangeLog to this bug...
I wrote i patched it: see comment #22 and #29 Since it was fixed before I saw this bug or had any CAN number I didn't wrote any of theses numbers in the ChangeLog. RSBAC is based on rsbacfixed which had latest -as and/or/additional/brad patches (first had brad patches, and since was integrated by rsbacfixed) (Now rsbacfixed has latest 2.6.11.z, I copy changelog from this kernel and bugs/CAN numbers whenever I have them after the patch) Anyway, 0180, 0179, 504 are ok. Ref: http://fixed.rsbac.org/
All fixed then, closing bug.
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commit;h=26eecbf3543b7a57699ce5b0bed82b84d3b61705