Yuzu: R/W Memory sections in executable. [SECURITY VULN]

[Alex-Aralis]

Ref: e9bfe05e04f4a83cadb2cc036689921defb4e342
System: Gentoo Linux

Because libressl's asm files don't include .note.GNU-stack they are creating writable and executable mem sections. I could fix this with patches but should be fixed upstream. How to fix https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart
List of offenders:
!WX --- --- ./work/yuzu-9999_build/externals/libressl/crypto/CMakeFiles/crypto.dir/whrlpool/wp-elf-x86_64.S.o
!WX --- --- ./work/yuzu-9999_build/externals/libressl/crypto/CMakeFiles/crypto.dir/cpuid-elf-x86_64.S.o
!WX --- --- ./work/yuzu-9999_build/externals/libressl/crypto/CMakeFiles/crypto.dir/aes/bsaes-elf-x86_64.S.o
!WX --- --- ./work/yuzu-9999_build/externals/libressl/crypto/CMakeFiles/crypto.dir/aes/aesni-elf-x86_64.S.o
!WX --- --- ./work/yuzu-9999_build/externals/libressl/crypto/CMakeFiles/crypto.dir/aes/aes-elf-x86_64.S.o
!WX --- --- ./work/yuzu-9999_build/externals/libressl/crypto/CMakeFiles/crypto.dir/aes/aesni-sha1-elf-x86_64.S.o
!WX --- --- ./work/yuzu-9999_build/externals/libressl/crypto/CMakeFiles/crypto.dir/aes/vpaes-elf-x86_64.S.o
!WX --- --- ./work/yuzu-9999_build/externals/libressl/crypto/CMakeFiles/crypto.dir/rc4/rc4-elf-x86_64.S.o
!WX --- --- ./work/yuzu-9999_build/externals/libressl/crypto/CMakeFiles/crypto.dir/rc4/rc4-md5-elf-x86_64.S.o
!WX --- --- ./work/yuzu-9999_build/externals/libressl/crypto/CMakeFiles/crypto.dir/modes/ghash-elf-x86_64.S.o
!WX --- --- ./work/yuzu-9999_build/externals/libressl/crypto/CMakeFiles/crypto.dir/camellia/cmll-elf-x86_64.S.o
!WX --- --- ./work/yuzu-9999_build/externals/libressl/crypto/CMakeFiles/crypto.dir/bn/modexp512-elf-x86_64.S.o
!WX --- --- ./work/yuzu-9999_build/externals/libressl/crypto/CMakeFiles/crypto.dir/bn/gf2m-elf-x86_64.S.o
!WX --- --- ./work/yuzu-9999_build/externals/libressl/crypto/CMakeFiles/crypto.dir/bn/mont5-elf-x86_64.S.o
!WX --- --- ./work/yuzu-9999_build/externals/libressl/crypto/CMakeFiles/crypto.dir/bn/mont-elf-x86_64.S.o
!WX --- --- ./work/yuzu-9999_build/externals/libressl/crypto/CMakeFiles/crypto.dir/sha/sha512-elf-x86_64.S.o
!WX --- --- ./work/yuzu-9999_build/externals/libressl/crypto/CMakeFiles/crypto.dir/sha/sha1-elf-x86_64.S.o
!WX --- --- ./work/yuzu-9999_build/externals/libressl/crypto/CMakeFiles/crypto.dir/sha/sha256-elf-x86_64.S.o
!WX --- --- ./work/yuzu-9999_build/externals/libressl/crypto/CMakeFiles/crypto.dir/md5/md5-elf-x86_64.S.o

I'm aware that this issue is coming from a submodule, and have informed the Citra team on their discord about the issue, but they pointed the finger over here for filing the ticket. Wanted to make sure that this was documented somewhere.

[SciresM]

"Security vuln"...you do realize yuzu is an emulator, which executes JIT'd arm64 code, right?

Presumably if some user has compromised the process they can just use jit stuff to execute arbitrary code -- W^X isn't meaningful here?

[Alex-Aralis]

In theory Yuzu could be viewed as a sandbox, for instance Yuzu has no facility for games to reach out to the internet, or read files from the use's documents folder. However if a ROM can climb out of the emulated sandbox it can perform any action that the process owner could, (in the case of an insecure system maybe even root privileges). I understand that security is not this projects primary goal, but this is still an issue worth considering and documenting at the least.

[ogniK5377]

As with the previous comment, it's quite literally jitting arm64. You can execute whatever code you like with just that alone. There is always a situation where a user can be put at risk for most emulators running user applications. Just like regular applications, only get homebrew from trusted sources and know what you run

[goldenx86]

Almost as if running VM was never a security risk.

[FearlessTobi]

As you said, the issue is caused by a submodule used in various other projects and not by yuzu.
I'd suggest opening a ticket in the libressl issue tracker.
Furthermore, if someone really wanted to exploit yuzu, there would be way easier options as pointed out by other SciresM for example.
In practice, users should only execute games they trust and dumped from their own Switch system.