linux-kernel - Re: [PATCH 05/10] x86/cet: ELF header parsing of Control Flow Enforcement

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 7 Jun 2018 11:38:02 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Yu-cheng Yu <yu-cheng.yu@...el.com>
Cc:     LKML <linux-kernel@...r.kernel.org>, linux-doc@...r.kernel.org,
        Linux-MM <linux-mm@...ck.org>,
        linux-arch <linux-arch@...r.kernel.org>, X86 ML <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. J. Lu" <hjl.tools@...il.com>,
        "Shanbhogue, Vedvyas" <vedvyas.shanbhogue@...el.com>,
        "Ravi V. Shankar" <ravi.v.shankar@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Jonathan Corbet <corbet@....net>,
        Oleg Nesterov <oleg@...hat.com>, Arnd Bergmann <arnd@...db.de>,
        mike.kravetz@...cle.com
Subject: Re: [PATCH 05/10] x86/cet: ELF header parsing of Control Flow Enforcement

On Thu, Jun 7, 2018 at 7:41 AM Yu-cheng Yu <yu-cheng.yu@...el.com> wrote:
>
> Look in .note.gnu.property of an ELF file and check if shadow stack needs
> to be enabled for the task.

Nice!  But please structure it so it's one function that parses out
all the ELF notes and some other code (a table or a switch statement)
that handles them.  We will probably want to add more kernel-parsed
ELF notes some day, so let's structure the code to make it easier.

> +static int find_cet(u8 *buf, u32 size, u32 align, int *shstk, int *ibt)
> +{
> +       unsigned long start = (unsigned long)buf;
> +       struct elf_note *note = (struct elf_note *)buf;
> +
> +       *shstk = 0;
> +       *ibt = 0;
> +
> +       /*
> +        * Go through the x86_note_gnu_property array pointed by
> +        * buf and look for shadow stack and indirect branch
> +        * tracking features.
> +        * The GNU_PROPERTY_X86_FEATURE_1_AND entry contains only
> +        * one u32 as data.  Do not go beyond buf_size.
> +        */
> +
> +       while ((unsigned long) (note + 1) - start < size) {
> +               /* Find the NT_GNU_PROPERTY_TYPE_0 note. */
> +               if (note->n_namesz == 4 &&
> +                   note->n_type == NT_GNU_PROPERTY_TYPE_0 &&
> +                   memcmp(note + 1, "GNU", 4) == 0) {
> +                       u8 *ptr, *ptr_end;
> +
> +                       /* Check for invalid property. */
> +                       if (note->n_descsz < 8 ||
> +                          (note->n_descsz % align) != 0)
> +                               return 0;
> +
> +                       /* Start and end of property array. */
> +                       ptr = (u8 *)(note + 1) + 4;
> +                       ptr_end = ptr + note->n_descsz;

Exploitable bug here?  You haven't checked that ptr is in bounds or
that ptr + ptr_end is in bounds (or that ptr_end > ptr, for that
matter).

> +
> +                       while (1) {
> +                               u32 type = *(u32 *)ptr;
> +                               u32 datasz = *(u32 *)(ptr + 4);
> +
> +                               ptr += 8;
> +                               if ((ptr + datasz) > ptr_end)
> +                                       break;
> +
> +                               if (type == GNU_PROPERTY_X86_FEATURE_1_AND &&
> +                                   datasz == 4) {
> +                                       u32 p = *(u32 *)ptr;
> +
> +                                       if (p & GNU_PROPERTY_X86_FEATURE_1_SHSTK)
> +                                               *shstk = 1;
> +                                       if (p & GNU_PROPERTY_X86_FEATURE_1_IBT)
> +                                               *ibt = 1;
> +                                       return 1;
> +                               }
> +                       }
> +               }
> +
> +               /*
> +                * Note sections like .note.ABI-tag and .note.gnu.build-id
> +                * are aligned to 4 bytes in 64-bit ELF objects.
> +                */
> +               note = (void *)note + ELF_NOTE_NEXT_OFFSET(note, align);

A malicious value here will probably just break out of the while
statement, but it's still scary.

> +       }
> +
> +       return 0;
> +}
> +
> +static int check_pt_note_segment(struct file *file,
> +                                unsigned long note_size, loff_t *pos,
> +                                u32 align, int *shstk, int *ibt)
> +{
> +       int retval;
> +       char *note_buf;
> +
> +       /*
> +        * Try to read in the whole PT_NOTE segment.
> +        */
> +       note_buf = kmalloc(note_size, GFP_KERNEL);

kmalloc() with fully user-controlled, unchecked size is not a good idea.