This is the second time (we know of) BeamNG.drive being exploited due to bad security practices - the first time, disabling ASLR [0], leading to Disney being hacked, this time, disabling CEF sandboxing. It is weird to see them go out of their way to disable conventional security features on their product.
I'd imagine by the time your program's security is critically reliant on ASLR and process-level sandboxing, you're already in deep trouble, since any given minor update may turn existing holes into viable exploits. It will only slow down the rate of attacks at best.
The lesson I'd take here is "don't embed a web browser to run untrusted code unless you can keep it up to date 24/7". Hence the popularity of Lua interfaces for mods. Or even the alternative JS engines built for such purposes.
ortichic · 2h ago
I had forced ASLR on in windows for a while... You'd be surprised how much stuff breaks with that. Almost feels like more is broken than not. Just to name a few: MinGW (including git for windows), Unity, Whatever installer Framework Signal and some others use, some Anti-Cheats
pixl97 · 6h ago
>It is weird to see them go out of their way to disable conventional security features on their product
Honestly with most developers I know, unless they also have a strong security background, it's not weird or surprising at all. Security features (almost?) never make debugging easier. When confronted with a failure that presents challenges devs will disable things that limit access or otherwise randomize the output in order to catch the problem and then 'hopefully' come tighten it back up when they are done. Unfortunately the second part rarely happens unless you have security auditors follow you around.
pjmlp · 22m ago
That is why then there are folks like me, complaining in code reviews, or adding configurations into the CI/CD pipeline.
However it is indeed a quixotic battle in some scenarios, regarding security best practices.
pjmlp · 25m ago
One could be using the safest programming language in the world, if the culture doesn't get the point, it doesn't matter how safe it can be.
abhisek · 2h ago
Still trying to understand - Did the mod developers intentionally shipped malicious code or they were compromised by some external attacker to target the downstream users?
throwaway314155 · 1h ago
The author indicates that the mod authors' account was "likely compromised" indicating a bad actor took over their account somehow, perhaps made easier by prolonged inactivity?
I don't think the author of this piece found it useful to speculate though and I have to agree. No need to break out pitch forks - let those involved get to the bottom of it.
everdrive · 6h ago
But did the malware do anything significant through proton to the host OS?
TZubiri · 2h ago
Unrelated, on mobile, background is quickly oscilating colours giving an epileptic vibe
fifteen1506 · 6h ago
I hate malware. I found two Android apps using an obfuscator loaded via JNI (libjiagu_64.so) which crashes on startup (on GrapheneOS) and I am at a loss at what to do next which doesn't involve send reports into the void hoping it reaches an human with the time, skills and willingness to check what is really going on.
[0]: https://news.ycombinator.com/item?id=41063489
The lesson I'd take here is "don't embed a web browser to run untrusted code unless you can keep it up to date 24/7". Hence the popularity of Lua interfaces for mods. Or even the alternative JS engines built for such purposes.
Honestly with most developers I know, unless they also have a strong security background, it's not weird or surprising at all. Security features (almost?) never make debugging easier. When confronted with a failure that presents challenges devs will disable things that limit access or otherwise randomize the output in order to catch the problem and then 'hopefully' come tighten it back up when they are done. Unfortunately the second part rarely happens unless you have security auditors follow you around.
However it is indeed a quixotic battle in some scenarios, regarding security best practices.
I don't think the author of this piece found it useful to speculate though and I have to agree. No need to break out pitch forks - let those involved get to the bottom of it.
Summary: https://user934.com/2025/04/29/investigating-suspicious-beha...