Steam Windows Client Local Privilege Escalation 0day
amonitoring.ru
amonitoring.ru
This seems pretty scammy of HackerOne and does nothing but hurt security. Either something is an issue and should be paid for, or it's not an issue and disclosure is fine. They're trying to have it both ways and trying to strong arm researchers into keeping quiet.
It used to be that even accepted bugs and paid bounties would be publically disclosed. It helped me learn a ton just from reading the (partially redacted) bug reports. Over time they became more and more redacted until they were left entirely pointless.
To mark a bug as N/A, declare it 'not fix' but then say also it can't be disclosed is precisely why responsible disclosure is a thing. Companies can't have their cake and eat it.
https://blogs.technet.microsoft.com/ecostrat/2010/07/22/coor...
All we want is a place to host a bug bounty page and allow us to pay rewards through it. The only reason I'd prefer hosting that on a platform rather than just making a bug bounty page on our own site is that I feel bounty hunters would trust it more, since it's not just some random page on a company website they've never heard of before.
The difference is that you pay her either way. HackerOne doesn't. If HackerOne wants the advantages of paid employees then they need to pay for employees and not mask it as a bug bounty program.
If it’s not a real vulnerability then why would it matter if she publicised it?
Or, is it actually a real vulnerability but you don’t want to admit it because she (the security consultant) is getting paid per vulnerability found?
Unless the company is lying and it IS a real vulnerability, writing an article about it seems harmless to me.
OFC that if I planned on writing an article I'd be open about it beforehand, but that feels like a courtesy and not an obligation unless an NDA is involved.
Disclaimer: I don't work in security so this is purely curiosity.
Like OP wrote in this thread, it either is a vulnerability or it's not. In the latter case, just assume it's the cost of doing business and people will write "bad" things about your product?
> Please note that we will not consent to disclose reports if they have been marked out-of-scope or inapplicable, or where Valve has not taken a specific corrective action / mitigation.
> Valve embraces transparency in our security. We will generally disclose the details of vulnerabilities found, upon request.
It is possible to get a "security bug" that is technically a security bug, but still isn't really all that important. But you generally want to be very careful in making that assessment, because just because one particular person, even someone fairly skilled in security, doesn't think it can be used to do anything truly harmful doesn't mean that the attackers won't figure something out.
XSS has been a particular rich source of this; it's very easy for someone not too up on security to say "Oh, whoopdedo, it lets you pop up an alert box or change the client side display", when in fact XSS can steal login cookies if you haven't properly secured them (which seems likely to correlate highly with people who don't think XSS is a big problem) and be used to proxy web connections to other resources in the context of the user, conforming to the same-origin policy [1]. So, for instance, with the recent story about a guy finding an XSS in Tesla's service management page, they were correct to respond to that as a serious issue; it wasn't just a way of moderately inconveniencing a service tech, it was a back door into their entire service system, potentially. XSS has a huge mismatch between the general developer's impression of its severity and its actual severity.
The XSS was in the screenshot viewer. Names of Source Mods were not escaped. Their fix was to never show Source Mod names on Steam Community at all.
- The "Exclusions" are very poorly defined:
Valve will have the right to determine CVSS classification, report validity, duplications, exclusions and out-of-scope bugs in its sole discretion.
- What's "In Scope" is extremely vague. Yes, it's a list of domains, however Steam uses way more domains than that. Even then, not everything is tied to a "domain" as such, for instance Steam provides P2P networking. Executables are indeed mentioned, but again, it's vague.
- Payouts seem low.
The HackerOne profile is something I would expect of (and would be acceptable for) a 10 person company, not a massive corporation with millions of users.
As it happens, there are only about 10 people [1] working on Steam. [2][3] This is the result of both Valve having only some hundreds of employees total and them being to be able to choose what they want to work on. Not many choose Steam.
--
[1] This is not counting customer support staff that is outsourced.
[2] Steam employees self-report the team size as 10 in this interview https://www.youtube.com/watch?v=atwE-K8y-ws&t=8m35s
[3] Someone who recently visited Valve observed this to still be true. "There are approximately ten people inside" + "This is the Steam cabal," https://www.joindota.com/en/news/84521-my-visit-at-valves-hq...
However, in this case, '10 person company' is more meant to imply the resources (bug bounty budget) available to the company. It's appropriate to categorize it as a 'a massive corporation with millions of users' for this purpose.
The whole process which began back in the late 90's with Ultima online in a bid to get people to pay monthly for the same computer role playing games by rebadging PC RPG's mmo's.
So everyone with a clue about gaming history should know valve only seems "big" because the internet enabled gave them first mover advantage when they wrapped the steam store around half-life 2 in the mid 2000's, over the next 5-6 years that would make valve a tonne of money as AAA games released on steam until uplay and origin showed up later.
Let us remember the reason we have storefronts for every company is because the internet enabled companies to steal PC games out from gamers via server locking games to their companies PC's. Now we're even seeing basic game functions held back and sold for microtransaction money.
If you buy the argument, you obviously never gamed during the 90's during the heyday of level editors, free maps and mods over IPX emulators like Kali and kahn.
It's not utter nonsense, DRM is literally taking files of the game hostage. Go load up overwatch and disable the network card, Go load up quake 3 or Unreal tournament 2004.
You can still play Quake 3 and UT2004, you'll notice a big fat error in overwatch because it is logging you into a server required for it to function.
Go get never winter nights released in 2002, compared against the "f2p" (aka stolen rpg rebadged an f2p mmo during develpment).
https://store.steampowered.com/app/704450/Neverwinter_Nights...
The original neverwinters had game tools and you could run your own server, vs neverwinter the "f2p mmo" version (aka moniker for the game moving to server locked game).
https://store.steampowered.com/app/109600/Neverwinter/
Any gamer in the 90's was expecting more dedicated servers, level editing tools with PC games.
Leauge of legends and DOTA 2 would have been fully single player RTS games with multiplayer.
So no you and anyone who believes like you is willfully ignorant that we now live in a PC game dystopia. Whereas before League of legends and DOTA 2 would have been coded like Quake 3, Unreal tournament 2004, and warcraft 3, you own the game and can play it multiplayer if necessary without a third party.
Diablo 2 we owned it --> Diablo 3 blizzard owns it and can now shut it down
Quake 3 we owned it --> Quake champions bethesda owns it and can shut it down.
So no, we've gone backwards in time to mainframe and dumb client model of computing because of the average gamer being computer illiterate and not seeing the writing on the wall.
So no they were not fundamentally a new "genre" that was what marketing and PR flackeys hoped people like you would buy. Note that private servers prove you incorrect, aka that there exist private servers for Ultima online and World of warcraft, demonstrate tehy would have just been Role playing games with shards players controlled, there was no need for companies to conrol them or the monthly fee.
Overwatch is a case in point that you are incorrect, since it's just a multiplayer fps, why is there no level editors, tools, open file specs and GTKRadiant? OH yeah thats right they wanted to lock down the code from a server in their office to resell skins that are sitting on encrypted files already on your machine setting a programming flag to display, when you've "earned" them via the stupid leveling system or gambled for them using their lootbox system.
That is why PC RPG's were rebadged mmo's, so that they could use it as a battering ram to change game culture. It's all about profits for these game companies, they wanted control of the software to put microtransactions in them. Notice after Valve, EA and activision got control of the software, they immediately shoved microtransactions into games.
You don't have to deal with lootboxes or MTX if you own the game outright. MMO's were part of the long term war on software ownership on the PC. To not see that and think they are special because you have very powerful feelings for these games, means you're ignoring the overwhelming evidence that the game industry was successful in changing public opinion regarding game ownership. AKA got you to see software as a service as "OK" and that's all they needed to get their foot in the door to take control of the software, once they got a generation of kids that's ok buying software they don't control - the skies the limit at abusive microtransactions, lootboxes and in game stores.
That also means level editing, free maps and mods need to be scaled back because it interferes with profits.
MMO's argument for online portions of their service were based around that scale. There are plenty of online only games, loot boxes, microtransactions that can happen outside of MMO/RPG style games, some existed before MMO's even took off.
To ignore the fact that MMO's absolutely do need more hardware and need to be split between client and server shows a clear lack of understanding or knowledge about client-server models, large multiplayer games and development.
You could argue even a game like Minecraft (which is not totally DRM free) includes the server code, so players (and companies) can setup servers as they please.
The only reason I can see for a game to not include the server-side code is to hold the users hostage.
5-10 years from now, nobody will be able to play these games because the servers will be discontinued. We effectively "rent" them because of this.
MMO = marketing term for computer program instructions
Is there any reason as a gamer for any program to be split between two computers when companies goals are to maximize profit, not produce the best games?
So no I understand perfectly well. The fact that private servers exist for world of warcraft and ultima online demonstrates your comment as a farce.
I downed your post because resorting to personal insults is against HN's guidelines.
To your point, there exists MMOs that are validly massively multiplayer, online games. There are also many games that didn't need to be architected as an MMO and, from a cynical viewpoint, that could be seen as a land-grab taking control away from the consumer.
You have glossed over a lot of other facts in your pursuit of black-and-white here. For example, Quake 3 and UT2004 had CD Keys. Likewise in regards to Steam, it's not that there are zero benefits to that delivery mechanism over how things were beforehand. Automated install and patching is a far cry from the messing each person had to do previously.
It's certainly debatable whether these things are a net positive or negative, and IMO it's becoming increasingly a negative as time moves on.
There is a reason and it's a darned good one: piracy. It was well discussed on professional game development sites in the '90s and '00s; building a online game or game with a large online component meant that it was immune to being pirated.
Eve Online is a good example of this.
This is not a good reason at all, especially from the consumer's perspective.
Why would i "thank" someone that puts unnecessary restrictions on how i can use the program i paid them money for?
> neither immoral
I see it as very immoral to deny me access and control to the software i paid for, especially when that happens because the developer treating me in a guilty-by-default way for something they have no idea if i'll do or not.
You could thank them for writing the program for you in the first place, if they didn't then you'd have to do it yourself.
It's a game. No one is forcing you to play it.
> No one is forcing you to play it.
That has nothing to do with whether the product is moral.
The correct term is "fraud". Just because copyright trolls misuse words that way doesn't mean we should sink to their level.
League of legends and DOTA 2 were just real time strategy games that have been coded to use the mainframe model, instead of the locally run application model like quake 3 and Unreal tournament.
That was the whole plan for all new PC games. Think about this - league of legends makes pure profit selling flags to display skins that are already on kids machines because we know how computers work. That was the end game for the game indsutry to resell the same game assets like skins and characters over and over at insane margins.
That's exactly what we got with lootboxes and mobile - aka a platform that is completley locked down and there is no software ownership. Go to google and select images, and put in "mobile game revenue 2019" or any other year just prior to this one. Then compare it to PC or console game revenue. The software industry is obsessed with locking down the PC because they see the mad profits from mobile. That's why we got drm in windows 10...
It's all been slowly building from early succeses of walled gardens like mmo's and steam in 2004, to fully server locked multiplayer games that companies control like league and dota 2. To mobile gacha games that sell gambling for pokemon like characters to kids for sick profits without the kids getting any ownership of the software they are paying for.
Disallowing players from enjoying a game without paying doesn't work for everyone, but the network effects of multiplayer games virtually assures an increase in sales once your game passes a threshold of popularity.
The tradeoff, however, is that this won't work for small and niche games. For players to convert to purchasers the value must appear sufficient, and a multiplayer game with no players has little value.
Contrast that with how Valve handled Steam. Valve set no restriction on game publishers. Publishers were never forced into taking advantage of digital distribution at all. They were able to preserve all of their retail distribution contracts by screwing the customer. Digital distribution is profoundly cheaper, enables release of games a week sooner, could rely on Steams DRM without needing third party extra DRM, etc. These are all things Valve could have required publishers to take advantage of to benefit customers. But they didn't. They gave publishers carte blanche and let them do absolutely anything they wanted. If another company had been the one to become the dominant platform, it could have been more like the iTunes situation.
This is also the thing which guarantees Steams eventual downfall. Music publishers considered, and a couple even tried, building their own digital distribution service. But, the publishers were incapable (because of institutional restrictions) of building a competent competitor that would be appealing to consumers. The publishers board wouldn't permit things like individual track sales, 99 cent price caps even for popular singles, etc. Steam is a different story. Since there are literally no restrictions on publishers at all, there is also no reason for publishers to refrain from building their own separate platforms and cutting out Valve's cut of the sale. Gamers have established that they are more than willing to install and use however many launchers as necessary, so there is almost no reason for big publishers to use Steam rather than just building their own.
BTW...
> Are you sure that a free game made of garbage by an unknown developer will behave honestly? Do you believe that for a 90% discount you will not get a hidden miner?
...beyond this being FUD, games do not need to run with Adminstrator privileges to put hidden miners and even if they did, all they'll need to do is simply... show the UAC prompt. So many things show it that people will accept it anyway, especially when they're trying to start a game. But more importantly, such a game will be removed instantly from Steam and thus wont spread much while the developer could be sued (before publishing anything on Steam you have to give them your full details) making the entire endeavor not worth the effort.
Though of course this issue can be taken advantage of outside of Steam.
The Steam Controller has a "lizard mode" for when it can't connect to Steam where it just acts as a dumb mouse. I have no idea whether it enables that for UAC prompts, but it probably could.
That matters because desktop mode still has customizable keybindings as usual, while lizard mode is completely hard-coded. Lizard mode also (obviously) doesn't support the soft keyboard, which would otherwise have been pretty useful from the lock/login screen.
If you try to stream something that first pops up UAC, the client just sits there waiting for it to be dealt with on the host.
Every time I do that I think there must be a better way.
> @powershell -NoProfile -ExecutionPolicy unrestricted -Command "$sessionid=((quser $env:USERNAME | select -Skip 1) -split '\s+')[2]; tscon $sessionid /dest:console" 2> UnlockErrors.logpp
I've not used it often and mostly given up on Steams streaming stuff. Playing simple stuff though RDP directly usually works well enough for the few times I still did that. Notably pretty much all games launch flawlessly. The drawback is it not being optimized for games, offering a notably worse performance on that front.
Yeah, this is a good point. Not sure how many folks here play a lot of Steam games, but a ton of them install their own specific VC++ runtime redists (sometimes multiple) at first run, and each of them throw their own UAC prompt.
It's absolutely an established pattern for me to mindlessly click through 1-5 UAC prompts on first run of Steam games. (Though they're typically all Microsoft Corp signed in the prompt, which is helpful.)
Maybe they should use "c:\users\all users\appdata" for this purpose instead of using "c:\program files"?
How old? Like DOS old? Because most programs from this century should assume they were installed somewhere inside of Program Files.
1. Log on as non-admin on a box with steam 2. Do not start steam or any game 3. cat %system32%\calc.exe > %programfiles%\steam\bin\steamservice.exe 4. Reboot 5. Log on, start steam 6. BAM! Now you have calc.exe (attempted to) run as System with highest local priveleges
This requires elevation.
I didn't modify anything so I assume Steam set it that way.
Headdesk
However, I'll point out that one hardly needs administrator access to, say, encrypt your documents and install a crypto miner. The whole idea that gaining administrator privileges through local escalation on a personal desktop is A Big Deal(TM) is silly.
So even if someone gets exec on your user files, you'd still prefer them to be limited to your user and not running at higher priv levels. Even if 90% of the damage is done with access to your personal files, it still adds more damage with higher privs.
Plus this means user-level countermeasures like "run steam as a separate user" are useful; with escalation, that's not an effective defense. Also, if you've got multiple users on the computer, an attack that can't escalate privileges might ruin your day, but an attack that can escalate privileges might ruin your day and your spouse's day and anyone else in your family's day, so even in terms of "personal files" on a modern Windows system you can still be looking at more damage from an escalating attack.
> So even if someone gets exec on your user files, you'd still prefer them to be limited to your user and not running at higher priv levels. Even if 90% of the damage is done with access to your personal files, it still adds more damage with higher privs.
This is debatable, since whatever other damage they could do is something I'm not likely to care very much about compared to all my work, the whole reason I have a computer in the first place, being held for ransom or otherwise lost to me.
> Plus this means user-level countermeasures like "run steam as a separate user" are useful; with escalation, that's not an effective defense.
I suppose this is true, however I don't think any competent authority will tell you that simply running a program you don't trust as another user should ever be relied upon as a sandboxing mechanism anyway.
> Also, if you've got multiple users on the computer, an attack that can't escalate privileges might ruin your day, but an attack that can escalate privileges might ruin your day and your spouse's day and anyone else in your family's day, so even in terms of "personal files" on a modern Windows system you can still be looking at more damage from an escalating attack.
That's a fair point.
You're right that merely using "runas" does not provide any additional security (at least none that can't be circumvented). However if you run an application in a separate desktop session under a separate user account that does not have admin access at all (e.g. the account type is "standard user") then it should be sandboxed from other users (in technical terms, it's a security boundary).
The most practical way to do this on a consumer desktop would be to have a separate "Steam user" account that you log in to for the sole purpose of running Steam. While most people wouldn't want to do this (as it's inconvenient), it should at least be an option for those that do want it. To put it another way, there's no good reason to undermine the enhanced security provided by separate user sessions.
I’ve seen steam on work computers. This isn’t limited to home desktop users by any stretch. People install steam because they don’t know it puts their work computers at risk.
You could argue that they shouldn’t have games on a work PC (some companies are a bit more lax and even play together) and an easy way to convince them to not do that is if you point out that Steam makes your system less secure by design.
Steam also sells design tools and complete sdks. Idk if it is a common way to install them though.
Security is still important for those companies
Edit: downvoters, I would really like to know why this post deserved downvotes
Tell me, what precisely does having administrator privileges on a workstation provide that having the user account's privileges does not? With the user account you still have access to the user's files (and they are almost certainly the only user of that workstation) and all network resources they have access to.
If the machine is on a Windows domain, usually anybody on that domain can log on to it. Which means I can walk up to your machine while you grab a coffee and use this attack to gain full control over everything on your machine. If you do anything personal on that machine, eg email, I just got access to it.
The parent is describing an attack which does not require the administrative user to do anything except install Steam. Any other user who can logon to that machine could use this privilege escalation exploit to access the administrative user's files
However, this is not necessarily the case, so I yield the point.
As a particular problematic scenario, consider a school: Steam cannot be used in educational settings because of this issue.
But no let’s just forget all of the reasons we use group policy and principles of least privileges.
Imagine if your initial foothold is user with Steam installed. You just got SYSTEM for free.
What good is the computer account for this when you already have the user account?
> But no let’s just forget all of the reasons we use group policy and principles of least privileges.
By that rationale, computer accounts should have far fewer privileges than the actual user account anyway, so again having local admin isn't worth much.
> run code that wouldn’t otherwise be possible
Namely?
> Imagine if your initial foothold is user with Steam installed. You just got SYSTEM for free.
And I'm struggling to see how that adds much to my problem of someone having a foothold on a user workstation already.
And that's ignoring the circumstances of Steam being installed on the workstation in the first place AND the user having installed some untrustworthy game with it in the window since the game's appearance on Steam and its detection and removal.
Which is also not to mention that this means the user has the ability to install software and is therefore infinitely more likely to just download some malicious installer from the nefarious portions of the internet that they can access with a web browser.
Powershell, friend. Changing execution policy requires privileges. Guess what SYSTEM gives you? Plus you can disable windows defender and install any nasty things you want! Pretty sure you’d need system to snoop/inject traffic too.
If you have other services or applications installed (like IT setting up your workstation), those things can now be read/changed where they otherwise wouldn’t be with just user access. This can lead to other information leakage about other parts of the network or services.
>And I'm struggling to see how that adds much to my problem of someone having a foothold on a user workstation already.
No fucking shit, but you don’t let them walk into system just because they got user.
You’re taking the stance that any compromise means death and that’s directly opposite of defense in depth, so you clearly don’t believe in that. That’s just being lazy mate. Why not just chmod 777 everything and call it a day?
>Which is also not to mention that this means the user has the ability to install software and is therefore infinitely more likely to just download some malicious installer from the nefarious portions of the internet that they can access with a web browser.
Because they don’t know Steam is insecure by design! They trust Steam! That’s the problem! This isn’t common knowledge and since Steam won’t fix it, it needs to become common knowledge.
PowerShell execution policy is stupid easy to bypass. You simply pass the '–ExecutionPolicy Bypass' parameter when launching the script. Of course, since you already have complete control of the user account, being able to run PowerShell isn't nearly as big a deal as the fact that you can run anything at all.
> Plus you can disable windows defender and install any nasty things you want!
Windows defender, like pretty much all AV software, is crap anyways and won't detect most of the things you'd be interested in doing. It's a low-effort screen for well known malware. Case in point: it didn't catch your malicious installer when Steam downloaded and ran it in this scenario did it?
> Pretty sure you’d need system to snoop/inject traffic too.
That may well be true, but considering I pretty much already have full control of the user account and can therefore do everything it can do on the network without injecting anything, I'm not sure what is gained.
> No fucking shit, but you don’t let them walk into system just because they got user.
Eh, it isn't really worth my effort to try and prevent it when all they'll have to do is fire a UAC prompt the user will almost certainly just click through anyway. Especially considering what little (basically nothing) it gets the attacker.
> Because they don’t know Steam is insecure by design! They trust Steam! That’s the problem! This isn’t common knowledge and since Steam won’t fix it, it needs to become common knowledge.
So here's the scenario you're talking about: A user has installed Steam on their work computer. They use Steam to download an installer that is actually malicious and this fact has not been caught by Valve yet. Steam, who's entire purpose is to install games, runs the installer. Consequently, the user account is now owned by an attacker.
...And even if this vulnerability were patched ALL OF THE ABOVE WOULD STILL BE TRUE!
GPO prevents this but if you have local system you can override that locally and then change execution policy.
I’m sorry, I don’t say this often but you don’t know what you’re doing so I’m not going to take the time for the rest of your post. I’d encourage you to research this more if you like it.
You strike me as a very typical infosec person, always endeavoring to make mountains out of molehills and add unnecessary friction to everyone else's job in order to add minor benefits in highly improbable scenarios.
All things considered, thanks for discussing this with me despite my harsh language and tone. It’s a bad habit of mine
Makes sense, because Windows is also used for servers. The Steam client is not.
> If Steam is installed on a corporate network PC (game development, QA services, esports teams, etc?), regular users being able to elevate to machine admin is a big deal.
No it isn't. This is effectively the same as being installed on some home PC. Being local admin on the workstation doesn't really give you any more ability to do damage than just a regular user account. A non-administrative process still has access to all the user's stuff, and all the network resources that user account has access to. Local admin doesn't really give you anything new.
That's dangerously untrue. On all the Windows systems at home, everybody else is a non-privileged user and I set sane file permissions so they can get to shared movies, etc, but not read my bank details and tax records. Privilege escalation means that they could trivially change those permissions. The same is true of a corporate environment -- just because you can't also make changes to AD doesn't mean the threat of accessing local files under other users' accounts is trivial.
ETA: I just read a bunch of this user's other posts in this thread and I'm beginning to suspect they're trolling, so I'll disengage.
Ok, in that scenario it is true, but multi-user desktops in the age of smartphones and tablets are a vanishingly small niche. My experience in corporate environments suggests they are also almost entirely 1:1 as well.
the issue is this file has W permission for all users
you can't write there without elevating. at which point you can just register stuff to run as you wish.
The primary way of attack was to trick a steam user into either uploading the token file directly, or trick the user into running an executable that uploaded it silently. If you're already tricking the user into running an executable you design, there's not much left that can be done to stop this since such an executable could reach inside the running steam process and read whatever data it likes.
I should also mention the trend towards these Vault services to store secrets is even worse, as that they effectively make all secrets on a machine world readable since an off box service can’t determine what user is making the request. And the trust on first use idea is lacking in most implementations and vendors like HashCorp in fact don’t want to add it anymore since apparently their users had problems using it and would lock their apps out by accident. So... yeah.
Even if you are trying to play two different games Steam will try to kick one of the players off. It seems like they think a "family" is a family of computers that one single person might want to access. I get that they might be concerned that someone sets up a Steam account for their entire floor of the dormitory or something, but wouldn't a sensible limit be more like 5 instead of 1, with the additional limitation of only one copy of a particular game at once? Plus the ability to buy multiple copies of a game for a single library if you want? Netflix, Amazon Prime Video, Hulu, etc... all figured this out, why can't Valve?
Also, you can buy licenses for a game on more than one account. If sharing is enabled for accounts A, B, and C on a set of computers, C can use a license from A or B, if both own the game. The trick is that it tries to use the license of the person who enabled sharing most recently. So if A enables sharing, then B, but B is currently playing a game, it won't let C play a game that both A and B own. You can log in as B and disable sharing, then it will work. Alternately, there are tools to fix this automatically by editing config files -- and in retrospect, they probably work because of the security flaws mentioned in an earlier thread...
Why I have a separate gaming only computer... no banking, no work, no social media, nothing but game platforms.
In fact, it's the only computer I run Windows on.
I’m glad the issues are getting more attention and hope Valve finds effective ways to harden their client. This is needed despite the walled garden they have.
I turned off remote streaming after that happened. Author of this paper is right for disclosing
Personally I find it annoying that it doesn't have a fallback whole-desktop mode, since some game launchers (eg Minecraft) interact very badly with Steam streaming, and Microsoft insist on turning RDP off on consumer editions. You can fake it by installing Notepad as a "third party game", but it's not entirely reliable.
I ended up using Nvidia+Moonlight to stream Minecraft.
- Steam has a privileged service, users can start/stop it.
- Steam's service resets a bunch of registry subkey ACLs under [HKLM\...\Valve\Steam] at startup
- Steam's service gives unprivileged users read/write access to its own keys
- Steam lets unprivileged users write to this area of the registry
- Steam's service follows registry symlinks
This is terrible. Any multi-tenant machine with Steam installed is affected and should be considered compromised.
Sayinf privilege escalation doesn't count because you need to place a file on the file system is a nonsense excuse. It's saying "yeah well it's not our problem that we give a process full system rights because the user already opened something else in low privilege mode".
But in practice, the only way to change registry keys/values is by going through the registry APIs provided by Windows; I certainly wouldn't consider registry operations as file system operations.
I'm on Windows 10. It's possible I've already installed the required Visual C++ runtimes.
I'm thinking the next step (for me at least) is not isolating Steam into its own non-admin account, but to its own entire VM.
[0] Which has been a "fun" metagame since doing that. Game developers are horrible children at security permissions and the whack-a-mole necessary to allow access exceptions for games inside that space is quite incredible and sometimes disturbing. For instance, some games have six or seven EXEs for no clear, discernable reason. Some games love randomly copying EXEs to temp spaces before running them (often downloaders and launchers, but the fun ones are those with no clear downloader nor launcher but still running EXEs from %LocalAppData%\Temp).
[1] Password cracking attempts on my Steam account got really disturbing/absurd. The weak link seems to be a Steam Web API that Steam claims has enough botnet protection, but Steam customer support of course tells me that the problem must be at my end due to malware. So of course, that lead me to "proving" that it can't be malware on my end in part by locking Steam down as much as possible.
Of course it probably breaks some Steam services but apparently not ones I use.
I can't imagine the number of security vulnerabilities in Steam games. Most games require invasive anti-cheat services that are connected to a command-and-control sever with full RCE capabilities (and RAM dumping/analysis, etc).
If you want a specific example, take Unreal Tournament (1999) on steam: this is an old game, yet its security practices remain unchanged. Most public servers I tried to connect to pushed dlls on my computer, that were then loaded by the game executable, to provide a variety of mods, anti-heat services, and more.
That means anyone hosting a UT99 has RCE and privilege escalation capabilities on any client that connect trough Steam, without even trying hard. More concerning is the fact that games are a very specific medium: robustness/security is often not the primary concern, most are networked, and few are patched [a few ears] after release, yet remain launched on a regular basis for decades to come. Moreover, newer games tend to push resource usage too much for elaborate sandboxes.
That's the reason why I run Steam trough flatpak's sandbox: at least, it, or games, don't have access to my filesystem. I still have concerns over the login token, though. Wayland does provide some extra protection against potential keyloggers/others, but I wish Steam itself was constructed like a browser, sandbox-wise.
(yes, the remote dll loading happened on Linux, trough wine/proton, a testament to the engineering of these compatibility layers).
Hopefully they'll learn from it and act more professionally and increase their payout if they want security researchers to take them seriously in the future.
Neither account seems to be banned, both comments seem perfectly fine.
I'm now somewhat curious is this comment will be hit with wathever hit the other (at the time of writing) four comments.
(perhaps this comment will get autokilled too)
... surprise? Of course not. Neither do 99% of their users.