devel/monotone i386 breakage, maybe following libc++ update?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

devel/monotone i386 breakage, maybe following libc++ update?

Stuart Henderson
devel/monotone now fails to build on i386. During the build it runs
its own-built "mtn" binary to produce manpages, which fails (segfaults),
fails to produce the manpage file, so packaging fails, making the problem
noticable.

It uses C++ and the failure started after the libc++ update. Seems
repeatable.

Reply | Threaded
Open this post in threaded view
|

botan i386 segfault [was Re: devel/monotone i386 breakage, maybe following libc++ update?]

Stuart Henderson
On 2019/06/20 16:59, Stuart Henderson wrote:
> devel/monotone now fails to build on i386. During the build it runs
> its own-built "mtn" binary to produce manpages, which fails (segfaults),
> fails to produce the manpage file, so packaging fails, making the problem
> noticable.
>
> It uses C++ and the failure started after the libc++ update. Seems
> repeatable.
>

This appears to be a problem with botan, the segfault in the devel/monotone
build is in botan code:

$ egdb ./fake-i386/usr/local/bin/mtn
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd6.5".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./fake-i386/usr/local/bin/mtn...done.
(gdb) set args manpage
(gdb) r
Starting program: /usr/obj/ports/monotone-1.1/fake-i386/usr/local/bin/mtn manpage

Program received signal SIGSEGV, Segmentation fault.
0x082eefff in botan_sha160_x86_32_compress () from /usr/local/lib/libbotan-1.10.so.1.1
(gdb) bt
#0  0x082eefff in botan_sha160_x86_32_compress () from /usr/local/lib/libbotan-1.10.so.1.1
#1  0x00000000 in ?? ()


And I see the same stack trace in botan's own regression tests.

Reply | Threaded
Open this post in threaded view
|

Re: botan i386 segfault [was Re: devel/monotone i386 breakage, maybe following libc++ update?]

Alexander Bluhm
On Thu, Jun 27, 2019 at 10:08:37PM +0100, Stuart Henderson wrote:
> #0  0x082eefff in botan_sha160_x86_32_compress () from /usr/local/lib/libbotan-1.10.so.1.1

This code is at a page boundary, so it traps into the kernel.  There
it is detected that the esp register is currently not on the stack.

The hand written assembler code in src/hash/sha1_x86_32/sha1_x86_32_imp.S
uses esp as a regular register.  Its content is safed at the beginning
of the function and restored at the end.  If there is a trap due
to a page boundary, the kernel stack guard kicks in and aborts the
process.

Botan-1 is end of life.  Perhaps we should just replace the i386
assembler implementation with the regular C code.

bluhm

Reply | Threaded
Open this post in threaded view
|

Re: botan i386 segfault [was Re: devel/monotone i386 breakage, maybe following libc++ update?]

Theo de Raadt-2
Alexander Bluhm <[hidden email]> wrote:

> On Thu, Jun 27, 2019 at 10:08:37PM +0100, Stuart Henderson wrote:
> > #0  0x082eefff in botan_sha160_x86_32_compress () from /usr/local/lib/libbotan-1.10.so.1.1
>
> This code is at a page boundary, so it traps into the kernel.  There
> it is detected that the esp register is currently not on the stack.
>
> The hand written assembler code in src/hash/sha1_x86_32/sha1_x86_32_imp.S
> uses esp as a regular register.  Its content is safed at the beginning
> of the function and restored at the end.  If there is a trap due
> to a page boundary, the kernel stack guard kicks in and aborts the
> process.
>
> Botan-1 is end of life.  Perhaps we should just replace the i386
> assembler implementation with the regular C code.

Someone over-optimized without considering the consequences.  Having
such instruction code on a unaligned-instruction architecture is just
too ripe for ROP gadget exploitation.  I hope that .S code dies.

Not going to delete the opportunistic ROP-pivot prevention mechanism....