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

[Paolo Ciarrocchi]

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@xxxxxxxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> - --
> /* *************************************************************** */
>    Marcos Daniel Marado Torres      AKA        Mind Booster Noori
>    http://student.dei.uc.pt/~marado   -          marado@xxxxxxxxxxxxxxxxx
>    () 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@xxxxxxxxxxxxxx>
> To: full-disclosure@xxxxxxxxxxxxxxxx, bugtraq@xxxxxxxxxxxxxxxxx,
>     dailydave@xxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


-- 
Paolo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/