freebsd security - Oct 2018 - [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-18:12.elf

On Mon, Oct 08, 2018 at 12:31:26AM +0200, Dag-Erling Sm?rgrav
wrote:
> Konstantin Belousov <kostikbel at gmail.com> writes:
> > <Lena at lena.kiev.ua> writes:
> >> Program Headers:
> >>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz 
Flg Align
> >>   PHDR           0x000034 0x08048034 0x08048034 0x00100 0x00100 R
E 0x4
> >>   INTERP         0x000134 0x08048134 0x08048134 0x00011 0x00011 R 
0x1
> >>       [Requesting program interpreter: /lib/ld-linux.so.2]
> > As you see, the file delcares that file/memory length of the
interpreter
> > name' segment is 0x11 == 16 decimal. But the string does not end
on
> > byte 16, which is not NUL.  We tighten the checks and do require that
> > PT_INTERP string is valid by checking that it is NUL-terminated at the
> > offset declared by the size.
> 
> The string isn't just unterminated, though.  It's actually longer
than
> the section.  To be precise, "/lib/ld-linux.so.2" is 18
characters long,
> plus NUL makes 19.  The section is supposed to be 17 bytes long.  I
> don't mind forgiving a missing NUL, but I'm not comfortable with
reading
> past the end of the section, and it worries me that Linux doesn't care.
Apparently it was not Linux.  Look at the astro/google-earth/Makefile
before r425359.

Konstantin Belousov <kostikbel at gmail.com>
writes:
> Dag-Erling Sm?rgrav <des at des.no> writes:
> > The string isn't just unterminated, though.  It's actually
longer than
> > the section.  To be precise, "/lib/ld-linux.so.2" is 18
characters long,
> > plus NUL makes 19.  The section is supposed to be 17 bytes long.  I
> > don't mind forgiving a missing NUL, but I'm not comfortable
with reading
> > past the end of the section, and it worries me that Linux doesn't
care.
> Apparently it was not Linux.  Look at the astro/google-earth/Makefile
> before r425359.
Ah, I see.  The port used sed to edit the file in-place instead of using
a tool that understands Elf and would have adjusted the section length.
But it doesn't any more, probably because the linux_base ports install
ld-lsb.so.3, so what's the issue?  And regardless, your patch wouldn't
have helped in this case, since it would only have copied the first 17
characters ("/lib/ld-linux.so.", missing the final 2) to the new
buffer.
So what is the rationale for the patch?

DES
-- 
Dag-Erling Sm?rgrav - des at des.no