lkml.org 
[lkml]   [2018]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 05/10] x86/cet: ELF header parsing of Control Flow Enforcement
From
Date
On Thu, 2018-06-07 at 11:38 -0700, Andy Lutomirski wrote:
> On Thu, Jun 7, 2018 at 7:41 AM Yu-cheng Yu <yu-cheng.yu@intel.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.

I will fix these problems. Thanks!

\
 
 \ /
  Last update: 2018-06-07 22:44    [W:0.071 / U:0.800 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site