Slashdot Mirror
Microsoft Has Already Fixed the Wi-Fi Attack Vulnerability; Android Will Be Patched Within Weeks (theverge.com)
Microsoft says it has already fixed the problem for customers running supported versions of Windows. From a report: "We have released a security update to address this issue," says a Microsoft spokesperson in a statement to The Verge. "Customers who apply the update, or have automatic updates enabled, will be protected. We continue to encourage customers to turn on automatic updates to help ensure they are protected." Microsoft is planning to publish details of the update later today. While it looks like Android and Linux devices are affected by the worst part of the vulnerabilities, allowing attackers to manipulate websites, Google has promised a fix for affected devices "in the coming weeks." Google's own Pixel devices will be the first to receive fixes with security patch level of November 6, 2017, but most other handsets are still well behind even the latest updates. Security researchers claim 41 percent of Android devices are vulnerable to an "exceptionally devastating" variant of the Wi-Fi attack that involves manipulating traffic, and it will take time to patch older devices.
Either put a fucking CVE number or description of what the actual bug is in the damn title or sod off. thanks.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion. -- Spazmania (174582)
Reading the comments on the previous article, it sounds like this attack involves an attacker creating a fake AP that masquerades as the real one, then exploits message 3 of the WPA2 handshake. However, there were some comments indicating that APs might need to be patched. How would an AP be vulnerable to the attack, and why would they need to be patched? Should I expect that I'll need to upgrade my router's firmware to fix this? I'm confused because it sounds like the issue involves vulnerable clients.
Also, why would Android require weeks to patch, especially because the attack was confidentially reported to vendors two months ago? This seems like a failure of Google to adequately fix vulnerabilities.
That patch is gonna do so much good laying around at your release server.
MS just fixes a bug?? No "We're evaluating if that can be practically exploited", just "fixed, done"...?
A WiFi attack allows one to manipulate a website? That escalated quickly.
Oh, just /. editors' normal approval of bunk write-ups.
Yep, I never spell check.
More incorrect spellings can be found he
The article wasn't quite clear? Made it sound like it was all, already taken care of... but didn't quite specify when that patch was released?
Won't make a bit of difference if the access points are still vulnerable.
After those weeks it will take for google to patch it, add in several more weeks for the manufacturer and then yet more weeks for the carriers..... if they decide to do it at all.
I bet they fix it in macOS 10.14 "Sierra Madre" and iOS 12!
So now most Android devices are, and will continue to be, vulnerable to both BlueBourne and WPA2 KRACK, meaning that essentially they are wide open to anyone pilfering whatever they want off the device itself and as they communicate over the air. With most manufacturers abandoning updates in 3 years or sooner, and for the small pool of supported devices having very infrequent updates available, many times 3-6 months behind the curve, why do we allow this kind of chronic insecurity?
It's insane that we allow businesses to behave like this: Give everyone computing devices they use to run their lives - healthcare, credit, banking, social, BYOD work, etc. and leave them open like Swiss cheese.
So Microsoft "patched" this by not properly implementing the phase 3 handshake re-transmit as it's required in spec of 802.11i from the start.
Windows rejects retransmit requests, causing the attack to fail.
Android Will Be Patched Within Weeks
What percentage of Android will be patched?
The 18% with 7/Nougat or better,
the 50% with 6/Marshmallow or better,
the 78% with 5/Lollipop or better,
the 92% with 4.4/Kitkat or better?
https://developer.android.com/...
You're leaking smartquotes, bro.
There is no XUL, only WebExtensions...
As a Nexus 5 owner, I'm not holding my breath on that being a true statement.
Sounds like a good fix to me. Instead of accepting retransmits, it's safer to restart the entire handshake.
This is a trolling effort worthy of the legendary posters of yore!
+5 Inciteful
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
I guess that explains why my Win10 box rebooted by itself two days ago.
#DeleteFacebook
I use linux all the time, for work, at home, etc... But I have to say, Microsoft is catching up: They have office365 working perfectly on Linux (I just wish they could sort out Skype, it's a mess). And now this, they're patching faster than google? There's been a ton of time for them to fix it (really, like months), and google has yet to figure out how to solve the issue. It's pretty bad. If you own an android device, there's just no way to know if you're safe or not. I understand android is open, but wait a minute: you don't just build a phone and get android and the google play, there are special requirements (read: money, money) to get the store. So somehow they can get you to sign stuff so you can have google play, but security patches? no, they just don't care. Yep. It's sad.
"The key negotiation process needs to allow for the possibility of radio interference, so it permits the access point to re-send the message that is step three of the handshake. If an attacker sends a copy of this message, the client device will be tricked into reverting back to the original encryption key and initialization vector used at the start of the session. The client's next transmissions will have been encrypted with the same key as earlier transmissions, even though that key was only meant for a single use. That allows for a key reuse attack, which doesn't directly expose the underlying encryption key but does make it relatively easy to decrypt the data that was encrypted, especially if something is known about the structure of the messages that were both encrypted with the same key. IP packet headers, in turn, provide exactly that."
Yes, if the phase 3 handshake re-transmit required by the specification inherently enables a key reuse attack, then the flaw is not in the implementation, but the specification itself, and security would dictate that one refuse to enable that portion of the specification. Losing the ability to initialize a connection in a high RFI environment, which most installations attempt to avoid and mitigate, is an inconvenience. Having your traffic snooped is quite a bit more of an issue.
From what I understand, the attack is on the router, forcing it to re use known keys for encryption. How do the client devices fix this issue?
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Has MS patched dnsapi.dll for Win8-10 (local DNS cache = bad)? Win7 = unaffected (best one & why I use it) https://www.bishopfox.com/blog/2017/10/a-bug-has-no-name-multiple-heap-buffer-overflows-in-the-windows-dns-client/
* Anyone wonder WHY I use hosts files in combination w/ OpenDNS (patched vs. kaminsky redirect poisoning) vs. UNPATCHED remote DNS or unpatched ISP dns (99++% aren't patched vs. kaminsky redirect poisonings)?
Don't wonder why after reading the above...
APK
P.S.=> For more speed, security, reliability & anonymity online accept NO substitute for APK Hosts File Engine 9.0++ SR-7 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/ ... apk
wpa (2.1-0ubuntu1.5) trusty-security; urgency=medium
* SECURITY UPDATE: Multiple issues in WPA protocol
- debian/patches/2017-1/*.patch: Add patches from Debian jessie
- CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080,
CVE-2017-13081, CVE-2017-13082, CVE-2017-13086, CVE-2017-13087,
CVE-2017-13088
* SECURITY UPDATE: Denial of service issues
- debian/patches/2016-1/*.patch: Add patches from Debian jessie
- CVE-2016-4476
- CVE-2016-4477
-- Marc Deslauriers Mon, 16 Oct 2017 08:20:18 -0400
Compared to these, I miss the GNAA trolls from years ago
Keep in mind that part of the reason these radios are NOT re-programmable is because of government restrictions concerned with out of band operation. One of the side effects of that is lack of documentation for ensuring the radios work correctly, or nowadays signing of the firmware so you can't reverse engineer/patch it when the problem is possible to mitigate at the device firmware level, or worse yet REQUIRES device firmware in order to mitigate.
Computer firmware needs to be user serviceable for exactly this reason. *ALL OF IT* Anything less is just expecting compromise sooner or later because the attack surfaces are so high.
Furthermore, I have little doubt this will come out as a government backed spy attack. The fact that the vulnerability exists across multiple platforms and devices implies that this wasn't just a common development mistake, much like the bluetooth issue. This was the intent of these standards, and likely of the Infineon smartcard issue as well.
It's not just the phones, tablets and computers that need to be updated. Since it's clients that need to be patched it's everything that connects to the network. Thermostats, scales, TVs, digital photo frames, ...
There appears to have been a new nwifi.sys in the Oct 2017 rollup.
Unless the patch was deployed before the vulnerability was exposed, the word "already" shouldn't be in the headline.
What smartquotes? Those are the most stupid things that ever was invented since they screw up code examples royally.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Hopefully it doesn't just drop the IP session. That would really suck if occasional packet loss causes a forceful oplock dismount on an SMB share.
See subject & M$ "hardcodes" in addys in tcpip.sys resolver (not dnsapi.dll, see below as to how/why) it's 4 WinUpdate (so can't be blocked): NOT SAME!
* I don't even HAVE dnsapi.dll turned on & I still cannot block windows' update servers in hosts OR firewall!
(dnsapi.dll local clientside SLOWER usermode buggy service is shut off here to save CPU & other I/O wasted on a busted piece of shit that fails w/ LARGE hosts files - which LINUX HAS NO ISSUE WITH, only MS - & also per this bug I am noting)
APK
P.S.=> A bug I caught MS in? MS SENIOR mgt. for Windows "Client Performance Division" conceded to me https://slashdot.org/comments.pl?sid=1467692&cid=30384918/ HAVE THEY FIXED IT? No. DID THEY EVEN PRODUCE A VALID ANSWER FOR IT?? NO - & I've seen some STUPID DESIGN (hearsay) that 'allegedly' says 127.0.0.1 & 0.0.0.0 aren't SAME on client workstation OS vs. server class OS (wtf? Now THAT is inconsistent design IF true!)... apk
OK, so how do I check whether a system has been pwned via any of these CVE's before being patched? openBSD provided system updates that essentially leaked the vulnerability, and government agencies have known for at least two months, not to mention everyone that they notified. Of course, we all have complete faith in the fidelity of our beloved United States government and all commercial corporations - they've never let us down.....
Does anyone have utilities that checks all system programs and critical files via digital signatures against the versions that are supposed to be there? Bonus points if it identifies out-of-date programs and suggests updates. Let us ignore for now the possibilities that (1) the system has been pwned so cleverly that such utilities can be fooled (2) the utility installs a backdoor that pwns the system and reports false signatures, as (3) open-sourcing the utility is a basic requirement for transparency, or many independent versions could be easily written given an appropriate database...
The database of file signatures is the important part, and can be quickly developed from one or more clean installs (multiple installs to catch variable files). I'm already aware of signatures used to validate updates, but this is for validation of existing systems. Presumably a list of files not covered by the database is a starting point to complete the system validation.
A little searching turned up machinery-project.org - anyone familiar with that, or can suggest other tools?
So says the Microsoft shill shitposting on /.
... and first than MS, but I think they're not paying media like TheVerge to share this.
Yup. Once again we see how closed source professional development results in faster, more usable and more importantly more SECURE code than "open" source stuff made by amateurs and hobbyists.
Another reason for using this great Android distributions.
Do not cry, but vote with your pocket, and always buy and run devices supported by the community.
Please stop crying for fast updates and put your money where your mouth is... you could buy only smartphones with good community support.
You can take a look at the list:
https://wiki.lineageos.org/devices/
"within weeks". Epic customer support.
I think Jared updated the pedo profile. s/cheetos/subs/.
Let's be honest... Android devices will not be patched in weeks... a few in months, but 90% never.