more nfo

As far as dosbox is concerned you are likely looking at a dependency not by dosbox code or dosbox main dependencies but by mingw or other system level dependency that those applications depend on that link to that library assuming we are talking about the version of dosbox from sourceforge and not other versions. I haven't checked anything this is just me responding off the cuff since I've never seen liblzma as far as compiling dosbox is concerned, although the Linux community and it's dynamic linking stance has always been a concern both compatibility and security wise. (Not saying static isn't a concern either)

So if such then it's likely not a dosbox issue but a higher up the chain issue and the thread should be renamed.

As far as the vulnerability it's important to know what the vulnerability is, what versions of the dependency are affected and how an application would potentially be affected by it before having a panic attack.

As far as for the future Linux distros need to work on a XDR solution just like Microsoft has done if they don't want Defender XDR on their Linux systems. It's been proven time and again that just being Linux doesn't make it magically secure but I imagine situations like these if they increase will only further incentivize making the PC a dumb terminal for the Cloud and locking the Cloud down further.

/EDIT https://gist.github.com/thesamesam/223949d5a0 … ce9ee78baad9e27

Safe to file this as FUD as far as DOSBox is concerned. liblzma is not a direct dependency, and analysis has shown that the backdoor is targetted at sshd:

In the malicious code, the library checks argv[0], which is the name of the program being executed, for /usr/bin/sshd. Additionally it seems to check for debugging tools like rr and gdb. If the checks are green, liblzma replaces a few function calls with its own code. It’s a complicated dance, but the exploit is specifically looking to replace RSA_public_decrypt.

That backdoor was prepared so slowly and deliberately that I would be surprised if there were not others lurking in xz or another piece of widely used open source software. But that is a worry for another day.

jmarsh wrote on 2024-03-31, 03:43:

Safe to file this as FUD as far as DOSBox is concerned. liblzma is not a direct dependency, and analysis has shown that the backdoor is targetted at sshd:

In the malicious code, the library checks argv[0], which is the name of the program being executed, for /usr/bin/sshd. Additionally it seems to check for debugging tools like rr and gdb. If the checks are green, liblzma replaces a few function calls with its own code. It’s a complicated dance, but the exploit is specifically looking to replace RSA_public_decrypt.

Nice.

In Soviet Russia, backdoor is potentially affected by Dosbox.

The problem with CVE in sshd is that sshd runs on root account and shellcode was executed in that context. This can't happen with Dosbox.

Just to drop a note, FreeBSD has completely opposite development dogma (cathedral vs bazzar sort of a thing). Xz is in the base system, thus unaffected - it was imported several versions ago when migrating from bzip2 to xz, the code is treated like operating system code.

Also it's a good thing to lock out everything running sketchy proprietary code behind a separate user account. Dosbox usually isn't an exploitation vector but isn't thoroughly tested either when it comes to breakout exploits. I haven't been running Dosbox under different user account, but Steam yes, and all the Linuxlator gaming stuff on FreeBSD.