search

DNSCrypt / dnscrypt-proxy

dnscrypt-proxy 2 - A flexible DNS proxy, with support for encrypted DNS protocols.
https://dnscrypt.info
ISC License
11.13k stars 995 forks source link

FreeBSD 13 memory mapping policy allow_wx=0 causes crash #1730

Closed richnetdesign closed 2 years ago

richnetdesign commented 3 years ago

I'm using FreeBSD 13 on a network appliance, with dnscrypt-proxy installed. A new security feature in FreeBSD 13 is "W^X memory mapping policy for user processes". In other words "disallow pages to be executable and writable".

To enable the mitigation sysctl kern.elf64.allow_wx=0

So I wanted to try it out, and most of my programs worked. However, the app crashes exec_new_vmspace: mapping stack size 0x20000000 prot 0x7 failed mach error 2 errno 13 Abort trap

Output of the following commands:

./dnscrypt-proxy -version 2.0.45

./dnscrypt-proxy -check

What is affected by this bug?

Crashes on start

When does this occur?

When starting dnscrypt-proxy it crashes with exec_new_vmspace: mapping stack size 0x20000000 prot 0x7 failed mach error 2 errno 13 Abort trap

Changing the sysctl back restores functionality.

Where does it happen?

FreeBSD 13

Expected behavior (i.e. solution)

Normal functionality

Other Comments

I can help investigate this. Wanted to put it out there and get feedback first. While this is a new feature in FreeBSD, I believe OpenBSD has had it for awhile so perhaps something to reference.

References

https://ximalas.info/2021/04/15/freebsd-13-and-wx-memory-mapping-policy-for-user-processes/

jedisct1 commented 3 years ago

Looks like +wxneeded needs to be set on programs written in Go: https://forums.freebsd.org/threads/rclone-not-working-with-w-x.80279/

jedisct1 commented 3 years ago

I don't think there's much that can be done by applications themselves. This needs to be fixed in Go.

richnetdesign commented 3 years ago

That rclone thread is very helpful. I'll be sure to search freebsd forums in the future. Now to track down if Go has this on there roadmap.

Seems like there might be 2 seperate issues.

  1. Go / compile toolchain issue is causing elf to be missing header. This prevents elfctl from configure binary to deviate from global W^X config.
  2. Executables compiled with Go crash immediately if W^X enabled.
igalic commented 2 years ago

given that this is a Go runtime issue, I've opened a ticket in Go: https://github.com/golang/go/issues/48112

jedisct1 commented 2 years ago

Awesome, thank you!

richnetdesign commented 2 years ago

I forgot about this. Thanks everybody it seems to be getting fixed upstream in Go, so perhaps I can set allow_wx=0 on my network appliance again soon.