Live data from Hacker News

Counter-Strike Global Offsets: reliable remote code execution

secret.club

71–80 of 94 posts

Re: Counter-Strike Global Offsets: reliable remote code execution

#71
post #33

Earlier quoted context omitted.

MM/DD/YYYY is clearly worse. Not only is it only used in a tiny number of places, making it more likely to cause confusion, but it doesn’t go consistently from smaller unit to bigger unit or vice-versa. 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.

+1 on ISO 8601, but MM/DD/YYYY does have a certain logic to it. The month essentially tells you what time of year it is. "Want to go on vacation in July 10th?" carries less mental overhead than "..on the 10th of July", unless it's currently July (ie, you just say "..on the 10th"). Because "in July" is more meaningful than "on the 10th of any random month".

Is it? Either we're asking to pick a date (in which case it's just "in July" or "mid July" or "in a couple of months"), or you're asking about a specific date which works for you, in which case both components are equally important.

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.

Re: Counter-Strike Global Offsets: reliable remote code execution

#72
post #33

Earlier quoted context omitted.

MM/DD/YYYY is clearly worse. Not only is it only used in a tiny number of places, making it more likely to cause confusion, but it doesn’t go consistently from smaller unit to bigger unit or vice-versa. 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.

+1 on ISO 8601, but MM/DD/YYYY does have a certain logic to it. The month essentially tells you what time of year it is. "Want to go on vacation in July 10th?" carries less mental overhead than "..on the 10th of July", unless it's currently July (ie, you just say "..on the 10th"). Because "in July" is more meaningful than "on the 10th of any random month".

I suspect that's at least partly because it's what you're used to. "July 10th" makes me pause for a second, as I think you're suggesting 'sometime in July', then you add a specific date to it.

Re: Counter-Strike Global Offsets: reliable remote code execution

#73
post #70

Earlier quoted context omitted.

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?

By realizing that a purely technical solution is not enough. - 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

"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?

Re: Counter-Strike Global Offsets: reliable remote code execution

#74
post #52

Earlier quoted context omitted.

> It’s time for kernel level permissions to be standard on desktops. 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...

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?

Re: Counter-Strike Global Offsets: reliable remote code execution

#75
post #52

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?

Because, really, the cheaters are just that bad.

Re: Counter-Strike Global Offsets: reliable remote code execution

#77

Earlier quoted context omitted.

This is a bit selfish view. I loved their controller, I love steam link allowing me to seamlessly play from any room (with whatever controller I want). I use Linux and think that vr is something everyone should try at some point. I know that you maybe couldn't care less about these things, but don't exacerbate the argument by saying "nobody". Besides, cs started with 3rd party servers and have always been there. Many…

Good for you mate that you enjoyed all that. I'm just pointing out they do a poor job on cs security and anti-cheat and communication in contrast to other efforts on the company like these, and it's cs who made steam possible, not that other stuff. 3rd party servers are different from 3rd party services.

I think it's great they take a server side approach to anticheating. More intrusive methods of other vendors reliably need andministrative access to the useres system and theres no way I allow anything game-related to run with root privileges. CS:GO is one of the best games in the market in this regard. The cs playerbase regularly complains about the opponents cheating when its much more likely that the other player is just much better.

Re: Counter-Strike Global Offsets: reliable remote code execution

#78
post #75

Earlier quoted context omitted.

Yeah and it sucks. Why does the games industry think it can own our machines for the sake of some ineffective anticheating solution?

Because, really, the cheaters are just that bad.

There are other viable options for dealing with cheaters, such as (but not limited to) community servers with robust moderation controls and modding capabilities to let them experiment with bespoke solutions out of band with the developer's release cycles.

Re: Counter-Strike Global Offsets: reliable remote code execution

#79
post #70

Earlier quoted context omitted.

By realizing that a purely technical solution is not enough. - 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

"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.

Re: Counter-Strike Global Offsets: reliable remote code execution

#80

Valve should be kicked off HackerOne. They seem to abusing the service to trick researchers into submitting vulnerabilities without providing any sort of compensation. Does anyone here work at HackerOne?

My experience with valve on HackerOne was when I discovered an easy way to lag, and if exploited crash, a dota 2 server. It was nothing technically fancy, but something that made it easy for griefers to ruin the game for everyone. I think even spectators to the match could trigger the functionality. They turned me down for any reward - I don't remember the exact wording in their policy but I think it was a generic ex…

At some point it is more responsible to make the exploit public and spark public pressure for a fix, than to let Valve ignore exploits while each day is a roll of the dice on a bad actor discovering them.

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.

Post reply on HN