> This vulnerability allows malicious intents to control command line arguments passed to Unity applications, enabling attackers to load arbitrary shared libraries (.so files) and execute malicious code, depending on the platform.
Aren't intents an Android-only thing? I'm not sure adding "depending on the platform" makes sense when the exploit only works on a single platform.
This seems pretty bad from the headline but there's no evidence of any in-the-wild exploits or if there is a feasible real-world exploit here. Some other domino(s) have to fall before it allows RCE. For instance, browser-based exploits are blocked by SELinux restrictions on dlopen from the downloads path.
Interesting that Windows is impacted, but on Windows you can simply drop a dx9 dll or sameNameAsExecutable.dll to "inject" code. Commonly used by modders for Unity and other games. From that perspective, I don't see how this is novel or so highly rated, again on Windows specifically.
The URI handler is a separate vector that is more concerning.
How hard is it for a remote attacker to replace a DLL on your Windows system? And how hard for the remote attacker to gain access via this exploit through Unity?
With physical access, anything goes - like when you replace DLLs on your own system for modding … or changing permissions to gain access to files … or any number of “unauthorized” activities because you are physically located at the machine.
Yeah, at first, I was like...Okay, so the victim needs to install a malicious app which means they already have code execution. This is just a permissions escalation? I suppose that can be bad if the target Unity app has some wide permissions.
But if it can be exploited via Browser, then it means any website with an XSS vulnerability becomes an attack vector. But the attack needs to specify which app to start. So even if you found a great app that uses Unity and has juicy permissions, you'd have to hope your victims have that specific app installed. I'm not sure you could try to launch multiple apps without tipping off the user that the website is trying to do something funky.
Sure it's a game engine, they are not exactly praised for their security. but my understanding is for games the end user has a mental modal where the engine isolates the users computer from the game content (the levels, art and game logic) I am not sure how relevant this mental model is to unity. Where unity is more of a game engine framework and the engine proper and the game code are more or less intertwined within that.
The gold example is the original quake where the engine had an application specific vm to run the game code. Again, not security focused and I am fairly sure vm escapes would be easy to find. But I also don't remember ever hearing news how a quake mod installed a rootkit on someones pc.
I'd say that most lines of business cuts as many or even more corners until they grow large or have other security interests, gamedevs are fairly prideful of their work in comparison to many other industries.
In this case however I'm gathering that this is an engine level issue, in general Unity hasn't been a huge target since most game-code is run under C# (even if people might resort to unsafe for some things) and has basic memory safety from the language. It's a bad oversight in this case though.
The relevance is bypassing the android application sandboxing of the game by other apps and running arbitrary code as the game. I suppose the relevance depends a lot on how much you are invested in your video game.
I don't understand the threat model of this for most Unity games on PC, it doesn't seem like there's anything you could do by running arbitrary code inside the Unity player that you couldn't already run on your PC directly or access via the process's memory, etc?
Well the code base is surely orders of magnitude smaller (there are several legacy ui systems, network systems, etc in unity) which means far fewer security problems. And while we can debate the advantages of open source, in my opinion the development model is obviously more secure compared to closed proprietary.
Godot has a known issue where the built in deserialization can lead to arbitrary code execution. E.g. a save file could be modified to execute any script when it's deserialized.
A quick look shows not much has been found CVE wise with godot, and not anything on the 4.x version of the engine. There is an interesting case of it being used to build a malware loader.
I've actually been playing with it a bit recently and have had a couple mysterious crashes in their ide. It's likely ripe fruit for a curious security researcher.
It's opensource, so people would likely have caught this issue.
It's opensource, so they can't just make some foolish, arbitrary licensing change to extort money from customers.
It's opensource, so it is going to be a better engine in the long run.
Unity had a niche, their greedy execs killed that and Godot is one of the beneficiaries of that.
> This vulnerability allows malicious intents to control command line arguments passed to Unity applications, enabling attackers to load arbitrary shared libraries (.so files) and execute malicious code, depending on the platform.
Aren't intents an Android-only thing? I'm not sure adding "depending on the platform" makes sense when the exploit only works on a single platform.
This seems pretty bad from the headline but there's no evidence of any in-the-wild exploits or if there is a feasible real-world exploit here. Some other domino(s) have to fall before it allows RCE. For instance, browser-based exploits are blocked by SELinux restrictions on dlopen from the downloads path.
Interesting that Windows is impacted, but on Windows you can simply drop a dx9 dll or sameNameAsExecutable.dll to "inject" code. Commonly used by modders for Unity and other games. From that perspective, I don't see how this is novel or so highly rated, again on Windows specifically.
The URI handler is a separate vector that is more concerning.
Which is why since Windows 11 version 24H2, Windows started getting some additional sandboxing capabilities in Win32, similar to how UWP works.
https://learn.microsoft.com/en-us/windows/security/applicati...
Currently it is still opt-in, but who knows when they decide to go Apple style with Gatekeeper.
How hard is it for a remote attacker to replace a DLL on your Windows system? And how hard for the remote attacker to gain access via this exploit through Unity?
With physical access, anything goes - like when you replace DLLs on your own system for modding … or changing permissions to gain access to files … or any number of “unauthorized” activities because you are physically located at the machine.
This is somewhat unsurprising - gaming software will doubtless cut corners on security-adjacent tooling (valgrind, etc) in order to ship faster.
It's also somewhat irrelevant unless there's a remote chain.
The Android Browser idea is interesting but is this actually a likely scenario?
Yeah, at first, I was like...Okay, so the victim needs to install a malicious app which means they already have code execution. This is just a permissions escalation? I suppose that can be bad if the target Unity app has some wide permissions.
But if it can be exploited via Browser, then it means any website with an XSS vulnerability becomes an attack vector. But the attack needs to specify which app to start. So even if you found a great app that uses Unity and has juicy permissions, you'd have to hope your victims have that specific app installed. I'm not sure you could try to launch multiple apps without tipping off the user that the website is trying to do something funky.
Sure it's a game engine, they are not exactly praised for their security. but my understanding is for games the end user has a mental modal where the engine isolates the users computer from the game content (the levels, art and game logic) I am not sure how relevant this mental model is to unity. Where unity is more of a game engine framework and the engine proper and the game code are more or less intertwined within that.
The gold example is the original quake where the engine had an application specific vm to run the game code. Again, not security focused and I am fairly sure vm escapes would be easy to find. But I also don't remember ever hearing news how a quake mod installed a rootkit on someones pc.
I'd say that most lines of business cuts as many or even more corners until they grow large or have other security interests, gamedevs are fairly prideful of their work in comparison to many other industries.
In this case however I'm gathering that this is an engine level issue, in general Unity hasn't been a huge target since most game-code is run under C# (even if people might resort to unsafe for some things) and has basic memory safety from the language. It's a bad oversight in this case though.
The relevance is bypassing the android application sandboxing of the game by other apps and running arbitrary code as the game. I suppose the relevance depends a lot on how much you are invested in your video game.
how does one cut corners on Valgrind? It's a free tool from what I understand.
I interpreted the comment as meaning cutting corners by not using Valgrind.
That at least makes slightly more sense, thanks.
by not using it.
I don't understand the threat model of this for most Unity games on PC, it doesn't seem like there's anything you could do by running arbitrary code inside the Unity player that you couldn't already run on your PC directly or access via the process's memory, etc?
Ah so that email was legit
I got it like 4 times, they really really wanted to us to be aware.
I'll just leave this here: https://godotengine.org/
Is it known to be free from arbitrary code execution vulns? Or is it known to also contain ACEs? What's the relevance to the post?
Well the code base is surely orders of magnitude smaller (there are several legacy ui systems, network systems, etc in unity) which means far fewer security problems. And while we can debate the advantages of open source, in my opinion the development model is obviously more secure compared to closed proprietary.
Godot has a known issue where the built in deserialization can lead to arbitrary code execution. E.g. a save file could be modified to execute any script when it's deserialized.
A quick look shows not much has been found CVE wise with godot, and not anything on the 4.x version of the engine. There is an interesting case of it being used to build a malware loader.
I've actually been playing with it a bit recently and have had a couple mysterious crashes in their ide. It's likely ripe fruit for a curious security researcher.
It's opensource, so people would likely have caught this issue. It's opensource, so they can't just make some foolish, arbitrary licensing change to extort money from customers. It's opensource, so it is going to be a better engine in the long run.
Unity had a niche, their greedy execs killed that and Godot is one of the beneficiaries of that.
"It's opensource, so people would likely have caught this issue." Lol, practically every CVE is on code you can read.
"It's opensource, so it is going to be a better engine in the long run." Citation needed.