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

[Theo de Raadt]

Alexander Bluhm  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

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

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 
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:
.
Find the GDB manual and other documentation resources online at:
.
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  0x in ?? ()


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