81–90 of 94 posts
Earlier quoted context omitted.
Because that's what they signed up for?
See it from Valve's perspective. 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.
Many of their breadwinners were made by 'hackers'.
after reading the comments, I think the takeaways for games are 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.
Earlier quoted context omitted.
That ship has long sailed. All the major anti cheat systems do this now, and have done for years.
And still cheaters plague most public servers of the games I played. 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?
Earlier quoted context omitted.
That ship has long sailed. All the major anti cheat systems do this now, and have done for years.
Yeah and it sucks. Why does the games industry think it can own our machines for the sake of some ineffective anticheating solution?
Earlier quoted context omitted.
"include footage from the cheater, not prerendered but as client state" Don't you need that deeper system integration to achieve that in a way it can't be negated by the cheat?
You can record (clientside and server side) the inputs from multiple players and play them back deterministically; if the suspected cheater's ones don't line up with how the game played out for the majority of the server then that's a pretty clear smoking gun. 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.
Earlier quoted context omitted.
> Why shouldn’t games allow arbitrary code execution? 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 goi…
TLDR, 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…
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.
Earlier quoted context omitted.
TLDR, 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…
> TLDR, 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 u…
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.
Sup Gaben?