Counter-Strike Global Offsets: reliable remote code execution
secret.club
secret.club
People complain when applications on Mac request permission to access files, but that makes such a huge difference. It’s time for kernel level permissions to be standard on desktops.
If you accept the admin prompt in windows that code can just run anything. In macOS the first time it'll run the code but prompt again if it starts trying to access the core file system.
You may, as a developer, have an expectation some simple app you've downloaded should be able to run in a sandbox quite simply. A random app seemingly unnecessarily trying to access your user/systems files is worth a second thought.
Well, for one thing, to maintain the integrity of online games, protect personal data from the game itself and help prevent theft of in game assets... so I think there’s no strong win here.
Yes it would be good if CS:GO exploits couldn’t reach out and hit your Bitcoin wallet or what have you, but you can’t really just give up entirely either. There’s by-design going to be things the game can access or at least indirectly access that can be sensitive. (At least in the context of online games like CS:GO.)
> People complain when applications on Mac request permission to access files, but that makes such a huge difference. It’s time for kernel level permissions to be standard on desktops.
I agree that improving security is good. However, the way macOS has implemented security has a heavy focus on not trusting the apps themselves and in some cases not even the user. While it is a reasonable principle on some levels, I suspect this mentality actually has more to do with greater control over the ecosystem and the security benefits are a nice bonus. Apple isn’t really alone in this either.
For this particular issue, the issue isn’t with trusting CS:GO itself, it’s with isolating the game so that it doesn’t have more privileges than necessary. That’s actually less difficult of a problem to improve on with less annoying implications. A Linux solution might be shipping an SE Linux profile or Firejail configuration with your app to help lock it down. In this case you still trust the app, and good developers can improve their security easily. No annoying prompts, albeit it would not protect against malicious developers at all.
I still have a lot of mixed feelings because I think concepts like secure boot and principle of least privilege are good ideas. However, they have been met with scorn in their introduction to desktop because traditionally, on desktop platforms, you want to trust the software vendor anyways. The trust boundaries are changing and consolidating trust mostly with the OS vendor and device vendor. I realize this long-held tradition of trusting desktop applications has been crumbling under pressure and less people trust software they depend on than ever. But, I still think that macOS is basically neglecting the demographic that absolutely wants granular and intensive security, but wants more control over how it is enforced and against what. In general, that demographic is being forced into the same pigeonhole as everyone else whether they like it or not, much to the detriment of their ability to hack, repair and otherwise use the device, maybe in ways the vendor objects to. Apple famously believes in a world free of porn. Why should the company that makes my phone be hindering the types of content I can consume on it so stringently?
I am also feeling stronger lately that we’re headed towards less and less sustainable conundrums as the grip tightens. One key insight is that back in the day, you generally trusted software vendors because they mostly had incentive to not betray that trust, and you used websites because you wanted to and not because you felt you had no other options. Even if we make security a priority and drop as many privileges as possible, will that solve the problem? We hate the software we use. Everyone wonders why the web is so slow and disliked; it’s because every time you scroll Twitter spends 100ms blocking the main thread on a modern multicore processor doing god knows what while the browser desperately tries to hide this fact. Even when you don’t scroll enough to cause any virtualized viewport changes. Is it ads, telemetry? Who knows. It’s a mess. Nearly every webapp and probably many mobile apps do things we hate. And they all seem to pull this elaborate bait and switch on users where it’s nice and user friendly and developer friendly until they no longer need your help to thrive.
Users should have ways to run apps they don’t trust that will help protect their security and personal information. Security by default is also a laudable goal, too. But if the future is going to be OSes trying to protect us against apps we hate that hate us that we feel compelled to use due to social pressure, legal requirements or business needs, I think we’re really just headed to a generally dark place.
I’m not saying I don’t understand the legitimate motivations here. It just also is convenient that part of this model of security necessarily takes control away from the user, and it seems like the endgame is that we hate everything and everything hates us. It is possible we’ve run into a situation where a technical solution is simply not enough to untangle the mess. I have no idea what is.
For a long time I was on the side of sympathizing with OS vendors. They were just doing what the security paranoids wanted, right? Well, kind of. But the implications of what it really means for computing feel bleaker every time the subject comes up.
And yet are we safe? The threats just keep adapting. I’m sure at one point many thought “as soon as those pesky buffer overflows are gone, computers will be safe.” It’s good that the security baseline on a technical level keeps improving, but I really think we need to find a way to have healthier relationships between end users, device vendors, and software vendors...
It's not like I can make you read my entire post, but I find it irritating that you went our of your way to let me know that you didn't actually read my post, but still felt compelled to respond anyways.
> but I think ancestor was talking about games being permitted to execute arbitrary code, as opposed to privileged users being able to inject code into a game process…
I never said anything about privileged users being able to inject code into a game process.
I am retorting that the idea that RCE exploits would be OK if we just sandboxed everything is not true. It would improve things, but online games like CS:GO necessarily have access to some things that would be considered sensitive, and thus we still have to care about RCEs.
I went on further to suggest that Apple-style ecosystem control is unnecessary to solve this particular problem. App vendors themselves could opt into various sandboxing measures to limit their own privileges to improve their own security posture. Apple's control protects against untrustworthy applications, and in this case, CS:GO is not an untrusted application.
And then, finally, in around 600 words, I began talking about how I have grown to dislike the walled garden approach because we're building a world where we all hate and distrust all of our software vendors and they hate and distrust their users. Building an ecosystem that is "secure," but that nobody actually likes or wants to partake in.
I appreciated your comment. Maybe saying RCE is “ok” was a bit of a hyperbole, it depends on the game. MMOs people could steal credentials, etc.
SELinux, App Armor, and MAC is what I mean. Windows has mandatory integrity control but it’s no where as comprehensive as Linux, MacOS, iOS.
Windows does have some opt in isolation controls as well like you suggested, but their recently released security features like App Guard is based around virtualization which think won’t work for the average program due to performance and overhead.
And then the games industry starts deploying vulnerability-as-a-service kernel modules in order to bypass all of those controls.
https://mobile.twitter.com/TheWack0lian/status/7793978407622...
On the other hand: how can you spot a cheater who obviously has the cheat at kernel level - with a anticheat software running above that?
- make it easy to report suspected cheaters
- include footage from the cheater, not prerendered but as client state
- create a way for experienced players to judge, from multiple angles, with proper randomization and incentives
- require an id for creating an account. Ban persons not accounts
Don't you need that deeper system integration to achieve that in a way it can't be negated by the cheat?
I think it is ok to be judicious with timeouts, kicks and even bans, so long as you provide a reasonable, accessible and well-scaled dispute mechanism.
That requires a deterministic simulation, and also trusting the clients inputs. Cheats that just send damage/kill messages are stopped by a server just checking "is it possible for X to do Y". Stuff like this is often explainable by unfortunate lag spikes on the "cheaters" side (and most instances of someone rotating 90 degrees and headshotting you in one shot are really just bad networking combined with an edge case in prediction code).
Meanwhile modern cheats are emulating input devices and living as kernel extensions. A game that looks at client inputs is doomed to fail.
> well-scaled dispute mechanism.
The primary issue with dispute mechanisms is social engineering. If you have a cheat forum of 300 people banned, and one figures out what to say to be unbanned, they share the results with others and everyone gets unbanned. A stream of 300 tickets in a game like Fortnite, particularly if they're done in multiple languages and spread across a few days would be unnoticed.
It's a tough problem. I'm not claiming kernel level anticheat is a _good_ thing but it seems to be better than any of the other options available right now.
It used to be a little buggy, but I now have it enabled all the time and don't necessarily feel any performance issue - on a powerful laptop with reasonable usage.
If anyone has more technical information about the feature I'd be very interested to see more about it and what it exactly does - is it really effective or just a lure?
Can't help but feel like this entire class of problem should be avoided with modern tooling. Even in a relatively unsafe language like C++, a static analyzer could have flagged an unchecked array access.
Or is there a weird culture of fear where you’d rather silently try to fix it without acknowledging that it exists, because acknowledging a problem means taking some legal responsibility? It wouldn’t be the first instance of US law having weird effects on human behavior but it does seem a bit far fetched.
That is probably one aspect of it for sure. I think the gaming industry itself might have problems with sharing because 0days in games could really mean no more purchases, at least for awhile, and even then you have lost momentum from your marketing. Also, for non-zero days, just bugs in general, look at No Man's Sky or even more recently Cyberpunk 2077, so much social backlash.
Look, for example, at what happened to Hello Games after the release of No Man's Sky - lots of people felt entitled to send death threats and demands to the developers - the UK authorities were regularly involved in threat assessment[1]. If some LoL players[2] are willing to swat the other team after losing a match then they're quite willing to go extreme lengths if their favorite character gets nerfed.
I think this frequently toxic community interaction really impacts how game development studios interact with press and the public. The folks reporting legitimate bugs might just end up being buried in an avalanche of "BUG: My DPS damage is too low" that overwhelms an already tetchy CS department.
1. https://www.theguardian.com/games/2018/jul/20/no-mans-sky-ne...
2. I'd just like to reinforce that most of the people in a community can be fine - it's the crazies that start a lot of these problems, most folks won't swat you for beating them at LoL.
Customer support is seen as an expense. So automate as much as their job as possible and then... stop paying for customer support.
In general, the bigger the company, the more bureaucracy and layers of indirection you have to get through to reach someone who even knows what you're talking about. This is regardless of whether the message is "bad security bug in your product" or "want to buy a million of your product".
I used to run some of the official servers for CS:GO and L4D2 on behalf of Valve. Mostly it was great but communication was always a challenge.
This behavior was seen before too with the devs behind the new Gmod in Source 2 (Alyx engine). They spent months trying to get in touch with access and it came down to an employee who ended up getting fired for neglecting responsibilities. Now everything seems to be working out and open tooling is being developed.
I had one server bug in HackerOne’s “mediation” for over a month, after 4-6mo of no reply, which did nothing until mentioning it to a Valve employee on another report they had actually responded to.
Disappointing for a program that has paid $1m+ in its lifetime.
Why should they prioritize people who break their hard work and coerce them into paying for protection?
I might be biased; always wanted to work @ Valve Software since HL1.
They've had pre-launch source codes leaked by hackers, gameplay ruined by hackers; they probably don't like hackers.
I wouldn't be surprised if they signed up purely out of spite to tarpit and frustrate hackers.
Valve's stance on hackers won't change the fact they exist and are out there doing their thing. Valve's stance can now be the deciding factor between exploits being disclosed to them for a reward, or sold on black markets as cheats.
If you don't want people "breaking your hard work", don't release software. However, being on hackerone can help alleviate the negatives.
Many of their breadwinners were made by 'hackers'.
Valve are, leaving millions of users at risk, despite having been informed of an issue.
Because they voluntarily joined responsible disclosure programs and promised rewards?
Their hard work wasn't good enough to survive in the extremely hostile world out there. The fact is online gaming is a form of distributed computing and so people are exposed to network attacks. By failing to prioritize security they are putting their customers at risk. They can either start taking this seriously or watch people make money off of the vulnerabilities in their hard work.
They turned me down for any reward - I don't remember the exact wording in their policy but I think it was a generic exclusion of DOS and DDOS vectors. I thought I should've still been eligible as my exploit was simple and only required a low input frequency. The bureaucratic process of the whole thing scared me from doing anything more and I was happy enough that they would fix the vulnerability and I could get back to enjoying the game.
I think it's five years later and the problem still exists, and regularly reduces the quality of my games.
If they don't feel the pain, again and again for things like this then there will never be any impetus to change.
This isn't your responsibility of course. I'm just saying that disclosure at this point would be anything but irresponsible. Maybe not in the middle of a big tournament, I suppose.
I submitted the bug where you I proved you could make predictions about a password in Microsoft just by using ctrl + arrow keys.
It wouldn't have been much anyway but I wouldn't have been surprised if they sent me some swag or something - instead I was surprised about how short the thank you mail was ;-)
(They said it wasn't a security issue but at least it was fixed in the next release :-P)
Edit: I later found a reliable way to run the encryption tools the correct way with the tooling in Azure Information Protection that still leaves the files unencrypted (so simple it can happen by accident, that's how I found it, useful for data exfiltration with plausible deniability) and besides the integration of information protection in Sharepoint is so extremely broken that depending on how you log in, SharePoint will easily serve you the files unprotected.
Between not finding the correct way the report it and the very "meh" feeling on my first find I only tried to report those onve or twice and then gave up.
cs:go at this point is a cheater's game.
because valve's server ain't reliable at all, some people choose to play on third party servers, and not surprisingly a lot of players had the third party client mining bitcoin on their computer [0]. much blame the service, but it's obvious to me it's Valve's responsability.
0: https://www.theverge.com/2013/5/2/4292672/esea-gaming-networ...
Besides, cs started with 3rd party servers and have always been there. Many people have never transitioned to the official matchmaking and I don't think that's necessarily a bad thing.
I just think that your comment is a bit too salty on HN's standards.
3rd party servers are different from 3rd party services.
Valve is not investing their resources in stuff you care about, but they are not objectively wasting their time. They are not just building another online game (which everyone is doing), but innovating in and developing areas that no one else can get away with wasting money on.
I am thankful for all the things you list, some of which have not turned out great, but that is imho just a sign that they are truly doing bold/economically dangerous things, for the good of the medium.
Counterpoint: No, they really don't.
> They are mostly a service provider who happens to own some profitable IP.
They are a staggeringly profitable service provider who occasionally has their employees work on games as a hobby. They just are not a game dev company anymore, and that's okay.
There is one part I’m not clear about. Presumably the vector to exploit this is a malicious server, not a proxy. So if you control the server, why do you need to set two Content-Link headers to trick the parser into thinking it’s empty? Could you use a legit file and a fake content header with extra (empty) bytes? Or does that have too many side effects due to the client actually parsing the file rather than ignoring it?
1. sandboxing - restrict read/write/execute folder/file access at kernel level
2. sandboxing - restrict games to execute arbitrary code, only the game binary itself is allow to be executed
3. anti-cheat software should not be installed at client's computer
4. implement anti cheating from server side instead of relying on client side anti-cheat software
The issue here is that cheat prevention is defense in depth. Drop a couple layers and your cheater rate rapidly rises. Doesn't take much from there to a dead game.
Sup Gaben?
If you want to learn from the best, and it has to be youtube, go watch Gynvael's channel.
> in over 4 months, we did not even receive an acknowledgment by a Valve representative. After public pressure, when it became apparent that Valve had also ignored other Security Researchers with similar impact, Valve finally fixed numerous security issues
Also, can we all agree "DD/MM/YYYY" is the worst possible date format?
YYYY-MM-DD is ideal, of course, due to easy sorting and no ambiguity over the order of MM and DD, but I’d take DD/MM/YYYY over MM/DD/YYYY any day.
I could make similarly silly arguments in favour of dd/mm/yy - if you're writing it down on a paper list and dates aren't yet final, it's easier to cross out the first item as you'll have space in the margins to put in the new value rather than the middle item, and for that kind of short term projections, the day is more likely to change.
The real reason we find a system preferable is just familiarity, no matter what post-facto justifications people try bringing up.
> Is it?
Yes, I'll stand by this one. Imagine it's January 1st, and I ask you to "pack for a camping trip some day in July this year" vs "…on the 10th of some month this year." While technically the latter narrows it to fewer days, the former is much more actionable because there's a lot less variability.
In my mind, it's similar to putting the main point up front when you're writing an email, and then clarifying, instead of giving all the context and working up to the request. The latter feels logical, like you're telling a story, but the former is so much easier to follow, because you don't have to re-interpret the context when you get to the punch line.
Here's a quick example: "I can't wait until you can come try it out. Such a smooth ride, tons of acceleration, and great handling. You're going to love riding my new tricycle." From a literary standpoint, it's a nice subversion of expectations, which makes it more likely to stick in your mind. But from a functional perspective — that is, communicate the ideas in an efficient, reliable, boring way — this would be much more effective, "I can't wait until you can come try out my new tricycle. Such a smooth ride, tons of acceleration, and great handling. You're going to love riding it!"
Back to dates. If you asked me, "Are you free on July 10th?" I would assume you mean the current year. When you ask, "Are you free on July 10th, 2025?" I do same thing, then hear the year and have to forget that and start over.
The real thing to optimize for is useful information up front. Can I start drawing conclusions as soon as you start giving information, or do I need to wait until the end? The programming equivalent is something like short-circuiting conditionals. I personally know I won't be able to take vacation in July this year, so I don't need to pay attention to the date once I've heard the month; but if the date came first, then I'd have to remember it in case the month turned out to be June, September, etc.
It's not a lot of overhead, and the date usually comes all at once in a row so it's not a very big difference either way, but I do think there's an objective difference.
> The real reason we find a system preferable is just familiarity
I grew up with mm/dd/yyyy. It's the most familiar/comfortable and, due to practice, the easiest for me to parse. I still think yyyy-mm-dd is better, for the same reasons as above (and because it's an international standard, and I like standards).
No, we cannot. Both DD/MM/YYYY and YYYY/MM/DD are consistent and usable (the latter preferred by developers because of its natural sortability).
The one format we can all agree is the worst possible is MM/DD/YYYY.
No, we can't. That format is properly ordered, unlike MM/DD/YYYY which makes absolutely no sense.