Disgruntled bug-hunter drops Steam zero-day to get back at Valve for refusing him a bounty A security bod angry at Valve's handling of bug reports has disclosed a zero-day vulnerability affecting the games giant's flagship Steam app. Russia-based bug-hunter Vasily Kravets said that he was releasing details of the flaw, an elevation-of-privilege hole, after a series of poor interactions with Valve led to him getting …
For reference: https://www.youtube.com/watch?v=X8lLruVR2zQ
Seriously, you're prepared to argue that Valve not paying this bounty is because of MS?
Go on then, "bare facts" me up!
Grin, it's just too easy to get some people excited these days. I need another 111 downvotes to hit the 10k, though, so expect more :).
You probably still use "M$" too.
Nah, that's too easy and boring. Also doesn't quite get any of the antsy reactions.
Don't worry, it wears off. Once I have the downvotes I was after I'll stop poking fun at Microsoft for a while - I want their PR people feel safe first :).
Seems like lately the microsoft pr army has landed at ElReg. They don't know humor, just downvoting and preaching the religion.
Finally someone who gets it, I had almost given up hope. That's all I have been doing - merely offsetting the Microsoft PR army - but some people have (a) no sense of humour and (b) take this as personal affronts which I frankly find hilarious.
That said, I don't actually like to troll that much (I'm more for the occasional good natured prod), but Microsofties appear to be so extraordinarily sensitive that its kinda hard to fight the temptation.
Oh, by the way, please go ahead and downvote. I'm trying to win a bet :).
it takes a hell of a lot to get yourself banned from HackerOne. That implies there's more to this story then is being told. At the very least I have to assume he was extremely abusive to the staff there.
Bug Bounties are always hit and miss for payouts. What one person considers a critical flaw another considers unimportant. Getting abusive for having your claims denied is unacceptable either way. Releasing the code into the wild after having it denied is also a complete d&ck move. It just shows you dont actually care about the security of your fellow netizens, you're just there for the potential payout...
Of course people are in it for the money. Thats not in question. But releasing the code into the Wild doesnt get you paid either, but it DOES put everyone else in danger. So I reiterate its a d&ck move.
It also seems pretty dodgy to me, that he found this bug in Steam AFTER he had already been banned from Steam's Bug Bounty Program. If you've already been told they wont pay you for anything you find, why would you spend time hunting for bugs in their program? the only reason I can come up with is malicious intent.
People are in danger whether he releases it or not. Would you prefer to be in danger and NOT know about, or be in danger with the knowledge that you are in danger? I would at least prefer to know.
You also assume that he looked for the bug AFTER he had been banned. It is a far more likely scenario that he found both bugs at the same time, They are, after all, variants on each other.
Additionally, in a previous post you decried that he was just "into it for the payout" and didn't care about his fellow net citizens. Now, however, you just equated searching for bugs without expectation of payout as "malicious intent".
If hunting for bugs with expectation of payout is bad, and hunting for bugs without expectation of payout is bad, then by your definitions ALL bug hunting is bad.
He tried responsible disclosure first -- they told him that they were not interested and banned him.
People are in danger whether he releases it or not.
I'm not so sure about this particular bug. If someone has physical access to your PC/laptop, then maybe. However, if you walk into where your computer is located and there's a guy wearing a hoodie with a bunch of 1's and 0's floating around him, then yes, you have a real problem.
Or a lan party...
Physical access usually means in this context connected to same switch/subnet/lan, has no need to transit a firewall, or c$ is open and accessable , not physical access is required as the device is air gapped, accessible only through 5 vault doors and 100m under ground
Maybe true, but he wasn’t banned from HackerOne, just from Valve’s part of it. That’s not quite the same thing, and may well have been the result of someone at Valve thinking he was irritating.
Unrelated note, what is it that Valve actually DO these days, other than sitting on a vast pile of money made off of other people’s hard work?
They probably occasionally go swimming in their giant money pool. .... ArrZarr
They always go Deep See Diving for giant grant money pools, ArrZarr.
Titans such as develop and maintain this type of Internetional Security Program ........ Leading AI with JEDI Projects in Overall Remote Command and Total Virtualised Control.
A Veritable King Solomon's Mines of a Bonanza to Value According to Practical Ethereal Worth.
Releasing the code into the wild after having it denied is also a complete d&ck move.
Perhaps, but in context I would disagree.
If I found a bug in your product, report it, and you deny it - what should the next step be?
I see three options for the hunter:
1) Do nothing. Let the bug remain and leave everyone using it still open.
2) Release it to the wild like he did. At least people know now about it.
3) Sell it on the black market making sure that the bad guys know first.
If I release it into the wild then maybe next time someone will listen if I try to report bugs.
After all, if the bug isn't serious enough to be paid for finding it then it follows that releasing it into the wild shouldn't cause any serious problems, right?
Also, if he was only there for the potential payout he would have just sold it on the dark net. The fact that he didn't shows that he DOES care about the users - just not about the company that rejected him.
This. I've been involved in bug bounties for the past 7 years on all sorts of platforms including Bugcrowd and HackerOne. The issue that this researcher ran into is quite common, and you're always left in weird limbo land. It basically goes like this:
a) submit but, and it's classed as 'won't fix' or 'out of scope' or <insert reason>
b) you ask if you can go into public disclosure - because of various NDA's and t's and c's attached to many 'private' programs you can't...
So basically you're sitting on something which is a known vulnerability and impactful but for whatever reason they've decided it isn't an issue, but you can't release it. This is where ethics take hold and everyone has a different opinion.
Personally I've never released vulnerabilities into the wild like this. It also means I know dozens of companies that have vulnerabilities in their products and they know it, and I know it, but that's it. It's now their problem, not mine. Spin that Karmic wheel and watch it goooo!
"Personally I've never released vulnerabilities into the wild like this. It also means I know dozens of companies that have vulnerabilities in their products and they know it, and I know it, but that's it. It's now their problem, not mine. Spin that Karmic wheel and watch it goooo!"
An ethical dilemma? Balancing the risk of loss to possibly millions of people against the legal "fiction" of some likely overly onerous NDA that might not even be a legal document if it's untested in court?
If news about the vulnerability gets released, the company will be forced by customers (who may not "understand" that it doesn't matter) to fix it, but if he just sits on it like Valve wants, the vulnerability remains, and if he discovered it, that means it is discoverable, so eventually someone else will, if they haven't already. Keeping quiet makes sure the people who don't know they are vulnerable remain that way, while speaking out at the very least fixes the "don't know" bit, if not also the "vulnerable" bit.
This is why I usually attach a deadman switch to security vulnerabilities I report.
Being silent is one thing - I'll disclose in this case anyway, but some outfits go nuclear with the gagging attempts - having the details passed to a couple of 3rd parties in other countries with a countdown timer BEFORE notifying the outfit means they can't prevent it happening.
I also work on a policy of giving outfits 2 chances at being cooperative, then I don't bother with notification delays anymore.
Why? Quite simple: I doubt the bad guys don't know about it already - and in the cases where I've tried to go through the "right" paths the bad guys have been observed using the vulnerabilties in the wild before the announcements were released - turning them into zero-day things anyway.
Agreed, and it will take time for scumbag cheap game co to add an exploit which gives Valve time to patch the app.
I tried Steam for one game but gave up on it and bought the game as a download instead. Steam was offline when I wanted to play and I realised it meant I couldn’t play on a plane or in a cafe with an unsecured wifi etc.
After this I think I might uninstall the app if I haven’t already.
No you cannot play offline without an internet connection. I moved to a block of flats which was supposed to have communal wi-fi, but didn't. I had to use the internet from my laptop wherever I could find public wi-fi. A couple of weeks later things on my gaming PC stopped working and told me to get online.
I raised a ticket with Steam and they told me to get lost. They are annoying and useless and I much prefer the days when I used to buy a game on a CD and run it with no further interference. Oh and did I mention all the tedious emails about the security of your steam account and please type in this code. I didn't want a Steam account in the first place, I wanted to play a game.
"Well I've just fired up steam with a disabled network connection and it let me play. I got the option to go into offline mode so take from that what you will."
I think the point is that it works for a while and then slowly breaks. I don't know for sure, as my Internet has not been down long enough to have to test that theory.
Releasing the code into the wild after having it denied is also a complete d&ck move. It just shows you dont actually care about the security of your fellow netizens, you're just there for the potential payout... .... IglethalUnrelated note, what is it that Valve[MS/Apple/Google/Amazon etc etc] actually DO these days, other than sitting on a vast pile of money made off of other people’s hard work? .... tcmonkey
It is popularly known as the American Corporate Way ..... Vaster riches for the few, poisonous scraps for the many.
But it only continues to work wonderfully well if hardly anyone knows. Nowadays though, that silent dreadnought of arrogant convenience is holed catastrophically below the water line long ago. And there aint no lifeboats available to pick up loaded survivors.
It may take a while. For some reason we got a family spotify acct and I download music to annoy the kids in the car. We dont get a phone signal here so my phone is often off. If I forget to turn it on and load spotify in the house so it can call home it refuses to play stuff I've downloaded!
"I received a lot of feedback. But Valve didn’t say a single word, HackerOne sent a huge letter and, mostly, kept silence," Kravets wrote. "Eventually things escalated with Valve and I got banned by them on HackerOne – I can no longer participate in their vulnerability rejection program (the rest of H1 is still available though)."
He's not banned from H1, just the Valve bounty programme.
"Releasing the code into the wild after having it denied is also a complete d&ck move. "
Yes and no. If Valve say it's not a problem, then neither is releasing the code. If the code being in the wild is a problem, then it's a bug Valve should be dealing with as soon as they are notified of it. After all, they don't know if a blackhat is already exploiting it.
it takes a hell of a lot to get yourself banned from HackerOne
Kravets didn't "get ... banned from HackerOne". He got banned from Valve's Response channel on HackerOne. That's a move by Valve, not by HackerOne.
From everything I've seen, this whole saga is about Valve fucking up their response. Everyone who's worked in PSIRT knows that being diplomatic with outside researchers and taking their reports seriously is the critical part of the job. Valve failed.
And, frankly, based on recent disclosures about Steam, I wouldn't trust Valve for a second. PC games nearly always run with elevated privileges; that obligates games vendors to be particularly careful with their software security (though they rarely are). I don't see any sign that Valve is doing well in that area.
"Are you sure that a free game made of garbage by an unknown developer will behave honestly?"
Is it bad that I kinda trust "unknown developers" more than Valve themselves?
I *know* Valve has no respect for my digital freedom and are a bunch of DRM masturbating twits but the "unknown developer" might actually turn out to be nice guys.
I don't know but my guess would be "We built it to DRM all games. It would cost us and involve a lot of testing to make DRM optional on free to play games. There's no obvious revenue stream in the (relatively) tiny number of users who care about DRM on free games."
Just my naive response but seems plausible. Why do you think they do it?
If you need local access to pwn, then you could do just about anything on that PC anyway.
I guess HOW he got access locally may be the question here, did he leverage the Steam client etc? Doesn't sound like it but wierder things have been done via steam chat in the past!
Sure but now you can do it without a UAC prompt. So with this exploit, UAC is now *completely* toothless, rather than only mostly.
Gamers may ask, "why does this random game need root?" It may give an opportunity to notice the exploit. Now there is no such opportunity.
There's still the misconception a system is p0wned with a single, frontal assault. While big, wormable RCE vulnerabilities get all the press, many systems are p0Wned using a stack of vulnerabilities, one after another. You may get limited local access to get a file on a system, and nothing else. But if you can then use another vulnerability to run the file with high privileges, you're utterly p0wned. And here also we are talking about a client that actually downloads files and installs them....
@Halfmad
"I guess HOW he got access locally may be the question here"
One of the arguments hacker put forward was a game having exploit added and made available by Steam, Steams own system would download it (and allow the exploit to be a success).
Steam, by definition, allows stuff to be installed on your machine, and by adding exploit into a game you know that the steam platform is there to exploit that bug.
.. And of course always a drip drip of new exploits to periodically allow you a new nasty way to get a file on someones system
Valve declined to recognize and pay out for the bug, which they said required local access and the ability to drop files on the target machine in order to run and was therefore not really a vulnerability.
Well at least it's not a repeat of the Steam Guard bug that would allow any code to be used.
You say
"they each require the attacker to already have access to the target machine (if that’s the case you’re already in serious trouble, so what’s another flaw)"
If you're a normal user and can run things as an administrator (which is what privilege elevation is) then that's a pretty serious flaw. I'm not sure why you're treating it so cavalierly.
Sadly I think you've misunderstood. To exploit priv esc bugs, you need to already have access to the machine - the ability to write to the filesystem, in one case. At that point, you can do bad stuff anyway, like execute arbitrary code as the user.
To be clear, this is priv esc because you can either go from arbitrary file write to code exec, or user-level code exec to admin code exec if Steam is running as admin. If you already have admin code exec access to the box, this vulnerability is irrelevant.
What we're saying is, it's not as dangerous as an RCE like the RDP bugs. It's not great, it's not terrible.
C.
If you have local system access and file write permissions, you can replace any dynamically loaded library installed with an application with a malware riddled one. This has been one of the top Windows attack vectors for decades. It's about as much a "bug" as saying that you'd also be able to replace steam.exe (or whatever it's called) with a malicious application.
Mess with the Windows folder.
Mess with the MBR.
Mess with the certificate store.
Flash BIOS and device firmware.
Disable the virus scanner.
Disable Windows Update.
Install keyloggers on other accounts.
It's definitely already pretty bad, but it's not necessarily a total loss without a privilege escalation. Without a privilege escalation, the PC may be salvageable. With root, you may as well buy a new computer and restore from backup.
Valve declined to recognize and pay out for the bug, which they said required local access and the ability to drop files on the target machine in order to run and was therefore not really a vulnerability.
I wish Intel felt the same way as Valve.
Crippling CPU's because of a vuln that only exists when in front of the device with adm rights is crazy.
Lies, damned lies and intel shills
"Crippling CPU's because of a vuln that only exists when in front of the device with adm rights is crazy." intel's CPU vulnerability makes it possible to ignore OS security so no need for admin rights.
If as you suggest, intel CPU are secure then why are they spending money trying to fix it ?
"If as you suggest, intel CPU are secure then why are they spending money trying to fix it ?"
Just a guess that the OP was complaining that some of the deep CPU vulnerabilities might not need as much fixing (and the accompanying performance hit) as they've been given. I didn't read it as him saying Intel CPUs are "secure".
It may be over exaggerated for a home PC, but certainly not a business server.
Think of a server running a dozen virtual machines, say in a shared hosting environment. It is possible (but not easy) to set up an malicious platform, and using the bugs "break" into, or steal the credentials from another VM running on the server, that you should have 0 access to.
So yes it is a major flaw that needed fixing
If you have the ability to write to the steam installatio directory (owned by TrustedInstaller), then you alraedy have administrator rights.
If you aren't admin and want to boot into another OS to write your files there, you could also just blank the password of the Administrator account.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
