linux-kernel - Re: Segmentation fault on all golang executables

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 12 Jun 2014 10:20:38 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Kui Zhang <kuizhang@...il.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...ux.intel.com>
Subject: Re: Segmentation fault on all golang executables

On Thu, Jun 12, 2014 at 9:59 AM, Kui Zhang <kuizhang@...il.com> wrote:
> Hello,
>
> This commit seem to cause Segmentation fault on any of my golang executables.

Well, crap.  It looks like the Go people took my sample vDSO parser...
and broke it.  WTF were they thinking?  I should have noticed that
they screwed it up when I was cc'd on this thing:

https://code.google.com/p/go/source/detail?r=56ea40aac72b

but I didn't.  Sorry, everyone.  And the issue isn't even something
sensibly broken like trying to find vdso symbols in the symbol table.
No, they're using the size of the SHT_DYNSYM section to deduce the
number of entries *in the dynamic table*.  This is just completely
wrong.

But even that's not all.  They borrowed by error handling, so they
should have silently failed to parse the vdso instead of crashing.
But then they broke it completely by failing to zero the state, so
they're just reading from initialized memory.  Grr.

The current offending code is here:

https://code.google.com/p/go/source/browse/src/pkg/runtime/vdso_linux_amd64.c

Since we don't get to break all Go executables, here are two options:

1. Try to keep the whole symbol table intact.  This is annoying:
there's a reason I removed it.  The linker script doesn't know how big
it is, so it's hard to make it compatible with the vvar table.

2. Write a dummy section table that contains a single empty section of
type SHT_DYNSYM.  Hopefully the Go runtime will then get far enough to
fail cleanly.  And they can go and write a real ELF parser or copy my
reference parser correctly.  (hpa, can you apply my patches to make
the reference parser 32-bit clean?)

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