Re: grsecurity 2.1.0 release / 5 Linux kernel advisories (fwd)

Paolo Ciarrocchi
2005-01-07T21:08:15Z

Andrew, Linus,
the below email seems to be very intersting.

Any comment ?

On Fri, 7 Jan 2005 19:54:43 +0000 (WET), Marcos D. Marado Torres
<marado@student.dei.uc.pt> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> - --
> /* *************************************************************** */
> Marcos Daniel Marado Torres AKA Mind Booster Noori
> http://student.dei.uc.pt/~marado - marado@student.dei.uc.pt
> () Join the ASCII ribbon campaign against html email, Microsoft
> /\ attachments and Software patents. They endanger the World.
> Sign a petition against patents: http://petition.eurolinux.org
> /* *************************************************************** */
>
> - ---------- Forwarded message ----------
> Date: Fri, 7 Jan 2005 13:18:53 -0500
> From: Brad Spengler <spender@grsecurity.net>
> To: full-disclosure@lists.netsys.com, bugtraq@securityfocus.com,
> dailydave@lists.immunitysec.com
> Subject: grsecurity 2.1.0 release / 5 Linux kernel advisories
>
> Let's try this again, since web archives don't like multipart
> attachments.
>
> 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.
>
> 7) Attachments
>
> expoits_and_patches.tgz can be downloaded at:
> http://grsecurity.net/~spender/exploits_and_patches.tgz
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> Comment: Made with pgp4pine 1.76
>
> iD8DBQFB3ukImNlq8m+oD34RAlwFAJ9IpoQRMmdhsPjdJlH8Mxct3yGZTwCeOuaD
> n855Y0P+FCBVUSaEDl17hmo=
> =6g/V
> -----END PGP SIGNATURE-----
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

--
Paolo