- cross-posted to:
- security@lemmy.ml
- cross-posted to:
- security@lemmy.ml
You must log in or register to comment.
Wow, an article full of fear mongering with zero explanation of how it works.
Not saying it isn’t a real concern, but how it works is crucial for understanding mitigation approaches.
The full details of how it works will probably not be public yet in order to protect people who haven’t had a chance to patch yet
It’s a zero user input, remote code execution exploit that doesn’t require direct physical access—that pretty much means anyone with WiFi is at risk until they patch
Agreed.
The exploit was discovered by a security research firm who did the right thing and reported it to the SW creator, giving them the opportunity to distribute a patch.
Since it hasn’t yet been reported as being exploited “in the wild” publishing details on how to perform the exploit would be at best negligent, and worst carelessly malicious.
As someone else said there seems to be no public details. “Improper Input Validation” is about all the info given MSFT Source. It has also been reported a packet has to be sent, suggesting either being on same network or some kind of handshake issue (Source 1 Source 2). It is also said to evade conventional methods (like firewalls and canaries) so I have doubt you actually do need to be on the same network first. So If I had to guess there is some kind of issue with nearby share or wifi direct, since it affects sever versions also I can only assume something in the wifi direct implementation. Since input validation is mentioned and wifi direct can use pins, I would imagine there is some way to craft a special wifi direct packet that holds codes and windows just runs it and/or passes validation. I am just shooting in the dark but I don’t see mitigation short of disabling wi-fi or updating.
