Live data from Hacker News

Counter-Strike Global Offsets: reliable remote code execution

secret.club

31–40 of 94 posts

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

#31
post #27
post #26

Earlier quoted context omitted.

I like Valve's approach. Who is the real bad guy here? 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.

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.

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

#32

Burying the lead here! > 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?

I’m ready for us all to standardize on the DATEINT format.

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

#33

Burying the lead here! > 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?

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.

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

#34

Burying the lead here! > 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?

> Also, can we all agree "DD/MM/YYYY" is the worst possible date format?

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.

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

#35
post #26

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?

I like Valve's approach. Who is the real bad guy here? 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.

> I like Valve's approach. Who is the real bad guy here?

Valve are, leaving millions of users at risk, despite having been informed of an issue.

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

#36

Burying the lead here! > 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?

I read the whole article to find out how Valve responded and it was EXACTLY what I expected. They've done this before and they'll do it again. Toxic

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

#37

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

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

#38
post #3

How can people contact big corporations and get no response? Are the messages not being read? 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.

For Valve at least my experience is that’s pretty common. With the way they structure their company everyone works on what they want to. The result is that nobody chooses to work on the boring stuff so it doesn’t happen.

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.

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

#39

Another example is why app level security is so important. Why shouldn’t games allow arbitrary code execution? It only matters because the access space for programs is still so broad. 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.

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

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

#40
post #31
post #27

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.

That is such a bizzare take.

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.

Post reply on HN