VOGONS


First post, by awgamer

User metadata
Rank Oldbie
Rank
Oldbie

https://hackaday.com/2024/03/29/security-aler … or-via-liblzma/

https://news.ycombinator.com/item?id=39865810

Reply 1 of 6, by awgamer

User metadata
Rank Oldbie
Rank
Oldbie

more nfo

Reply 2 of 6, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

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

How To Ask Questions The Smart Way
Make your games work offline

Reply 3 of 6, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 4 of 6, by ovvldc

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 5 of 6, by dr_st

User metadata
Rank l33t
Rank
l33t
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.

https://cloakedthargoid.wordpress.com/ - Random content on hardware, software, games and toys

Reply 6 of 6, by zb10948

User metadata
Rank Newbie
Rank
Newbie

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.