Every article tag can be clicked to get a list of all articles in that category. Every article tag also has an RSS feed! You can customize an RSS feed too!
We do often include affiliate links to earn us some pennies. See more here.

Valve locking down publishing Steam builds with SMS codes due to Malware

By - | Views: 30,855

Valve announced recently some new changes for developers publishing public builds to their games on Steam, requiring a phone number and a text message confirmation code.

As the announcement says "As part of a security update, any Steamworks account setting builds live on the default/public branch of a released app will need to have a phone number associated with their account, so that Steam can text you a confirmation code before continuing". The change is due to go live on October 24th and for developers who don't have a phone Valve simply say "Sorry, but you’ll need a phone or some way to get text messages if you need to add users or set the default branch for a released app". It will also be needed for adding new users, and Valve plan to add this requirement to "other Steamworks actions in the future".

Valve didn't mention why, but it didn't take long for the reason to make its way online. It turns some developer accounts were compromised, and used to spread malware on Steam. As noted by Simon Carless on X, showing a screenshot a developer received:


Screenshot via Simon Carless, SteamDB

In reply to the X post, developer Benoît Freslon said "Hey Simon, I'm the developer of this game. ALL my accounts were hacked by a Token Grabber Malware. Unfortunately, the 2FA i s useless if the token is still active. I just used my dev account to release the game few hours before the hack I suppose."

Valve confirmed to PC Gamer the issue affected less than 100 Steam accounts with the games installed.

Article taken from GamingOnLinux.com.
Tags: Game Dev, Misc, Steam
12 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
19 comments
Page: «2/2
  Go to:

BlackBloodRum Oct 12, 2023
View PC info
  • Supporter Plus
Quoting: denyasis
Quoting: Nateman1000
Quoting: BlackBloodRum
Quoting: Purple Library Guy
Quoting: BlackBloodRumWhy is the game blurred? This developer should put their hands up and admit they failed basic computer security.
You mean . . . they're running Windows?!
That could well be true! Imagine having to use Windows every day though? The agony, the anger, the frustration, the distractions and to top it all off, you upload an infected game.
Many think windows disease is incurable but it is very curable. So make sure to get a Linux or BSD distribution for your computer and cure this disease

This is probably ignorance in my part, but how is security better with Linux in this situation? We're (mostly) running these programs wide open out of the home drive (maybe some ppl are using flatpack or snap, but even then that's not a default requirement on most distro and people still poke holes in those sandboxes regularly). No, it can't infect "the system", but since we're executing programs out of /home, isn't that good enough? The malware is still running under the users permissions, it can still execute in /home, read data, access the network, etc.

Maybe I'm missing something fundamental with Linux security, but it seems once I log in anything within the user space can run under my permissions, malware or not? Especially if it's malware hidden in a program/game that I intentionally started?

I've used Linux a very long time, but I'm self taught.... Security is one of those Linux areas that's always been complex for me to grasp in a meaningful way.

For a typical desktop system without additional protection whatsoever, the malware may work. But consider this, what is malware trying to do, and where is it looking?

It's almost certain it'll look for typical Windows locations, which would be those provided by Proton (Wine). In the case of a Steam game running via proton for example, that means if it will find steamapps/compatdata/(gameid)/pfx/drive_c/* by default. The good news is, unlike regular wine, proton doesn't link users/steamuser/Documents to your real documents location.

So it's possible the malware will simply do nothing of harm to a Linux machine.

However, that doesn't mean you can simply forget and dismiss it! It is possible the malware has been trained to handle Linux, in which case it will try to get access to your home directory. Worst case here is your home directory gets hosed, and data which your user has permission to modify is altered, which is fairly minor.

You can prevent this situation in a couple of ways, you could prevent that access to those files using AppArmor or SELinux, you could combine that with, or use only flatpak with a proper configuration by modifying the permissions to revoke "All User/System/anything Files". It simply doesn't need it, along with disabling access to xdg-music, xdg-pictures. Steam only needs to access the locations that it is instructed to download games to (Your library), so you can specify only that directory as read/write and block everything else. It shouldn't need other directories, but if it does and doesn't need to write to them, then set it to read-only.

This advice applies to basically all flatpak apps. Only give minimal permissions. For example with Bottles, you might download your GOG games to a home directory folder like ~/Games, well bottles doesn't need to write to those GOG installers. So it can be safely set to read-only for bottles.

Oh, and the big one: Keep things updated with the latest security patches.

These are simple security measures, but it should be more than enough to prevent windows-based malware from escaping its wine prefix.

It might not however, stop a specifically targeted to you attack. A key thing to remember, security isn't something you can just say "must be like this" for. Different environments have different threat models.

Know your threat model, and adjust your security as necessary.
denyasis Oct 12, 2023
Quoting: BlackBloodRum
Quoting: denyasis
Quoting: Nateman1000
Quoting: BlackBloodRum
Quoting: Purple Library Guy
Quoting: BlackBloodRumWhy is the game blurred? This developer should put their hands up and admit they failed basic computer security.
You mean . . . they're running Windows?!
That could well be true! Imagine having to use Windows every day though? The agony, the anger, the frustration, the distractions and to top it all off, you upload an infected game.
Many think windows disease is incurable but it is very curable. So make sure to get a Linux or BSD distribution for your computer and cure this disease

This is probably ignorance in my part, but how is security better with Linux in this situation? We're (mostly) running these programs wide open out of the home drive (maybe some ppl are using flatpack or snap, but even then that's not a default requirement on most distro and people still poke holes in those sandboxes regularly). No, it can't infect "the system", but since we're executing programs out of /home, isn't that good enough? The malware is still running under the users permissions, it can still execute in /home, read data, access the network, etc.

Maybe I'm missing something fundamental with Linux security, but it seems once I log in anything within the user space can run under my permissions, malware or not? Especially if it's malware hidden in a program/game that I intentionally started?

I've used Linux a very long time, but I'm self taught.... Security is one of those Linux areas that's always been complex for me to grasp in a meaningful way.

For a typical desktop system without additional protection whatsoever, the malware may work. But consider this, what is malware trying to do, and where is it looking?

It's almost certain it'll look for typical Windows locations, which would be those provided by Proton (Wine). In the case of a Steam game running via proton for example, that means if it will find steamapps/compatdata/(gameid)/pfx/drive_c/* by default. The good news is, unlike regular wine, proton doesn't link users/steamuser/Documents to your real documents location.

So it's possible the malware will simply do nothing of harm to a Linux machine.

However, that doesn't mean you can simply forget and dismiss it! It is possible the malware has been trained to handle Linux, in which case it will try to get access to your home directory. Worst case here is your home directory gets hosed, and data which your user has permission to modify is altered, which is fairly minor.

You can prevent this situation in a couple of ways, you could prevent that access to those files using AppArmor or SELinux, you could combine that with, or use only flatpak with a proper configuration by modifying the permissions to revoke "All User/System/anything Files". It simply doesn't need it, along with disabling access to xdg-music, xdg-pictures. Steam only needs to access the locations that it is instructed to download games to (Your library), so you can specify only that directory as read/write and block everything else. It shouldn't need other directories, but if it does and doesn't need to write to them, then set it to read-only.

This advice applies to basically all flatpak apps. Only give minimal permissions. For example with Bottles, you might download your GOG games to a home directory folder like ~/Games, well bottles doesn't need to write to those GOG installers. So it can be safely set to read-only for bottles.

Oh, and the big one: Keep things updated with the latest security patches.

These are simple security measures, but it should be more than enough to prevent windows-based malware from escaping its wine prefix.

It might not however, stop a specifically targeted to you attack. A key thing to remember, security isn't something you can just say "must be like this" for. Different environments have different threat models.

Know your threat model, and adjust your security as necessary.

Thanks for the info. Might I tee you up another question(s)? Hope is not too silly. For the nearly 2 decades I've toyes with Linux the mantra has always been "ppl won't target Linux because it's too small so malware won't work!

Now, I truly mean no offense, but the beginning of your post reminds me of that. Why would it just look for Windows directory? Why not just go up a level or two or simply run from the directory it's currently in?

For the sake of argument here, let's presume a Linux build of a Steam game was infected... Why would we presume it would look for Windows stuff? It's already running attached to a Linux script or executable in Linux environment, right?

I see your point about Proton and Wine making things more difficult, but I do have a question about that. I know they still seem to keep Z: as the rest of the file system outside the prefix. Why would a Windows malware not look for other drives? You're right, it depends on what it's trying to do, but I can say my limited workplace experience is all in Microsoft shops and they all use network drives heavily. I'd expect a ransomware or something similar to look for stuff outside C: right away, right?

Last last question.... Even with everything sandboxed, a malware (say some sort of DDos bot), could just sit in the sandbox and do it's thing? We'd still need an antivirus or someway to detect it being there, right?

Thanks for answering my questions and having the patience to deal with stupid questions!!
Nic264 Oct 12, 2023
Quoting: denyasisNo, it can't infect "the system", but since we're executing programs out of /home, isn't that good enough? The malware is still running under the users permissions, it can still execute in /home, read data, access the network, etc.
Relevant xkcd: https://xkcd.com/1200/

Quoting: BlackBloodRumIt is possible the malware has been trained to handle Linux, in which case it will try to get access to your home directory. Worst case here is your home directory gets hosed, and data which your user has permission to modify is altered, which is fairly minor.
Worst case is rather that it uploads your ~/.ssh, ~/.mozilla and ~/.thunderbird to some remote server.
I would not call that “fairly minor” either way, what is more valuable on your computer than your data?
BlackBloodRum Oct 12, 2023
View PC info
  • Supporter Plus
Quoting: denyasisThanks for the info. Might I tee you up another question(s)? Hope is not too silly.
There's no such thing as silly questions, there are only questions.

Quoting: denyasisFor the nearly 2 decades I've toyes with Linux the mantra has always been "ppl won't target Linux because it's too small so malware won't work!

Now, I truly mean no offense, but the beginning of your post reminds me of that. Why would it just look for Windows directory? Why not just go up a level or two or simply run from the directory it's currently in?
I've heard the same thing, and I disagree with the idea that the OS and market share is too small to be targeted. It was not the point I was trying to make, but rather, that a malware designed for Windows will most likely look for Windows related resources.

Ironically, in our quest to make Games and other applications more compatible with Linux, we also make malware more compatible with Linux.

Quoting: denyasisFor the sake of argument here, let's presume a Linux build of a Steam game was infected... Why would we presume it would look for Windows stuff? It's already running attached to a Linux script or executable in Linux environment, right?
That's a different issue altogether, if it's a Linux native build then it's probably a Linux native malware. To protect against such a threat would require further hardening. In that case I would strongly recommend SELinux, ideally on a distro that has it enabled by default. I say that since on a distribution which has it enabled by default, it is far easier to setup SELinux than one that doesn't, so you could simply tweak it rather than configure the whole thing.

There is AppArmor as an alternative. Otherwise, if neither of those are suitable then there's always Firejail.

Quoting: denyasisI see your point about Proton and Wine making things more difficult, but I do have a question about that. I know they still seem to keep Z: as the rest of the file system outside the prefix. Why would a Windows malware not look for other drives? You're right, it depends on what it's trying to do, but I can say my limited workplace experience is all in Microsoft shops and they all use network drives heavily. I'd expect a ransomware or something similar to look for stuff outside C: right away, right?
That's something more people need to ask. It's true, if the ransomware looks beyond C:\ it will most certainly find Z:\ and if it does, it will see your root directory (/). But that's also why I mentioned it depends on what it is looking for. A ransomware will almost certainly try to get everything it can find, on any drive. So you'd be hosed in that case. On the other hand, a malware which tries to steal login credentials will probably get lost in Z if it's not aware of how Linux works.

But this is a key misconception with Wine and Proton in general: Wine (Proton) is not a sandbox, it never tried to be, it never was. It never will be.

On its own wine can do very little to protect your system from the malware, because it's simply not trying. That's not its job. However, that doesn't mean you can't bolt on other things to your Linux to protect against things ran inside it.

This is why the sandbox, or limitation of file access by other means is important here. For example, if you install flatpak steam, configure the permissions to only allow specific directories, you'll find that proton's Z:\ will simply lead them to files within the sandbox, with no further access to the steam (So your real root (/) cannot be accessed).

This sandbox would be active whether you are using the malware within proton, or the malware as a native application. Protection from both. Neither can access your root (/). That's why I heavily recommend the flatpak to new users, just for that extra bit of protection, assuming you don't have "All system files" filesystem access enabled, I really wish developers would stop enabling that in flatpaks.

Quoting: denyasisLast last question.... Even with everything sandboxed, a malware (say some sort of DDos bot), could just sit in the sandbox and do it's thing? We'd still need an antivirus or someway to detect it being there, right?
Yes and no. Assuming for the moment that the malware is trapped entirely within the sandbox, then it will start and end with that sandbox. So for example, if you have a Windows malware that is running within proton, when you click "Play" on a game, it will probably launch with the game (it sees this as a system boot). When you exit the game, if the malware is attempting to run in the background then you'll notice that Steam's button didn't return to "Play" after the game exited. It's worth asking yourself why that may be. The malware will keep the prefix "awake" so to speak, so you, and steam, will notice the prefix hasn't exited.

For a native malware, it may be a little trickier. Still assuming it didn't escape the sandbox entirely, it is possible it forked another process which the Steam client is unaware of, in this case your game would appear to have ended, and the button will return to the green "Play".

However, that process too will end once the flatpak is closed entirely. For example, executing:

flatpak kill com.valvesoftware.Steam

Would immediately stop any/all malware running within the sandbox, along with Steam itself of course.

There is one thing that should be mentioned however, the sandbox covers Steam as a whole, so that means it would theoretically be possible for a malware to spread itself to other games, and the sandbox as a whole. The sandbox does not protect on a per-game basis, so all games (and therefore malware) are able to see each others files.

Since everything is happening within the Sandbox, you will probably notice rogue or strange processes within your process monitor, linked to the sandbox. It does mean however, a ransomware could encrypt your entire Steam flatpak installation, all games everything, but that's so far as it would go.

Should you install anti-virus? It's not strictly necessary so long as you take other steps to protect yourself such as sandboxing. With that said, I would suggest having ClamAV or such installed in general, if only just to do occasional checks and to verify things you've downloaded are clean before you share them onwards.

There's also a couple of online services which can check on a per-file basis if you wish.

But overall, your safest option is to simply use common sense. Don't download from dodgy websites, that video isn't that important.

The biggest threat however is not Steam, Steam is one of the safer options. The biggest threat is games from Itch.io, since in many cases files are simply not checked before you download them, or you may be pushed to third party websites entirely to download.

Quoting: denyasisThanks for answering my questions and having the patience to deal with stupid questions!!
There's no such thing as stupid questions, there are only questions.

Linux is not immune to security issues, it never has been. But it does give you some really good options to protect yourself, should you feel the need. In all honesty with the Linux user base growing, the risk of more Linux malware showing up only grows stronger.

(And when dealing with proprietary software? There is a need!)

Quoting: Nic264
Quoting: BlackBloodRumIt is possible the malware has been trained to handle Linux, in which case it will try to get access to your home directory. Worst case here is your home directory gets hosed, and data which your user has permission to modify is altered, which is fairly minor.
Worst case is rather that it uploads your ~/.ssh, ~/.mozilla and ~/.thunderbird to some remote server.
I would not call that “fairly minor” either way, what is more valuable on your computer than your data?

That's a fair point, but you should aim to minimize damage. In my own case, if the malware uploaded those three directories, they would get:

~/.mozilla - not found
~/.thunderbird - not found
~/.ssh - Keys which require a physical yubikey to be pressed to unlock.


Last edited by BlackBloodRum on 12 October 2023 at 8:17 pm UTC
DerpFox Oct 12, 2023
Quoting: artixbtw
Quoting: KimyrielleI wonder why Steam can't just support hardware tokens, like everyone else. I hate using phones as security tokens because they become a single point of failure (and also because I don't trust big business not to lose/abuse my phone number). :S
Yep, phone numbers are a laughable form of security, I don't understand why Valve still believes it's reliable enough not to be replaced by actual 2FA that doesn't require a proprietary application (at least officially).

One extra hoop to jump through, which requires a separate device as a security measure (easily broken if the user syncs their SMS to their computer though), but a very unreliable one.

Come on, Valve.

Maybe because that's the fastest and easiest what to do MFA there is. I don't say SMS is a good factor, but other factors are harder to make people accept them. They had to add a second factor now with as less friction as possible. And a sadly high number of game devs are as computer smart as the average office worker. So, as someone who had to push MFA in an office setup, I understand why they choose SMS first. We may see other factors pop up in the near future.
Purple Library Guy Oct 12, 2023
Quoting: BlackBloodRumSince everything is happening within the Sandbox
All this talk of Sandboxes nigh forces me to leave this:
https://www.youtube.com/watch?v=zyPHWZx_X60
ElectricPrism Oct 13, 2023
Quoting: denyasisThis is probably ignorance in my part, but how is security better with Linux in this situation? We're (mostly) running these programs wide open out of the home drive.

Yeah so. Not everyone can afford it, but __ IF __ you __ CAN __ -- go ahead and separate your gaming rig from your Work or Personal Desktop.

In the future __ IF __ you are going to get malware, it's very likely that it come through video games, especially if it were Windows as Anti-Virus do not scrutinize video games the same way they do other software.

Obviously I would never recommend Windows as it already __ IS __ malware -- but having your devices be appliances and segregating your "trusted" from "untrusted" is a good habit. The same goes in Networking -- give yourself some different subnets and separate "trusted" devices from "untrusted" devices and wifi from wired.
Pengling Oct 13, 2023
View PC info
  • Supporter
Quoting: Liam DaweThe developer only seems to have posted about it on their Steam forum but not in any announcement.
That is possibly the most ironically-titled game that this could've happened to.
ElectricPrism Oct 13, 2023
I felt the need to return to the topic again. Requiring "cell phones" doesn't bode well with me.

Hell I'm ready to drop cellphones entirely for Satellite Phones.

The point is SMS is like "The Fax Machine" -- the government having laws to keep it around is archaic and not really good.

This is such a BIG move in the wrong direction. Cellphones don't need to be a even more mandatory part of our lives.

Literally physically mail them a encryption key generator required to update their game. The encryption key generator can cycle passwords based on the date time.

Edit: Or at the very least have the developer whitelist a ip address from which to authorize updates, or have valve put a temporary deposit in their back account between 1 and 99 cents and have them verify by disclosing the amount stated.


Last edited by ElectricPrism on 13 October 2023 at 4:44 am UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register


Or login with...
Sign in with Steam Sign in with Google
Social logins require cookies to stay logged in.