CS:GO: From Zero to 0-Day
neodyme.io
neodyme.io
However, sometimes programmers forget to remove the debug symbols from the final binaries of the game. Programmers are humans, and humans make mistakes.
Executables/libraries on disk file size will increase with debug symbols. The kernel and loader will look at binary headers and load only what is needed for execution into main-memory. Kernel and loader will not load the debug symbols at runtime, they are useless for them. The debugger will look also at the headers and use them to load the debug symbols, which are need for backtraces. Therefore initial file read from disk will take a little more time but the execution is not affected. Startup speed is usually influenced by loading of further resources, initialization and checks. So you will get a lot for some bytes on the disk.
https://stackoverflow.com/questions/24117063/is-a-program-co...
https://stackoverflow.com/questions/39222698/does-compiling-....
Some people still argue that security by obscurity works and hide everything. I doubt that.
The sentence before the one you quote is
> Sometimes versions of the game are also intentionally shipped with debug symbols to generate better error reports.
You remove that context, quote him saying sometimes it's a mistake and criticise him with the preface he already provided!?
When someone makes a statement and that statement is innaccurate or untrue, it is helpful to correct it so that they can change their post/future-posts to ensure they are making the strongest argument/most compelling narrative possible. Sometimes this is misused or misunderstood to be combative, but it is not constructive to approach conversation this way.
Would people stop using this site if it stopped offering dopamine hits in the form of a number next to your name?
> Sometimes versions of the game are also intentionally shipped with debug symbols to generate better error reports. However, sometimes programmers forget to remove the debug symbols from the final binaries of the game. Programmers are humans, and humans make mistakes.
It looks like the author is saying shipping final binaries with debug symbols is a mistake, and that's what @ho_schi is criticising.
The author did not say that "shipping with debug symbols is always a mistake", they noted that it can happen unintentionally and provided evidence of that in this case.
As pointed out by jpmoral, I consider debug symbols generally a good thing. Exceptions apply as usual e.g. embedded computing.
Another approach is using stuff like debuginfod to ship debug symbols automatically when needed. Archlinux and Fedora do that and it improved debugging and reporting - especially regarding dependencies.
There are ways to convert symbol names on the crash report server, so the claim that you can get better crash report with debug symbols is not correct.
Why you shouldn’t release debug symbols:
* It helps patent/copyright trolls litigate you easier.
* Makes it easier to reverse engineer your binaries, which will help malicious actors and competitors.
* You might lose some trade secrets.
If you are a startup owner, please ensure to never release commercial/close-source binaries with debug symbols. You can thank me later.
Most things involving security also use and greatly care about obscurity of implementation. The principle is that the security should not "rely solely" on obscurity, not that obscurity has no benefits.
Usually, making software such that one can have a high confidence of it being secure is not economical. One relies on being harder to break than the competition, for which obscurity can be a big deal, and on offloading or mitigating damage when flaws are inevitably exploited anyway.
It's engineering after all, isn't it?
Yes, it is a mistake. None of those things require symbols on the customer’s machine.
It is certainly true for games. There are only very expensive cheats for eg R6S and Overwatch 2, and the encryption of those games is a headache.
In any case, this is an online video game, if you want to have a billion cheaters, feel free to ship debug data (for no reason) with the binary.
I mean, it's not quite MW2 (2009), which I believe has multiple known RCEs that'll never be patched. But still not good enough for an actively developed live service game. One hopes that Source 2 has better standards for it, but I'll believe it when I see it.
It seems like Activision does not allocate any development time to their older games, even if critical vulnerabilities are found. Black Ops 3 (2015) has a number of remote code execution vulnerabilities in its peer-to-peer networking code, making it completely unsafe to play - even though it is readily available on Steam. Of course, these exploits are fixed by the community in custom, modded, clients. Sadly Activision likes to send cease & desist letters to developers of these clients.
Personally I’ve found an exploit in CoD4 (2007) that will leak the CD-key of a person joining your server. This was reported to Activision in 2009 (ish), but also never (officially) fixed. It uses similar CVar leaking concepts as the one discussed in this article. Probably that would also make for an interesting write-up.
[1] https://web.archive.org/web/20080517095348/http://www.securi...
Edit: a raspberri pi that filters out bad packets from old games
Not just actively developed, but the most popular game on Steam by far, with ongoing revenue of around $50 million per month (peaking at >$100mil recently).
https://www.dexerto.com/csgo/players-reportedly-spent-100-mi...
They especially have no excuse for not pouring resources into security.
What it would actually mean for Valve if they allowed that to happen is hard to say, since they're in such a firmly entrenched position with a near-monopoly on PC game distribution, but every CS:GO player getting cryptolocker'd wouldn't be good for their brand to say the least.
How about an FTC complaint for unfair and deceptive business practices?
This seems like a great case.
Given the drawn out timescales for getting critical bugs fixed, working on security is seen as boring or low value by Valve devs. Due to compensation being tied to stack ranking system, people are dissuaded from fixing these bugs as a result.
Can you tell me more about these RCEs, how they work, or some technical analysis on this game?
Connecting to these services safely is absolutely something players should have trust in.
A feature provided by all well designed client/server software. Thus avoiding vendor lock-in and dependence. Good for LAN-Parties, bad or no networking, original developer doesn’t exist anymore or doesn’t care.
And then there as these developers which are the only ones with the server code and shutdown their servers by intention - I recommend to avoid software which such a planned obsolescence.
(Also, why aren't you supposed to use other servers?)
Security is not a priority. Priorities are performance and getting the thing out the door under constant crunch time with minimal cost and likely nobody hired specifically to handle this kind of security.
Performance usually means shortcuts everywhere, a mentality to avoid anything unnecessary in normal operation (like checks that values are within an expected range), and memory-unsafe languages.
Add various anti-cheats and you'll probably get an almost free escalation straight to the kernel too.
Also, lots of complexity, and often built-in scripting languages.
Edit: In this specific case, it was a series in logic bugs, in code that would generally not be considered super-sensitive and thus receive additional attention for a security review. To write secure software, every developer needs to be security aware, and a game company isn't the environment where you can expect that to happen.
Most of these online multiplayer games are implemented with heaps of unsafe c++, and due to the nature of the game, are constantly parsing inputs from the network, and from other clients. This is a recipe for disaster!
For this reason I will only run modern games in some sort of sandbox, ideally in a VM with GPU pass through, or maybe run them on a dedicated system that is only used for games.
Even in a VM, exploiting it would give access to the passed in GPU, and from there I'm not totally sure what is possible, so even this isn't perfect but it's quite a lot better than nothing.
Normally people are launching the game through the steam GUI under their regular uid, so CS:GO for example with this setup, can read and write to all of the data in ${HOME}. That's pretty scary!
Even running steam through flatpak doesn't give you much protection when sharing the X11 socket.
I think the most reasonable setup for the "average user" is to create a separate user account on their system that is dedicated to gaming. You can run graphical sessions for both users at the same time and switch between them via whatever method (i would just switch between multiple ttys). Users on Unix-like systems in theory should not be able to interfere with other users, or even harm the system so long as they can't escalate to root. It's important to realize that there are situations where an unpriv'd user can harm the system, like if there is a bug with sudo, or a kernel exploit! I think it's much better than the default though!
I agree it took them too long to fix these vulnerabilities but Valve is notorious for its schedules/timeline/insane delays. It's been a meme for years now.
There appears to be a lack of proactivity in addressing these bugs. Given Valve's substantial daily earnings from CS:GO through weapon skin sales, it seems their operational focus is more on maintaining the revenue stream rather than committing to quality engineering practices.
Not to mention the potential of "what if the anti-cheat is deliberately programmed to be malicious?". A dismal state all around.
I've for a long time kept my gaming PC in physically separate network. While I've relaxed that for practical reasons, can't imagine ever logging into anything I can't trivially burn or recover into a gaming machine.
Still anecdotal, I know, but it seems to be a rather small issue.
> Today, I purchased and installed Dead by Daylight with the intention of playing with some friends, only to start the game and find a message from Easy Anti-Cheat stating that the game "cannot run under a virtual machine."
[1] https://www.reddit.com/r/VFIO/comments/100yqok/bypass_eac_ca...
[2] https://www.reddit.com/r/blackdesertonline/comments/px0flc/v...
Looking at how big the impact could be if this was discovered elsewhere, and how meager the payout was and how little Valve seemed to be interested, I guess it's fair to say that security of millions of PC clients is not taken seriously at all. If this is how it's handled for a game that makes big $$, I wouldn't dare imagine how it is for thousands of online AA games and other low budget software that runs everyday in our computers.
Nowadays I'd be more concerned about malicious mods for singleplayer titles.
https://github.com/perilouswithadollarsign/cstrike15_src
The engine code is very old, and CS:GO itself was not developed by valve but by Hidden Path Entertainment initially as a port of CS: Source to consoles and they didn't really do a great job.
right from the get go, the authors made it clear that each of the rce requires a user to connect to a malicious server. the only scenario this is possible is if the user connects to one of the community servers.
while community servers have been the backbone of previous cs titles, it is far from the main place the majority of players connect to to play the game. the only major exception being third-party matchmaking systems such as faceit and esea, where the connection is handled directly by each service.
so the scope of exploit in the vast majority of the cases would be for a very minor set of playerbase or unless exploiters hack faceit/esea servers.
at the same time, the community servers have had a shady relationship with valve, where some of them allow you to try any skin in the game from server-side. i believe things like that played a part in why valve did not bother much with supporting them with the current game, especially with the ui for connecting to them barely updated since cs 1.6 two decades ago.
moreover, the exploits listed are not by themselves enough to inject a payload to victims's computer. the game itself runs in user mode and the client-sided commands are usually game specific.
overall, while i support the efforts made, the potential impact have been overblown in interpretation. i can see why valve took so long to fix these.
That sounds quite bad.
https://github.com/sr2echa/CSGO-Source-Code/blob/dafb3cafa88...
https://github.com/sr2echa/CSGO-Source-Code/blob/dafb3cafa88...
How many high value targets are installing games on their machines with sensitive data, and connecting to random private servers? Hopefully not enough to justify developing an exploit like this.
https://www.kaspersky.co.uk/blog/cs-go-two-million-usd-inven...
Too many people are happy buying shoes that explode, taking their feet away, if the shoe laces are tied on the wrong order.
Also, competitive games, especially shooters, are extremely sensitive to latency, so they are by their nature quite unfit for streaming. People who build PCs which render at 300 FPS to a 120Hz+ monitor for competitive play won't be happy to deal with even a quite optimistic 10ms additional roundtrip latency.