Correct you have to erase/delete/overwrite security related information fields the moment you are done with it the first time, you recalculate it again if you need it later on. That is exactly what newbies forget when they rely on the garbage collector.
A GC'd language is far less likely to allow access to the heap though (it takes a bug in the compiler/runtime). So that's still better than delete in C++.
Good point there. The VM the language runs in is usually "as tight as a duck's ass".
Good point there. The VM the language runs in is usually "as tight as a duck's ass".
Not the case for the Adobe Flash VM. Operating system security was also a "solved problem" back in the 1970s with microkernels, but that doesn't mean there haven't been holes in any OS since. Performance always trumps security.
We were looking at this vulnerability at work last week. Thankfully many manufacturers are releasing patches.
As of 16/10/2017, Ubiquiti has issued a fix for its devices.
My wireless router is Rosewill brand. It cost less than $20 and is at least 5 years old. I doubt there's any point in even looking for a patch.
My wireless router is Rosewill brand. It cost less than $20 and is at least 5 years old. I doubt there's any point in even looking for a patch.
Possible LEDE code for two Rosewill models. LEDE 17.01.4 has the patch for this Krack vulnerability. I'm running LEDE 17.01.4 as of today on a router that I got for free because it was deemed too old.
lede-project.org/toh/start?dataflt%5BBrand*~%5D=rosewill
It's important to reiterate that although routers can be patched to mitigate the way this exploit is used, it is actually a client vulnerability. Patch your client devices.
It's important to reiterate that although routers can be patched to mitigate the way this exploit is used, it is actually a client vulnerability. Patch your client devices.
Absolutely but in more cases than not, this is not possible. I use around 9 wireless devices at home. Even my current Android smart phone is considered end-of-life and has been superseded with 2 newer models, so software updates are no longer being pushed to it over the air.
A few of them are old legacy laptops which haven't had driver updates for many, many years.
As for the rest of them, well, I'm at the mercy of the companies who designed them. Maybe they'll patch them, maybe they won't.
I use EAP on my Wi-Fi network at home so the issue isn't so much of a problem and on those "legacy" devices which don't support EAP, they are walled-in to a severely locked down part of my network.
That's where the biggest concern is surrounding this whole exploit, is those millions and millions of devices (think IoT) still in use which won't get an update. It's really not an issue for current hardware.
Despite the serious problems caused by stack/heap overflows, etc, this bug is much subtler and it's mostly an issue with the specification.
Fortunately it's not that the specification is wrong, the protocol is fine and it's been formally verified. It's just that the specification is incomplete.
Yesterday I came up for an example for a service note we sent to our customers. I'm sharing it here trying to clarify.
Imagine that someone pays you with a check. You have never seen one, so you are told to go to the bank in order to cash it. Banks, of course, are required to pay the check holder as long as the signature is valid and the account has enough funds.
So, we have a check paying protocol.
"Go to the bank, hand your check to the clerk and wait for your money".
Now, imagine that someone comes with a way to make perfect copies of a check. So, let's say two persons go to the bank with perfect
copies of the check. The bank clerks execute the check paying protocol, with the end result that two different persons have just cashed in the same check.
This is a problem, obviously, so someone notices that there is a vulnerability in the way checks are handled.
Let's look at it in more detail. We have a simple prototol for cashing checks. "Hand your check to the clerk and wait for your money".
Along with this protocol, the bank does some amount of internal processing. But that's not necessarily written down in the standards
for handling checks because it can be more or less obvious and, of course, different banks might have different internal procedures. In order to ease interoperability it's often advisable not to specify in more detail than needed.
So how are banks handling the check in our simple, vulnerable example?
Internal procedure (vulnerable)
Clerk receives check
Clerk verifies signature
Clerk checks account
If there are enough funds, withdraws and pays to the check holder.
But we said there is a security problem in that internal procedure. So we fix it adding an extra step. If the check can be cashed
(signature was correct and there are funds) you add an additional verification: was that check number cashed already? If it was
not, you add a note to the customer's account stating that "check number XXXXXXX has been cashed" and you pay the holder. Now
you have a protection against duplicates.
As a second measure against this kind of problem, some body governing the banking industry updates it's guidelines/standards for
check handling, stating that checks are numbered and the check numbers should be verified.
Pretty obvious, it's a very silly example. But the purpose is to show how is it possible to say that the WPA2 protocol doesn't need to
be changed (the protocol that describes how to cash a check in the bank hasn't been altered, the holder does exactly the same) and only
the internal procedures have been changes.
What has happened with WPA2 is roughly the same. Some internal processing was too lenient. And it's not necessarily a case of sheer
sloppiness, but most probably being cautious. When dealing with standards and multiple manufacturers you have to be extremely careful about adding extra checks because you might end up with serious interoperability problems. Unless those checks are not specified in the standard you can't make some assumptions. Moreover, wireless networks are tricky. There are errors and retransmissions.
So, probably the WPA2 standard will be updated. According to the author of the discovery it should be, and I agree of course. The protocol itself won't change. Just the internal processing.
Hope it helps clarify the nature of this problem. Sorry if the example is too silly, but in this case the real problem lies in the boundary between regulated and unregulated behavior in communication standards.
Would a solution simply be that if a client "doesn't receive" the third unencrypted message (due to outside interference/tampering), rather than the access point replaying that message, abandon the connection attempt, disassociate the client, don't reset the counter and carry on as if it were a new connection?
Updated my Unifi AP last night. What makes this vulnerability extra bad though is that the clients need to be patched too, and as an admin you don't have full control over who is connecting to the network, so need a way to vet devices and make sure they too are patched.
Hmmm I thought only clients needed to be updated.
Hmmm I thought only clients needed to be updated.
No, there are multiple bugs. Clients have more of them, and are more affected, but the AP side is also a target.
Client patches are rolling out - my old Kindle Fire HD (2013!) just got updated - not just fixing Krack, but sneakily fixing a bug preventing it from connecting to any 802.11w enabled (even if optional) network. But wait, there's more! It actually implemented working 802.11w. On Android 4.4. Whoever put that through earned a beer or other beverage of their choice.
Is there any central list of AP and client devices subject to the Krack vulnerability and the state of patches for them? It seems to me that all devices currently being sold - or which were recently sold should get patched.
Is there any central list of AP and client devices subject to the Krack vulnerability and the state of patches for them? It seems to me that all devices currently being sold - or which were recently sold should get patched.
So far, this is the the best page I found that collects all the vendor info and patch releases:
https://github.com/kristate/krackinfo
No, there are multiple bugs. Clients have more of them, and are more affected, but the AP side is also a target.
Quoting from
https://www.krackattacks.com/#faq which is the authoritative source:
"What if there are no security updates for my router?
Our main attack is against the 4-way handshake, and does not exploit access points, but instead targets clients. So it might be that your router does not require security updates. We strongly advise you to contact your vendor for more details. In general though, you can try to mitigate attacks against routers and access points by disabling client functionality (which is for example used in repeater modes) and disabling 802.11r (fast roaming). For ordinary home users, your priority should be updating clients such as laptops and smartphones."
Which means: unless you are using client functionalities in your APs (802.11r fast roaming or WDS) the attacks described in that paper won't work against the AP. The main priority is to patch clients. They say that they are working on possible modifications to the behavior of the APs so that they can somewhat protect clients, but that's tricky and it can lead to incompatibilities.
Well, I guess it's time to install a community version of Android to keep using devices that aren't officially getting updates anymore.
Well, I guess it's time to install a community version of Android to keep using devices that aren't officially getting updates anymore.
I just did that for 3 of my tablets at home using lineageos.
https://download.lineageos.org/I checked the release notes to make sure they had the patch before installing.
Obviously, not all Android devices are supported.
Yeah, not all, but still quite a lot. I wish they had the 2012 Nexus 7.
There is an unofficial build for that over at XDA.
Thanks, Monkeh and retiredcaps!