Question about binfmt_elf.c

Question about binfmt_elf.c

[Rob Landley]

Could somebody please update this comment to explain why fiddling with 
strangely protected bss is _not_ an easy way to leak arbitrary amounts of 
uninitalized kernel memory (with whatever previous contents they have) to 
userspace?

    nbyte = ELF_PAGEOFFSET(elf_bss);
    if (nbyte) {
            nbyte = ELF_MIN_ALIGN - nbyte;
            if (nbyte > elf_brk - elf_bss)
                        nbyte = elf_brk - elf_bss;
            if (clear_user((void __user *)elf_bss +
                                    load_bias, nbyte)) {
                    /*
                     * This bss-zeroing can fail if the ELF
                     * file specifies odd protections. So
                     * we don't check the return value
                      */
            }
    }

Just curious.  Reading through the code and trying to understand it...

Rob
-- 
GPLv3: as worthy a successor as The Phantom Meanace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.

Re: Question about binfmt_elf.c

[Andrew Morton]

On Fri, 16 Jul 2010 15:12:39 -0500
Rob Landley <rob@landley.net> wrote:

> Could somebody please update this comment to explain why fiddling with 
> strangely protected bss is _not_ an easy way to leak arbitrary amounts of 
> uninitalized kernel memory (with whatever previous contents they have) to 
> userspace?
> 
>     nbyte = ELF_PAGEOFFSET(elf_bss);
>     if (nbyte) {
>             nbyte = ELF_MIN_ALIGN - nbyte;
>             if (nbyte > elf_brk - elf_bss)
>                         nbyte = elf_brk - elf_bss;
>             if (clear_user((void __user *)elf_bss +
>                                     load_bias, nbyte)) {
>                     /*
>                      * This bss-zeroing can fail if the ELF
>                      * file specifies odd protections. So
>                      * we don't check the return value
>                       */
>             }
>     }
> 
> Just curious.  Reading through the code and trying to understand it...
> 

In January 2005 davem added a check.  In Feb 2005 Pavel said "hey, my
Kylix application broke".  So we took the check out again.

http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg60120.html
http://www.mail-archive.com/bk-commits-head@vger.kernel.org/msg01390.html

I don't kow how one would craft such an elf file.  I don't _think_ it
could leak unintialised memory, as we probably haven't faulted the page
in yet.  Perhaps a partial page could be exposed though.

Roland, Jakub: help!

Re: Question about binfmt_elf.c

[Roland McGrath]

> On Fri, 16 Jul 2010 15:12:39 -0500
> Rob Landley <rob@landley.net> wrote:
> 
> > Could somebody please update this comment to explain why fiddling with 
> > strangely protected bss is _not_ an easy way to leak arbitrary amounts of 
> > uninitalized kernel memory (with whatever previous contents they have) to 
> > userspace?

I can't tell why you would ever think that was possible.  There is no
kernel memory involved, uninitialized or otherwise.  All the memory in
the user address space is "initialized", being either zero pages or
file-mapped pages.  The only thing that happens when bogus ELF headers
prevent us from clearing some bss is that a partial page of file data
is visible in user memory rather than being all zero.

> In January 2005 davem added a check.  In Feb 2005 Pavel said "hey, my
> Kylix application broke".  So we took the check out again.
> 
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg60120.html
> http://www.mail-archive.com/bk-commits-head@vger.kernel.org/msg01390.html

Note there are other places that call padzero() and do check its
result.  So we're only ignoring the error for one particular kind of
bss, which is not even done in normal layouts at all (with the right
p_flags or not).  Usually, there is only bss in the last segment, which
is the path that uses padzero().  This code path without the error
check is only used for a segment that both has bss (p_memsz > p_filesz)
and is followed by some other PT_LOAD segment.

> I don't kow how one would craft such an elf file.  

  $ cat badbss.lds
  SECTIONS {
	  . = SIZEOF_HEADERS;
	  .text : { *(.text*) } :re
	  .bss : { *(.bss*) } :re
	  . = ALIGN(0x1000);
	  .data : { *(.data*) } :rw
  }

  PHDRS {
	  re PT_LOAD FLAGS(5) FILEHDR PHDRS;
	  rw PT_LOAD FLAGS(6);
  }
  $ gcc -m32 -static -nostdlib -nostartfiles -o badbss -xc <(echo 'char use_bss[0x234], use_data[0x345]={1,}; _start(){}') -Wl,badbss.lds
  $ eu-readelf -l badbss
  Program Headers:
    Type           Offset   VirtAddr   PhysAddr   FileSiz  MemSiz   Flg Align
    LOAD           0x000000 0x08048000 0x08048000 0x00009d 0x001634 R E 0x1000
    LOAD           0x0000a0 0x080490a0 0x080490a0 0x000345 0x000345 RW  0x1000

   Section to Segment mapping:
    Segment Sections...
     00      [RO: .note.gnu.build-id .text .data .bss]
     01      [RO: .data]

To the loader, "bss" means p_memsz > p_filesz, as you see there in the
first LOAD segment.  And it's not writable.


Thanks,
Roland