The TF2 subreddit announcement: https://www.reddit.com/r/tf2/comments/g64t0b/data_leak_warni...
The TF2 subreddit announcement: https://www.reddit.com/r/tf2/comments/g64t0b/data_leak_warni...
The original hl2 code leak was a fan from Germany that hacked into Valve's network and stole a version. https://arstechnica.com/gaming/2016/06/what-drove-one-half-l...
There are YouTube channels like VNN that rely on Valve leaks, but most of it seems like running `strings` on their update files. He does claim to have some inside sources, but they mostly seem to provide social commentary on Valve internal politics.
Refer to this r/Games thread for more details: https://reddit.com/r/Games/comments/g61v4x/_/fo6r9ef/?contex...
https://twitter.com/ValveNewsNetwor/status/12529744828321382...
He also re-tweeted this account of the events https://twitter.com/JaycieErysdren/status/125300494000139878...
tl;dr: A Valve employee in 2016 told Tyler about a few things Valve was working on. Tyler kept the chat log and shared it with friends. Unrelatedly, TF2 and CSGO's code was semi-publicly leaked in 2018, and one of the friends found and held onto that. Tyler and the friends worked on a fan project together named F-Stop, after an unreleased Valve project, but then one of the friends had a falling out with the rest of them and published this stuff together, probably to embarrass him for sharing the chat log and maybe to make him look involved in the TF2/CSGO leak.
A little more confirmation: https://twitter.com/TeamFortress/status/1253186403900420098
I’m slightly shocked with the phrasing in that post “It is definitely possible that someone could install a virus on your machine by just being in the same server.”
That.... seems like a pretty shocking security hole, unless they are talking about unknown possibilities, in which case the term “definitely” is a bad choice. If this can be done with the source, it could have been done before, no?
As for uploads, players used to be able to set custom models in quake 2 which were distributed to other players on the server. Though I am not sure if that was done by server admins in special cases for clan payers or members or if there was an actual upload mechanism in the game engine.
Game code is particularly known to be "spaghetti", "code cowoy"-style, where the result is more important than the form or correctness. I mean, that's art, after all, so that seems obvious.
And do you think a lot of companies update their games after they are out? Most often, the code is definitive, refactors are out of the question, etc. I've never seen a bug that fixes a security issue (CVE), let alone for old titles.
And that's when RCE is not by design. It is in Garry's mod, but that's for client-side mode scripted with lua, so theoretically sandboxed. Unreal Tournament 99 though, has plenty of servers that put some dlls for "anti-cheat" software on your computer before you join. That one probably sn't sandboxed.
While we talk about anti-cheat software, can we think a moment about everything that could go wrong with a piece of software that has a very deep access to the system, is sometimes in-house, and not necessarily audited, and whose functionality often includes:
* downloading challenges from servers, patch them into RAM and see what happens
* scan the RAM of the whole system, plus the filesystem, for known exploits
* upload parts of that RAM and filesystem to random servers for analysis
* take screenshots, log keypresses, monitor the system and upload all of this.
Takeaway: sandbox your games. There's a reason I run Steam in a flatpak, on Wayland... Convenience is part of it, but that's not the main one.
If flatpak works perfectly, I suppose an attacker could still steal the "cookie" that automatically logs you into Steam.
Ideally you want Steam to be sandboxed, and then Steam to in turn run all the games in individual sandboxes.
Steam itself has an interesting "Linux runtime" option for games, but it is unclear if that isolates things more than the status quo.
I don't know what I could do, short of replacing every executable in the steam directory with something that uses a mount namespace or a similar restrictive mechanism before launching the actual executable. Inject a modified libc to perform this on steam's exec call? I think the ball is in Valve's camp to improve this.
D:
People put up with that?
And it's not even about trusting that Riot are not bad actors, tencent conspiracy nonsense aside, it's about leaving that trash running with that level of access in a way that some malicious process could use to elevate its permissions. That is the (ab)use case that worries me.
(when a client connects to a battle.net server, one of the early handshake steps is to download a fixed named MPQ file, which is a Blizzard proprietary archive protocol which contains a DLL that is loaded and a certain fixed named function runs from it, which will checksum your client binary and send the result to the server to compare and allow you to progress further)
This analysis is on-point, and something a lot of sources seem to miss. A determined actor can find the exact same exploits with and without access to the source code, though I admit it is much more complicated without ("determined").
- https://hackerone.com/reports/542180
- https://nvd.nist.gov/vuln/detail/CVE-2020-9005
- https://nvd.nist.gov/vuln/detail/CVE-2020-7952
- https://nvd.nist.gov/vuln/detail/CVE-2020-7951