[HN Gopher] Arbitrary code execution in Unity Runtime
___________________________________________________________________
Arbitrary code execution in Unity Runtime
Author : andygmb
Score : 74 points
Date : 2025-10-03 13:21 UTC (9 hours ago)
(HTM) web link (flatt.tech)
(TXT) w3m dump (flatt.tech)
| philipwhiuk wrote:
| 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?
| sidewndr46 wrote:
| how does one cut corners on Valgrind? It's a free tool from
| what I understand.
| Sohcahtoa82 wrote:
| I interpreted the comment as meaning cutting corners by _not
| using_ Valgrind.
| sidewndr46 wrote:
| That at least makes slightly more sense, thanks.
| kelsey98765431 wrote:
| by not using it.
| jfyi wrote:
| 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.
| Sohcahtoa82 wrote:
| 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.
| somat wrote:
| 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.
| whizzter wrote:
| 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.
| mzajc wrote:
| > 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.
| Karliss wrote:
| The biggest impact is for Android. The official advisory from
| Unity https://unity.com/security/sept-2025-01 lists that for
| desktop platforms it's more of privilege escalation instead of
| code execution.
|
| On windows if the game has been registered as custom URL scheme
| handler it opens ways for triggering it without ability to pass
| custom CLI arguments.
|
| On macOS as part of application signing macOS apps also contain
| permission manifest. So in theory if a user runs a malicious
| app (which for some reason is properly signed but with limited
| permissions) it could leverage a vulnerable game to run in the
| context of slightly more permissions but still as the same
| user.
|
| On Linux in most cases anyone able to pass cli arguments could
| also run code directly with same privileges. I guess if the
| game executable was marked as setuid. That seems unlikely.
| p_ing wrote:
| 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.
| jagged-chisel wrote:
| 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.
| pjmlp wrote:
| 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.
| krapp wrote:
| I'll just leave this here: https://godotengine.org/
| flowerthoughts wrote:
| 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?
| ActionHank wrote:
| 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.
| zktruth wrote:
| "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.
| somat wrote:
| > "practically every CVE is on code you can read."
|
| This is probably true due to a sort of survivorship bias.
| code you can read is much easier to analyze and test and
| report. Closed source internal code has a lot of security
| by obscurity built into it. Not to dismiss security by
| obscurity, I am sure it keeps an absolute frightening
| amount of code safe.
| jfyi wrote:
| 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.
| zulban wrote:
| 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.
| singron wrote:
| 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.
| ge96 wrote:
| Ah so that email was legit
| bootsmann wrote:
| I got it like 4 times, they really really wanted to us to be
| aware.
| rbranson wrote:
| 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.
| wilg wrote:
| 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?
___________________________________________________________________
(page generated 2025-10-03 23:00 UTC)