Instalar Steam
iniciar sesión
|
idioma
简体中文 (chino simplificado)
繁體中文 (chino tradicional)
日本語 (japonés)
한국어 (coreano)
ไทย (tailandés)
Български (búlgaro)
Čeština (checo)
Dansk (danés)
Deutsch (alemán)
English (inglés)
Español de Hispanoamérica
Ελληνικά (griego)
Français (francés)
Italiano
Bahasa Indonesia (indonesio)
Magyar (húngaro)
Nederlands (holandés)
Norsk (noruego)
Polski (polaco)
Português (Portugués de Portugal)
Português-Brasil (portugués de Brasil)
Română (rumano)
Русский (ruso)
Suomi (finés)
Svenska (sueco)
Türkçe (turco)
Tiếng Việt (vietnamita)
Українська (ucraniano)
Comunicar un error de traducción
Normas y directrices sobre discusión
Denunciar este mensaje
We immediately reviewed our services that use log4j and verified that our network security rules blocked downloading and executing untrusted code. We do not believe there are any risks to Steam associated with this vulnerability.
The early discussions about this issue mention Steam specifically, but they were talking strictly about the server side — not the Steam client. It appears the initial reports were using "a DNS lookup occurred" as enough to indicate a potentially-vulnerable system. However we were able to confirm that Steam servers were not at risk of running untrusted external code via this log4j issue.
"IMMEDIATE ACTION REQUIRED: Uninstall Valve Steam Software to mitigate CRITICAL Log4j Vulnerability"
I don't know if they actually detected a vulnerability, or just did a scan of installed software and Steam is not on their approved list. I uninstalled it; I will be wiping this machine and turning it in next week anyway.
I think that was kind of silly
1) The researchers indicated the steam website was vulnerable not that the client itself was
2) I assume your IT director has some kid playing Java minecraft and somehow paniced that Steam used Java (despite you know like it doesn't come with a JRE???)
3) Id be wary of an IT director giving that kind of directive, because it kind of shows they are
a) irrationally reactive
b) technically incompetent
These are things I don't want any IT director to be
As indicated by the valve employee above, the researcher have to set up a proof of concept exploit without actually exploiting or runnign code locally as that would be a gross violation of security research protocols (you don't atively try to exploit someone that you aren't giving heads up to)
Thus I think what they likely did was send the command to "do a dns query to this website" this would be fairly innocuous, be allowed through firewalls, but would not actually do anything on the target system. But you'd see "aha this system actually responded to our request". So you'd know the site was running a exploitable version of log4j.
But what would happen in the real world is that the command would try to download and then execute a command locally. Because the edge firewall would reject the download itself, while yes the system would technically execute the command sent in the exploit, it wouldn't actually download the payload meaning nothing actually would happen on the servers.
This is similar to how Valve dodged HeartBleed. Valve encrypts your password BEFORE it goes over the HTTPS tunnel. So while yes, Valves servers were vulnerable to HeartBleed, attackers couldn't see anything useful because your password was encrypted. Sort of ironically there was a thread on the old forums where people were wondering "why do you encrypt the password when its going over an HTTPS tunnel, that seems redundant"
I have a very low opinion of almost anyone with a 'C' in front of their title. (this is a *big* company) But there's not much I can do about it.
My reading of that post was to assuage fears of “could someone have hacked valve in the time before patching” and that their interm filters made the exploit more difficult to execute anything useful and thus the probability of the exploit being executed is extremely low between the time of the announcement and when their servers were patched
I don’t think it was “well the edge filters are there so we don’t need to do anything”
Good news thanks.
Its easty to test the exploit on Minecraft because you can download your own client and server and destroy whatever you want on it. You're not impacting MS directly you're destoying your own client and server. That's totally fine.
What you don't do is try to test your vulnerability on a system you dont actively control. Such as the search field on a website.
I feel like you don't actually understand how this vulnerability works or what log4j is if you're talking about Chromuim.....
Look I don't really know why you'd say that because I am very very sure I was spending an entire week trying to patch OpenSSL on dozens of LInux machines, linux based appliances. Unless you're telling me the myriad of vendors that were literally throwing patches into my face demining I install this RIGHT NOW was an illusion. HeartBleed was most definitely a major problem on Linux
This is sort of compounded by the fact that while the steam client and CUSTOMER facing websites used encrypted passwrods in the tunnel, the B2B partner website didn't do that and that site had to be changed very quickly