Don't you only need to patch one end of the communication? Eg if phones are patched, they're safe, even if the AP is not. Then again, I didn't read the attack fully, this might be a client-only problem.
My understanding is that only the light bulb's traffic will become decrypted. If you see it go from blue to red, without your consent, then you'll know. Otherwise, the Wifi password is still safe.
It's a pity this didn't completely break WPA2 like how WEP was broken, now it will be years before there's any new security developments. Things like management frame authentication and dynamic client keys for open networks would be big improvements for the majority of use cases.
Somewhat pointless remark as WPA only protects up to the access point. Any vulnerability after that has wider implications regardless of the WPA status.
At its worst, this attack reduces a protected network to an open wifi, yes.
The risk is that you may do things on a protected network assuming it really is protected - this is more of a thing for organisations rather than consumers, for example organisations might have unprotected services accessible over their office wifi.
Note that in the demo video they use SSLStrip to cancel attempts of websites to switch to https.
The only protection here is HSTS (which is not enabled by most websites, but major ones like banks will usually have them) and manually typing https:// in your address.
I think it's a nice plugin until you forget that you're using it and you rage for minutes/hours trying to understand why you can't access some website.
It might be worth it.
I remember spending hours trying to figure out why Google Adsense wouldn't render correctly. In the end I figured out that it was Adblock's fault :))
This only applies to websites which land on a plain HTTP page and then load links to HTTPS pages. Entering “ https:// “ explicitly before any URL accessed will fully mitigate this.
Is there a way I can install an open source phone OS on my old Android phones to keep them patched? I'm not prepared to keep buying new phones just because manufacturers only provide intermittent updates for a year or two.
LineageOS has a moderately large selection of supported phones for a custom ROM and it has weekly updates. My two and a half year old Moto E has the October 5th security patches for Android.
Look through the list yourself, but at least on my device, most of those kernel security issues aren't really of significant impact as apps don't have access to the APIs needed to trigger them and they're not remotely exploitable.
> I'm not prepared to keep buying new phones just because manufacturers only provide intermittent updates for a year or two.
You could just ... buy an iPhone and get timely security updates for years.
EDIT: Downvote if you want, but if iOS 11 contains this security fix exclusively and not iOS 10, then an iPhone 5s bought on 20 September 2013 is going to get this fix. If Apple release an iOS 10 update and you bought an iPhone 5 on 21 September 2012 you're covered too.
In principle yes (if it is not against the app store guidelines). But if submitted as an app, it cannot use JIT compiling for security reasons. This will make the speed of JavaScript execution very non-competitive to WebKit.
Apps should be self-contained in their bundles, and may
not read or write data outside the designated container
area, nor may they download, install, or execute code,
including other apps.
So your can't ship a JS interpreter either, even without a JIT.
And section 2.5.6:
Apps that browse the web must use the appropriate WebKit
framework and WebKit Javascript.
So you just can't have a web browser not using the built-in WebKit, period.
As far as I can tell, you can install a web rendering engine that is not the built-in WebKit, as long as you only use it for HTML/JS that come with your app. At that point the JIT caveat applies.
You can ship a JS interpreter, it just can’t download code from the internet and run it (yes this makes shipping a browser in the App Store impossible).
But regardless, with your own device, you can run whatever code you want on it.
Even for a more modern smartphone. I don't want to lose access to my 32bit apps by migrating to iOS 11. So I hope a patch for iOS 10 will be made available.
Not the OP, but I just lost access to FlightTrack which was an awesome flight search and status monitoring app that could even pull your itinerary from TripIt.
Having switched to an iPhone recently it does bother me that you can't download iOS updates via 4G. When this gets fixed I need to turn on wifi first (or install iTunes).
I'm using https://lineageos.org/ (previously known as CyanogenMod) on most of my older Devices. I think this is as close to an open source OS as you can get right now.
Depends on the phone. I'm using a ~ 4 year old phone with LineageOS. I also have a Russian phone whose userland source code was never released, and no open source ROM exists; this phone is swimming in vulnerabilities and languishing in Android 6.
Unfortunately, Google has given app developers a quite powerful tool to disable the use of their apps on non-official OS images, in the form of SafetyNet. So even if you can install an open source version of Android expect a bunch of stuff to no longer work afterwards.
Magisk (/system/less root) currently passes the SafetyNet checks and it, and it's MagiskManager App, are both FL/OSS and hosted on github [0] as well as pre-built images linked from XDA [1].
I'm using it successfully with LineageOS 14.1 (Android 7.1.2).
Not really - ultimately they're root, Google SafetyNet isn't, it has to run at the application level. Meaning Magisk will always win until remote attestation is enforced. There hasn't been a breaking update since July if I recall correctly and the Magisk developer had it patched in about a day.
SafetyNet is not about "official" status, it's about security checks.
I'm actually persuaded that I don't need terminal root access on a device (except for system debugging), but rather a firmware signed with my own release keys, and apps that need privileged access baked in.
SafetyNet doesn't actually detect custom ROMs, a stock LineageOS will pass it on most devices at least.
It attempts to detect root or modifications to the ROM by malicious software.
Certain newer devices have secure boot attestation that may cause SafetyNet to fail unless spoofed to be a different device which does not have such attestation.
No. It only cares about unlocked bootloaders on devices that shipped with Android 7 because a requirement of shipping with that was hardware support facilitating dm_verity, which is essentially a check that the bootloader wasn't tampered with. Without the necessary hardware there's simply no way to perform this check in anything resembling a reliable fashion.
Also, neither root not an unlocked bootloader is required to make "proper backups". Some data actually can't be backed up, and for some data there is no point in making a backup. If the goal is to be able to restore the system to a specific, known state, a bit-for-bit image backup of the entire filesystem is just one way to accomplish the task.
> No. It only cares about unlocked bootloaders on devices that shipped with Android 7 because a requirement of shipping with that was hardware support facilitating dm_verity, which is essentially a check that the bootloader wasn't tampered with. Without the necessary hardware there's simply no way to perform this check in anything resembling a reliable fashion.
So in other words "yes, that is a requirement that will eventually be on all android phones"? Am I misunderstanding something? Older phones being an exception does me little good going forward.
> Also, neither root not an unlocked bootloader is required to make "proper backups". Some data actually can't be backed up, and for some data there is no point in making a backup. If the goal is to be able to restore the system to a specific, known state, a bit-for-bit image backup of the entire filesystem is just one way to accomplish the task.
The last time I tried adb backup and restore, it was a mess. Multiple apps like Skype had no data. And authenticator explicitly opts out of being backed up.
Titanium backup, on the other hand, works perfectly.
Ideally I would just have a rooted phone, but then safetynet complains, and I can't even use Netflix and pokemon. As an alternative I could accept an unrooted but unlocked phone, and root it only when making and/or restoring backups. But having neither is a big hassle.
> So in other words "yes, that is a requirement that will eventually be on all android phones"? Am I misunderstanding something? Older phones being an exception does me little good going forward.
To date it means that it's very possible to bypass any protections put on this though - I believe this may even be possible without spoofing the device in this way, but in any case, Magisk works on any device available today.
It seems that OpenBSD already patched their source code and that wasn't to the likings of the researcher. In the future he will now delay notifying OpenBSD of vulnerabilities.
Why did OpenBSD silently release a patch before the embargo?
OpenBSD was notified of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: "In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging". Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.
What about the vulnerabilities that OpenBSD notice? Works both ways. And they have an active interest in such things and have discovered as much as any famous-for-five-minutes security researcher.
> [OpenBSD] have discovered as much as any famous-for-five-minutes security researcher
TL; DR OpenBSD acted rationally if they'd prefer to go it alone, which seems to be their culture. To their credit, it's worked pretty well so far. But you can't have your cake and eat it too. If they prefer a mad scramble after public disclosure, they'll get it. But they shouldn't get early notice from responsible researchers.
> OpenBSD won't get notified about vulnerabilities until well after everyone else
Which doesn't make a difference if OpenBSD still gets their patch out at the same time as everyone else. Unlike other vendors, it doesn't take OpenBSD four months to go from vulnerability notification to patch release, if you look at previous disclosure timelines they typically have a patch out in days.
It sounds rather like he is trying to blame OpenBSD for his own mistake. As multiple people from OpenBSD have said, he agreed they could apply the fix, so they did. He didn't have to say they could. The fact that CERT persuaded him to extend the embargo later is not their fault.
True, they don't. However, this researcher has the authority to not notify the openbsd team in advance any more and he already announced that he'll keep his cards closer next time. What happens if sufficient researchers come to the same conclusion?
What happens if a vendor or researcher is in bed with the NSA and they use the exploit while embargoed?
The whole thing is a shit show and really I'm rather more behind OpenBSD's approach.
Edit just to expand on this as someone deleted a post ....
----
It's slightly more complicated than the prisoner's dilemma. The prisoner's dilemma doesn't account for a large facet of the problem which is being discussed here. If all the good parties participate and coordinate then we're better off. The problem is there are outlying circumstances which means that not everyone will be included:
1. If someone kicks someone out (OpenBSD) on political whim playing CYA, they no longer benefit.
2. If a party is not let in, they no longer benefit.
3. If someone is unaware of it, they don't benefit.
This turns it into a security monopoly where the big vendors get exclusive rights to embargo and exclude smaller vendors and control the disclosure process on their own schedule.
The first thing the people outside of the club find is they wake up on Monday morning and have to clear up a shitstorm of monumental proportions with less resources than the monopolised vendors who've had time to deal with it.
Then there's the assumption that the monopolised vendors are trustworthy which is 100% impossible to validate and therefore invalid.
Yeah, the hysterical part is how people think distros is leak proof. It just doesn't leak in nice public ways to allow "responsible white hats" to wag their fingers. Raise your hand if you can say you confidently know the full back channel distribution of a notification to distros.
Ultimatum games [1] are a subset of prisoner's dilemmas. That covers Nos. 1 and 2. Assuming researchers want something from those they disclose to, it makes sense for them to cast the widest net possible while minimising the risk of defection. Balancing that optimization is a game as old as civilization.
> This turns it into a security monopoly where the big vendors get exclusive rights to embargo and exclude smaller vendors and control the disclosure process on their own schedule.
Not necessarily. It turns into a monopoly of those who can show themselves to be credible partners. This exhibits incumbency bias which in social context we call track record. It's not nearly as exclusionary as you're making it out to be.
> Then there's the assumption that the monopolised vendors are trustworthy which is 100% impossible to validate and therefore invalid
This is common in trust problems. You don't need to be 100% sure everyone you're dealing with is trustworthy to work with them because we don't live in a single-iteration game. Again, iterations of retaliation and forgiveness remove the need to have 100% certainty about a player's intentions.
They were pressured by OpenBSD to do so, and regret it. That doesn't mean they broke embargo, but it also doesn't reflect well on them. Do you think Theo would've respected the embargo if they had said "no, do not patch until the embargo date?"
Sounds like the researcher is at fault for putting OpenBSD on their list. If you cut a deal with someone who serially defects, at a certain point the onus shifts from them to your lack of foresight.
The problem isn't a "fool me once shame on...fool me you don't get fooled again", because the problem is one unscrupulous party is unscrupulous to different parties and the different parties at different times are unaware of it.
> the problem is one unscrupulous party is unscrupulous to different parties and the different parties at different times are unaware of it
Sure, but eventually you get called out on it in a public forum, like this one, and people stop giving you goodies going forward. I would consider it acceptable practice to, when considering dealing with OpenBSD (or people who are close to them), (a) withhold vulnerabilities until after the embargo date or (b) refuse to give any information unless they sign a binding non-disclosure agreement committing them to the deadline under pain of penalty. (The latter is an option because it appears, in this case, they broke the spirit if not letter of the agreement. The solution to that problem is legalese.)
To be clear, I accuse you of nothing less than playing a rational response to the researcher's apparent "always coöperate" strategy. "Defect" in a prisoner's dilemma context does not mean "breach" in a legal one. (For example, an OPEC member defecting has zero legal consequences. It does, however, affect their standing in the next round of negotiations.)
'Defect' doesn't mean 'breach' in a legal situation, it also doesn't mean 'sociopath and/or economics professor' in a psychological one, but people form connotations, so be careful what you accuse. Anyway I think you're playing the PD analogy too much... But I'll play a bit too. Construct a payoff matrix. What does real defection look like? It's patching mid-July, when the patch was received, instead of waiting to the agreed upon end of August time. I see no defect here. There could only be one if, after CERT was involved and set a new date, Mathy asked OpenBSD to postpone the prior date agreement, and instead of cooperating they patched immediately for the biggest gains to their users. There is no mention of such a request, hence it probably didn't come.
The researcher's reaction is correct. OpenBSD maintainers' lack of patience may have led to this vulnerability being discovered and exploited by other people.
As far as I understood, this attack has no client-side mitigation that could be employed other than treating every wifi as an open network. The attack might already be known to hostile actors or may have become known during the embargo, but full disclosure without an embargo would guarantee that clients are at risk without mitigation. An embargo at least gives time to prep patches and protect at least a portion of the clients.
Either there is a possibility for patches to be prepared during an embargo or there is “no client-side mitigation”, you can’t have both. From reading the rest of this thread, it appears that it is quite possible to patch this on clients such that, if you are using a patched client, you are safe. Disclosing earlier would have lead to more people having patched clients earlier and hence being safe.
Patching the client is a fix. Mitigation would bea config setting that makes me safer (disable some unused functionality,...). So yes, you can have both.
That’s like saying that prior to introducing seatbelts, we should have allowed for a period of time to glue people to their seats because it is preferable to have a mitigation they can apply themselves than a fix the manufacturer has to put in.
If you don’t limit mitigation to "a config setting" (and why would you?!), a patch/new version is the best mitigation you can get.
I limit mitigation to a config setting because that’s what affected clients can do in this case. Everyone patching wpa_supplicant on their android handset is just not going to happen and it takes time for vendors to roll out patches.
> As far as I understood, this attack has no client-side mitigation that could be employed other than treating every wifi as an open network.
I've been doing that for years and recommend others do so as well.
The rise of HTTPS nearly everywhere helps mitigate things a bit. This same type of exploit 5 years ago would wreak havoc exploited at the local Starbucks WiFI.
In other words, its malfeasance by the security community for holding out.
There's only a few courses of actions. One is to sit quietly and let everyone eventually do the solution. And that doesn't work. No fire under peoples' asses, and the work is delayed.
The other, is to release it promptly. Then, at least we can decide to triage by turning down X service (even if wifi), requiring another factor like tunnel-login or what have you.
But truthfully, defect in a Prisoners Game played out here was the best choice. The rest of the community is "agree".
No one should care about a community that agrees that releasing silent patches is a good idea. This is exactly the same behavior that created the need for full disclosure in the first place. And no, there aren't just two options nor are processes binary. It's rather mind boggling how "the community" has managed to go full circle in such a short time and themselves become the opinionated people they were supposed to be the alternative to.
You got everything wrong. If big vendors are unable to patch their proprietary products in an acceptable time, that shouldn't put others at risk. Users shouldn't choose their products...
Think about it in a different way:
What if a vulnerability was discovered in TLS and FOSS implementations patched it, but there is an embargo for supposedly protecting some banking software? What if NSA/CIA/other agencies find out about it (they would know immediately) and use it to target users/activists?
This is why embargoes have deadlines. To make the necessary trade-off between "patch as soon as you can, potentially jeopardising the safety of users -- even users of non-proprietary projects" and "wait for everyone to be ready before you patch -- which also jeopardises users". The embargo system deals with this by forcing everyone to agree on a date, and if someone patches after that date then too bad. You may disagree that the deadline was so long, and that could be a fair criticism.
But pretending as though co-ordination of any kind is somehow bad (and then resorting to emotional arguments and so on) is pretty reckless.
3 months is more of a joke than a reasonable time, but one can argue about that if he wants...
> even users of non-proprietary projects
Actually many FOSS projects get only notified on the disclosure date.
Hiding the vulnerability for such a long time makes more harm good. The vulnerability can potentially be exploited by security agencies that necessarily know about them and could also be leaked to a bad actor by an employee of one the vendors.
Hopefully WPA2 isn't that important, but potentially security sensitive users trusted something that was known by some to be vulnerable for 3 months! Bad actors could have used it against them.
The embargo resulted in potentially bad actors knowing about the issue, but not vulnerable users.
The state actor should be least of your worries compared to the millions of script kiddies would could use the vulnerability once it is disclosed publicly.
For most of them the day after, when I get a notification from my RSS app...
No. I also don't expect them to choose device based on security. That is very bad as vendors won't care about patching their older devices (look at Android devices, home routers...) and vendors won't care about patching their flagship devices fast as they have the possibility to request very long embargos.
Making compromises for those vendors and giving more time for security agencies and other bad actors to silently exploit the vulnerabilities (where FOSS projects would have made patches for users that care) is not the way to go. That philosophy actually makes everybody less safe.
I have seen and participated in this disclosure debate for 10 years now. I have come to the conclusion that, in the long run, the least harm approach is full disclosure. There isn't any wiggle room. There are no shades of grey. The whole coordinated response movement is misguided. There are some limited circumstances where it can make sense to delay disclosure, such as creating an imminent threat to human life, but generally full and nearly real time disclosure results in safer software sooner for end users without putting them at some unknown, but high risk level.
What if [...] is FUD. What if Theo de Raadt works for the FSB? We need to work with the facts.
If you don't agree with an embargo and decide to break it, that's on you. But the consequence is that you shouldn't be surprised if next time you're informed later, or not at all. What OpenBSD proponents and developers are doing right now, is damage control. It may work this time, it may work next time, but it won't keep working every time so pick your fights right. It isn't the first debacle OpenBSD has with full disclosure either (hint: OpenSSH).
There are also millions upon millions of devices which won't get patched. Given the vulnerability is apparently the most vulnerable on Linux and hence Android, do you think all the smartphones running Android 4.3, 4.4, 5.0, and 6.0 will be patched [1]?
No, I don't. And its stupid, because it doesn't have to be that way. But telecoms have complicated the situation with their greedy firmware reinforced planned obsolescence.
This feels like some kind of prisoner's dilemma game theory problem. By defecting from the embargo, OpenBSD gained potential security for its users at the expense of all other users. Overall, this is a loss, unless you use OpenBSD. I have to agree with the researchers on this one; OpenBSD acted selfishly here.
Read that again. We asked to commit without revealing details, he said yes, that's what happened. I guess he changed his mind about that after the fact, but nobody promised not to commit. We didn't "defect" from an embargo unilaterally.
They agreed, but now they regret the decision and wouldn't make it again. To prevent themselves from doing so, they will not speak with OpenBSD until later in the process.
Now that it's more clear what role disclosure deadlines play in cooperating with security researchers, it probably makes more sense to just cooperate than point fingers.
Perhaps "defect" is the wrong word given the circumstances, but the result is the same. There's a good reason for the embargo: this all takes cooperation, as it's not a Nash equilibrium. I still agree with their decision not to include OpenBSD so early in further disclosures, given Theo's short-sighted statement.
It's precisely the correct word. Prisoner's dilemma are simple, mathematically. This was one. OpenBSD defected. The joke's on the security researcher, though, since this doesn't appear to have been their first time [1][2].
Robert Axelrod outlined, in his 1984 classic The Evolution of Cooperation [3] four requirements for a successful iterative prisoner's dilemma strategy. One is retaliating. Security researchers are letting OpenBSD play an iterating game as if it's an N=1, i.e. they're not retaliating. Given the community is playing "always cooperate," OpenBSD's best move is actually "always defect".
So does the simple mathematical treatment also include language like "the joke's on ____”? Or was that more of a philosophical interpretation of yours?
Both your [1] and [2] seem to conclude that violating the embargo had no significant ill effects: "since... the underlying issue was already publicly known, OpenBSD's commits don't change things much." If "defecting" causes no problems for the other participants, does it actually count as defecting? (And if not, how is this a mathematically simple prisoner's dilemma?)
From what I've read, I don't see why everyone is giving you a hard time about this. It sounds like you did exactly what he agreed you could do, and then he changed his mind.
It's a loss, even if you use openbsd. If you break the embargo, you won't be notified in advance anymore. Basically, you get an advantage once but will get several losses for a very long time. Overall it's bad, even for OpenBSD users.
Author doesn't know what FreeBSD, Debian and OpenBSD people cooperate and share knowledge, so most probably OpenBSD developers will know about the issues, just not from an "official" email.
Furthermore by not even attempting to include OpenBSD in some embargo agreement, there's no reason for OpenBSD to not patch as soon as they hear about it. Indeed that's what seems to have happened on the linked 'evidence' about them not respecting an embargo of a linux distro group they're not part of.
tedunangst: "We asked to commit without revealing details, he said yes" "I guess he changed his mind about that after the fact."
The patch has obviously an explicit description:
"State transition errors could cause reinstallation of old WPA keys."
It's true, however, that anybody who analyzes the diffs would eventually figure that out, as Theo de Raadt argued.
My conclusion is also that the real error was even wanting to give the details to him at that moment, as there's apparently a history of him not respecting embargoes.
I still fail to get what you wanted to express with your comment here. I've just quoted two sentences from another comment of yours on the same page, have you understood something else?
"Our attack is especially catastrophic against version 2.4 and above of wpa_supplicant, a Wi-Fi client commonly used on Linux. Here, the client will install an all-zero encryption key instead of reinstalling the real key. This vulnerability appears to be caused by a remark in the Wi-Fi standard that suggests to clear the encryption key from memory once it has been installed for the first time."
"Because Android uses wpa_supplicant, Android 6.0 and above also contains this vulnerability. This makes it trivial to intercept and manipulate traffic sent by these Linux and Android devices. Note that currently 41% of Android devices are vulnerable to this exceptionally devastating variant of our attack."
„submitted for review on 19 May 2017“ ... „OpenBSD was notified of the vulnerability on 15 July 2017“
Can anyone explain the timeline of releasing such significant security findings? Why is it disclosed to the public 1/2 year after submitting to review? I'd guess the (publicly funded) research behind it is a lot older than that.
From my understanding of research at public institutions there is a long period of time and steps between finding something interesting and submitting a paper for review.
Why not disclose the vulnerability first to concerned parties and then write up a fancy research paper? Why the other way round?
Only two explanations I could come up with: Either there must be a very short time frame between identification of the vulnerability and writing of the paper or there was further research needed. Or....I don't know
Vuln disclosure has historically been associated with vendors delaying and ignoring issues for a long long time. That's the whole reason FD came about. There's no confusion on my part.
Not really. As far as I can tell, the attack basically requires spoofed MACs anyway because the keys are derived in part from the MACs, so whitelisting won't get you much benefit if any at all.
This will fool your client (eg: your phone) to connect to it, before it reaches your access point, then forward packets to your AP (basic man in the middle).
On the other hand, I am wondering if it manages to correctly forward packages back to the AP if that has MAC filtering on...
Correct me if I am wrong but basically the attack is against clients, not access points which means simply patching the AP will not do, one would have to patch all of the clients. And the AP patches that are now coming in are probably for client mode, so they fix a certain scenario when the AP is a client which is far from the common one?
"This can be abused to steal sensitive information such as credit card numbers, passwords, chat messages, emails, photos, and so on."
As much as this is a scare tactic to get people to demand vendor patches, it's been true for https for a while.
Browsers don't have any trick (that I know of) to enforce https on first connection. HSTS is defeated by simply rejecting connections to https - the user will retry the site from different devices and destroy their hsts cache in order to reach the site. Assuming the site used hsts.
All major browsers implement a HSTS preload list[1] to get around the first connection problem. Manually deleting the HSTS pin for a site is quite involved and not something I'd expect most users to do.
Preload lists are not a realistic solution (you can't preload the whole internet) and a sufficiently complicated site will be subverted due to 3rd party dependencies. And does uninstalling a browser not clear the hsts cache?
You can't preload the whole internet, but by getting the top xx thousand you get 99% of all Chrome users traffic. Its not perfect, but it is very, very effective.
Perfect is the enemy of good. A large portion of sensitive traffic is protected by HSTS today, and the preload list compresses well. By the time it'll become a problem, we'll hopefully be at the stage where HTTP is treated as insecure anyway.
I'm not certain if uninstalling a browser clears the cache (do uninstalled browsers retain their profiles?), but preloaded sites would not be affected - they're included in the browser binary. Either way, let's not act like there's a massive hole in HSTS because there's a possibility that users might go as far as reinstalling their browser to visit a not-preloaded HSTS-enabled site that's being targeted.
I'm not saying it's a massive hole, i'm saying it's an easily preventable hole that the entire industry is ignoring for unknown reasons. One simple URI change could make HSTS obsolete and fix the hole with no need for awkward workarounds and half-measures. Nobody has yet explained to me why "good enough" is better than "fixed".
The research talks a lot about how it somewhat depends on the implementation of the wireless client, but only in regards to Linux and OpenBSD, anybody know what the status on the Windows implementation is?
I believe that the code for the 4-way/group key handshakes etc is part of Windows even in XP, though there was the option of using your own supplicant before Vista.
Quick googling found out that at least one guy did come very close to realizing that 4-way handshake should have hard replay protection: http://slideplayer.com/slide/5762070/
On page 30 of the presentation: "Authenticator may (or may not) re-use ANonce"
Stop panicking (unless you need your daily dose of the End of the World drama).
From the source: 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.
Some people don't want read all the articles and tend to panic. It's why if there's any security issue we need a list about action to reduce risk, when, how, etc. otherwise people still we dispute about it's feasible or not and then finally the journalist will explain how to fix the risk. I like to read the whole article but then sometimes it's very hard to check if it's truly feasible or it's just a panic mode, for example when wannacry come out the information was a mess.
As an Android user is there any mitigation for this other than ditching my handset and switching to an iPhone or waiting (hopelessly) for a patch from my vendor.
This really does highlight the absolute disaster zone that the Android handset market has become as far as updates are concerned. I'm sure the Pixels will get a fix relatively quickly but almost every other Android user is going to be left in security limbo.
This is one of those things that should be better with modern handsets and the security patch level for Android. Hopefully a fix for this is included in the November set.
In general most bigger manufacturers have been somewhat decent in updating their flagship devices. With a Sony flagship from the last 18 months for example, you usually won't run more than two months behind on security updates. Samsung is similar if I remember correctly. Hopefully a big exploit like this will be enough of a kick in the butt to get manufacturers releasing security updates faster.
I have a HTC 10, a flagship device that's barely a year old the fact that I now have to wait a couple a months for a patch to what is clearly a critical vulnerability is just ridiculous. The fact that anyone without a flagship device should now throw that phone away because it will probably never be patched is despicable.
I totally agree with your hope that this will kick both the manufacturers and Google in the butt enough to get something done about this. I don't like our chances though!
To underline your point, even my Nexus 5 (_from Google_), which is a little less than 3 years old, will never receive security updates. And one of the main reasons I chose the Nexus was to be sure to get updates on time. Except for the security vulnerabilities, everything of the device is totally fine. It's such a waste of resources… (In this case I at least have an alternative in the form of Lineage OS, which will only cost me time and nerves for the migration.)
You'd expect better from the horse's mouth, but most other companies are worse. I got a Fairphone 2 and my partner a Wileyfox Swift 2X. Both have very good software support thus far. Near monthly updates. Wileyfox phone is a bit new, but they got a good track record. Nokia (HMD) also seems to be back, this time with good software support (thus far). Compare that to Motorola.
Hopefully Android Orea 8 with Project Treble will stop this ridiculous trend for the rest of us. Together with the smartphone market being saturated (budget phones of 200 EUR are very decent these days), we may end up with long term support on older yet still decent devices.
The Nexus 5 was released 4 years ago. At the same time the iPhone 5C was released. The 5C also won't receive a patch for this.
There is a problem with handset abandonment, but this is true across all vendors, and it does not underline sequence7's claim that this is solely an Android problem.
To be fair, these two examples are both on the extreme end: The Nexus 5 being one of the longest supported Android phones on the market, and the 5C having a rather short support period, compared to other iPhones like the 5S, which was released along with the 5C and got iOS 11. Security updates for the Nexus 5 also stopped shipping about a year earlier. There's still room for improvement for Apple (5 years of security updates seems reasonable), but there's still a large gap.
We are 4-5 years into the period where people have had sub $300 choices, so there is an alternative to spending $500+ on a device that comes with 2 years of support. Maybe not a fantastic alternative, but the $300-$500 extra that people choose to spend says something about what they care about.
Has anyone ever taken a vendor to court on the basis of consumer rights and not providing security updates and the product therefore not being fit for purpose?
For example, under the Consumer Rights Act 2015 in the UK the product must last for as long as a reasonable person would expect it to, and Apple's interpretation of that is five/six years (see https://www.apple.com/uk/legal/statutory-warranty/).
I'm always tempted by this, I have time, I know people, but the thing is, you agree too far to many contracts by starting to use such a device, that just navigating the initial waters to find a path to sue anyone is a complete non-starter. I'm not able to tilt at this windmill. Hopefully the Purism phone succeeds and I can buy one. Till then ill keep buying a top of the line Apple phone each 4-5 years when support runs out.
> you agree too far to many contracts by starting to use such a device, that just navigating the initial waters to find a path to sue anyone is a complete non-starter
The Consumer Rights Act 2015 also covers unfair terms in sales contracts (and at least in Scotland EULAs are part of the sales contract, per Beta Computers (Europe) Ltd v Adobe Systems (Europe) Ltd; I don't know the status elsewhere in the UK), and it's quite likely you could just go through most of the possible contractual outs and argue they are unfair terms.
If it's anything like Australian Consumer Law, it's really really difficult to sign away those rights. In fact, even attempting to tell a customer that they can sign away those rights can result in company ending fines.
Hmmm, might have to lead with this line of reasoning when I ask Samsung here in Australia why my S6Edge doesn't have an update for this in a reasonable timeframe...
Mobile devices also have much less reason to lose support than they used to. In 2010, the difference in hardware between a new phone and a 3-year-old phone was huge - 8 times the RAM, 4 times faster CPU, twice the display resolution, etc. Nowadays, the Nexus 5's specs are on par with midrange phones being released as new. It has all the hardware required to run modern apps. There's no good reason why it can't be supported, besides getting more money from people if they have to buy a new phone every 3 years.
Quite frankly I don't think we should be counting elapsed time from when the device was first released but rather to when the device was last sold as new. I have a Sony Z3 first released September 2014, but which I purchased new over a year later in October 2015. The last security update this phone received is the May 2016 one.
On the bright side, Nexus 5 has a lot of community support. So, as you've stated, there are decent ROM alternatives like LineageOS that are actively maintained to implement these patches.
Last I checked, LineageOS for the Nexus 5 is still vulnerable to CVE-2017-9417 (Broadpwn). LineageOS might work for keeping the userspace up-to-date, but their kernels are still largely dependent on the upstream vendors. If the problem is in a firmware blob, as is the case with Broadpwn, you are pretty much guaranteed to be SOL without vendor support.
this is why I am rooting for initiatives like PostmarketOS [0] and similar initiatives in the hopes ot break this mentality that every year we need to buy new hardware in order to stay secure.
Fortunately the term "flagship" doesn't promise anything about support, patches or security.
It's just a word that means you paid more for having all the bells and whistles that the OEM could offer at the time, instead of going for the next-best model or such.
Fortunately, whether you can afford the best of the best with all the optional extras or a cheaper second-tier model doesn't affect the security of the device. And it shouldn't, because if you can't afford a "flagship" device, doesn't mean you can afford to get hacked either.
Unfortunately, while the security-update frequency ought to be comparable, it turns out that it's mainly comparably bad :-/
Although websites or apps may use HTTPS as an additional layer of protection, we warn that this extra protection can (still) be bypassed in a worrying number of situations. For example, HTTPS was previously bypassed in non-browser software, in Apple's iOS and OS X, in Android apps, in Android apps again, in banking apps, and even in VPN apps.
This only applies to apps which screw up validation of TLS certificates. There is an unfortunate amount of them, but certainly does not apply to all apps (and not an issue for websites).
Either way, this disclosed vulnerability only involves link layer man-in-the-middle in order to collect traffic. Active manipulation of traffic (Required for TLS intercept) is more complicated.
Since this is fixed by a patch to wpa_supplicant LineageOS does fix it, but it is pointed out elsewhere in this thread that Lineage is still vulnerable to older hacks like broadpwn on many devices since they have a hard time patching kernel-level vulnerabilities without vendor participation.
Your advice is valid, but it’s important to not have a false sense of security.
Both APs and clients need to be patched[0]. Mitigations are possible on AP side if no updates are available[1].
[0]: "Finally, although an unpatched client can still connect to a patched AP, and vice versa, both the client and AP must be patched to defend against all attacks!"
[1]: "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)."
It was quite nice to let a wifi router be the VPN client to offload it from all your laptops/phones/etc. and better guarantee "VPN always on".. so much for that.
This issue is two-fold right. You can install plugins that force SSL client side (on the main site and any AJAX calls thereafter) but like you said you have no idea what calls that site is making server side. They could be sending everything you send them over plaintext after the initial TLS secured request. Rough times.
All major browsers implement HSTS preloading, and getting added is quite simple. A very large percentage of your average internet user's traffic is covered by this.
Preloading is a problem waiting to happen. It works fine when only a small portion of the internet uses it. But when you have 2 GB preload file with a few billion entries things are not going to work so well.
As others suggested ensure that all communication uses TLS (be it https et al or tunnel traffic through a VPN).
Also you could install a better version of Android on your phone rather than an outdated vendor version. That will probably fix more security related issues than just this one :)
Vendor version contains blobs (binary objects) for drivers which are most often than not a problem to deal with for OSS and cause various bugs. It's usually workable depending on vendor and hardware but not exactly a perfect solution either.
or waiting (hopelessly) for a patch from my vendor
If this is an actual in the wild exploitable issue, there will be patches very quickly for handsets in the support period, as quickly as there is for iOS. This has been the case repeatedly before as well.
What a weird post in general. Maybe wait to complain about this a month down the line or so? Instead it's just effectively noisy rhetoric.
The support period for an iPhone is at least 3 years of regular patches and feature updates. Most Android phones on the market will have a 'support period' of 12 months if you're lucky.
My point is that the roll-out of updates to Android is unacceptably poor and inconsistent and relies on optimism on the part of the user.
The use of the word hopelessly was probably unnecessarily dramatic I agree but I'll leave it there so your comment makes sense.
Did you intend to post that reply to me? Because of course there isn't a patch for iOS yet, and when there is it will leave out hundreds of millions of devices that no longer receive patches. My point was that if one wants to stomp their feet and do the easy "Damn Android" complaint, at least wait until the basis is sound.
I appreciate this is coming from a UK perspective and that not everyone is this lucky, but I don't remember the last time I used public WiFi on my phone thanks to a general mistrust of it and the fact that 4G (or at least HSPA+) has very good coverage here.
This is about WiFi "protected" with WPA2: basically treat it as suspiciously as you would any public WiFi.
If you choose not to use public WiFi because you can't "trust" it, then you now need to stop using your private WiFi too (until your systems get appropriate patches).
Ubiquity just released a patch for KRACK and soon others will I imagine. From a client perspective, same as always, wait for a patch from your OS vendor. edit: it seems this patch only handles modes where the AP is a client like a bridge or site-to-site. Its still a client-side fix and patching AP's used traditionally won't fix this.
In practice, everything of value should be going over TLS. If you're worried you should be using a VPN on untrusted networks. This attack, if I'm reading it right, doesn't do anything someone on your wlan or lan can't do right now via ARP poisoning and other attacks. So being on that work connection or restaurant wifi is almost the same risk level of this attack.
The thing is, not every protocol offers TLS. Take SMB (network shares) for example... encryption is only offered as of v3 and if a company/university wants to allow Windows 7 clients, they're capped to SMB v2.1.
That's a good example. I guess there's other mitigation at work here. In my case if I'm in a public wifi area and connecting to my work PC then I'm using VPN to access smb. Smb just isn't open to the wifi attacker.
In a case that it is, its curious how you would inject data into a smb stream and not fail checksums from client-side chechking. Maybe its trivial to deal with this, not sure.
If the WPA2 protected wifi network is using AES, which is the most common in my experience, then they won't be able to inject any data. From the Krack website:
If the victim uses either the WPA-TKIP or GCMP encryption protocol, instead of AES-CCMP, the impact is especially catastrophic. Against these encryption protocols, nonce reuse enables an adversary to not only decrypt, but also to forge and inject packets.
You should be good if you’re up to date as of November 6th (I think, it may be November 8th)
Swiftonsecurity tweeted this out, it’s a description of KRACK and various devices affected by it. Apparently google already fixed it on android? Also it says that iOS is rumored to be protected against this since iOS 11 but it’s not confirmed. Nobody has put out an official statement yet. What’s weird is that commercial vendors like Ubiquiti UniFi (I use them myself) have already released fixes for their APs but the paper says that clients should be the priority and get fixed from KRACK ASAP. And it’s weird because I don’t know of any client-side fix released in the wake of KRACK being public.
https://char.gd/blog/2017/wifi-has-been-broken-heres-the-com...
I found it interesting that, in his article, he said:
"With our novel attack technique, it is now trivial to exploit implementations that only accept encrypted retransmissions of message 3 of the 4-way handshake. In particular this means that attacking macOS and OpenBSD is significantly easier than discussed in the paper"
but elsewhere it said recent versions of OS X and iOS are not impacted. I wonder if the "safe" OSes are only vulnerable to the blocking/replay but not the decryption of data?
My UniFi AP-PROs show up today so I'll make sure to update them first thing.
Also, I'm having a bit of a hard time understanding the attack. It sounds like he forces them to connect to his AP, performs the attack, then allows them to connect to the intended network with the zeroed key, THEN is able to sniff that client's traffic because he knows their key? If I understand correctly, this means he cannot sniff the whole network's traffic, only the traffic between the attacked client and the AP? This makes me wonder about the meaning of a pre-shared key, but I'm guessing the PSK is only used to setup the relationship between client and AP, and then after the initial connection/pairing the pre-shared key is no longer used...
> Also, I'm having a bit of a hard time understanding the attack.
He forces them to connect to his own AP and forwards all traffic to the destination so that the client is unaware it has been redirected.
He then forces the client to re-install the key which (on anything that is derived from wpa_supplicant e.g. Linux, Android, etc) the client has blanked out after first use, so the key it reinstalls is now all zero bytes.
He can continue to forward the traffic to the destination so that the client gets responses, but now he can decrypt all of the traffic too.
For clients that re-install the correct key (which the account does not recover in any way) the attacker has to rely on snooping enough encrypted data in order to perform a birthday attack as the key re-installation also resets the frame counters which leads to nonce-reuse which is a problem in ciphers like AES-GCM.
Install one of the major ROMs like AOSP or LineageOS. Relying on your vendor for software or purchasing a device that forces you to isn't the best idea these days.
> Relying on your vendor for software or purchasing a device that forces you to isn't the best idea these days.
Relying on the efforts of unpaid volunteers doing their best to hack together binary blobs is also not the best idea...
Not all devices are supported by major ROM distributors, nor is the support guaranteed to be endless or current... (even some devices as major as the Galaxy S6 for example)
Agreed, but unfortunately if the difficulty of maintaining/backporting/forward-porting binary blobs means that nobody will release ROMs for your device (anymore), your point is pretty much irrelevant. ;-)
This is true, however it doesn't make the point irrelevant.
1. Beyond difficulty of porting blobs, you might well also simply get your updates from a custom ROM faster than you'll get them from the manufacturer, even if it's still supported. That in itself is an advantage.
2. Backporting updates to third party components can be simple (assuming a stable ABI/API); the easiest case is probably that of just dropping binaries from a similar phone that did get updated into a zip file and then flashing it. Look at busybox installers, for example; all you need is a version compiled for your hardware. Java components can sometimes be changed as well (see xposed). This works on desktop systems as well, sometimes: I've been able to 'fix' older games into working just by dropping a newer version of a dll into the game directory (directx, openal, etc))
3. Maybe the company is just stupid. Motorola (or is it Verizon?) has tried Marshmallow for the Moto E2 in Europe, but not in the US. I'd expand on this but I'm on mobile and I'm lazy.
"is there any mitigation for this other than ditching my handset and switching to an iPhone or waiting (hopelessly) for a patch from my vendor."
Using a VPN is the best way to mitigate this until your device is patched, assuming you trust your VPN provider or run your own VPN.
Edit: Actually, even if you don't trust your VPN provider, you'll be protected against this attack (KRACK), given their client is implemented properly.
Unfortunately this is a big part of trusting your VPN provider. It’s shocking how bad the situation is, especially it seems on those marketed via Android apps. [1]
Well the VPN ecosystem has an enormous long tail - the paper you cite tested 283 (!) apps. It's unfortunate but somewhat expected that a significant number, especially the ones that haven't been around for long, would have issues.
I'm sure, given the size of that list, that they tested some of the biggest players on the VPN space. I think it'd be good to know which apps were tested and didn't show any issues, especially in light of Krack and the Android bug on wpa_supplicant.
With critical bugs like these, it's certain Google will require recent devices that have enough affected users to be updated ASAP. Expect an update within in a few weeks.
423 comments
[ 4.2 ms ] story [ 285 ms ] threadNo, luckily implementations can be patched in a backwards-compatible manner.
... if transmitted over plaintext http
Is this issue any different to using open wifi at a cafe, which many many people do, relying on HTTPS for their security? (This is an honest question)
The risk is that you may do things on a protected network assuming it really is protected - this is more of a thing for organisations rather than consumers, for example organisations might have unprotected services accessible over their office wifi.
The only protection here is HSTS (which is not enabled by most websites, but major ones like banks will usually have them) and manually typing https:// in your address.
It might be worth it.
I remember spending hours trying to figure out why Google Adsense wouldn't render correctly. In the end I figured out that it was Adblock's fault :))
https://www.ssllabs.com/ssltest/analyze.html?d=commbank.com.... https://www.ssllabs.com/ssltest/analyze.html?d=nab.com.au&s=... https://www.ssllabs.com/ssltest/analyze.html?d=westpac.com.a...
CUA does have it - https://www.ssllabs.com/ssltest/analyze.html?d=ob.cua.com.au
Bankwest does but has some awful problems elsewhere - https://www.ssllabs.com/ssltest/analyze.html?d=ibs.bankwest....
But yeah, Westpac and NAB don't, and in addition to the ones you tested, ANZ and St. George don't have it either. That's pretty unacceptable really.
Anyone got any suggestions for options?
But it has very few kernel security patches: https://cve.lineageos.org/android_kernel_motorola_msm8610
You could just ... buy an iPhone and get timely security updates for years.
EDIT: Downvote if you want, but if iOS 11 contains this security fix exclusively and not iOS 10, then an iPhone 5s bought on 20 September 2013 is going to get this fix. If Apple release an iOS 10 update and you bought an iPhone 5 on 21 September 2012 you're covered too.
And section 2.5.6:
So you just can't have a web browser not using the built-in WebKit, period.As far as I can tell, you can install a web rendering engine that is not the built-in WebKit, as long as you only use it for HTML/JS that come with your app. At that point the JIT caveat applies.
> (if it is not against the app store guidelines)
But regardless, with your own device, you can run whatever code you want on it.
I'm using it successfully with LineageOS 14.1 (Android 7.1.2).
[0] https://github.com/topjohnwu
[1] https://forum.xda-developers.com/apps/magisk
I'm actually persuaded that I don't need terminal root access on a device (except for system debugging), but rather a firmware signed with my own release keys, and apps that need privileged access baked in.
It attempts to detect root or modifications to the ROM by malicious software.
Certain newer devices have secure boot attestation that may cause SafetyNet to fail unless spoofed to be a different device which does not have such attestation.
Also, neither root not an unlocked bootloader is required to make "proper backups". Some data actually can't be backed up, and for some data there is no point in making a backup. If the goal is to be able to restore the system to a specific, known state, a bit-for-bit image backup of the entire filesystem is just one way to accomplish the task.
So in other words "yes, that is a requirement that will eventually be on all android phones"? Am I misunderstanding something? Older phones being an exception does me little good going forward.
> Also, neither root not an unlocked bootloader is required to make "proper backups". Some data actually can't be backed up, and for some data there is no point in making a backup. If the goal is to be able to restore the system to a specific, known state, a bit-for-bit image backup of the entire filesystem is just one way to accomplish the task.
The last time I tried adb backup and restore, it was a mess. Multiple apps like Skype had no data. And authenticator explicitly opts out of being backed up.
Titanium backup, on the other hand, works perfectly.
Ideally I would just have a rooted phone, but then safetynet complains, and I can't even use Netflix and pokemon. As an alternative I could accept an unrooted but unlocked phone, and root it only when making and/or restoring backups. But having neither is a big hassle.
To date it means that it's very possible to bypass any protections put on this though - I believe this may even be possible without spoofing the device in this way, but in any case, Magisk works on any device available today.
It's really not the same as being free of annoying and unhelpful restrictions.
Also fairly actively developed and supports a wide range of devices.
Why did OpenBSD silently release a patch before the embargo?
OpenBSD was notified of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: "In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging". Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.
TL; DR OpenBSD acted rationally if they'd prefer to go it alone, which seems to be their culture. To their credit, it's worked pretty well so far. But you can't have your cake and eat it too. If they prefer a mad scramble after public disclosure, they'll get it. But they shouldn't get early notice from responsible researchers.
I don't believe that embargo is healthy or responsible! If anything its a monopolising factor.
Which doesn't make a difference if OpenBSD still gets their patch out at the same time as everyone else. Unlike other vendors, it doesn't take OpenBSD four months to go from vulnerability notification to patch release, if you look at previous disclosure timelines they typically have a patch out in days.
The whole thing is a shit show and really I'm rather more behind OpenBSD's approach.
Edit just to expand on this as someone deleted a post ....
----
It's slightly more complicated than the prisoner's dilemma. The prisoner's dilemma doesn't account for a large facet of the problem which is being discussed here. If all the good parties participate and coordinate then we're better off. The problem is there are outlying circumstances which means that not everyone will be included:
1. If someone kicks someone out (OpenBSD) on political whim playing CYA, they no longer benefit.
2. If a party is not let in, they no longer benefit.
3. If someone is unaware of it, they don't benefit.
This turns it into a security monopoly where the big vendors get exclusive rights to embargo and exclude smaller vendors and control the disclosure process on their own schedule.
The first thing the people outside of the club find is they wake up on Monday morning and have to clear up a shitstorm of monumental proportions with less resources than the monopolised vendors who've had time to deal with it.
Then there's the assumption that the monopolised vendors are trustworthy which is 100% impossible to validate and therefore invalid.
No bullshit please - you guys do a wonderful job of avoiding it and stamping on it when it does turn up. Keep up the good work :)
> This turns it into a security monopoly where the big vendors get exclusive rights to embargo and exclude smaller vendors and control the disclosure process on their own schedule.
Not necessarily. It turns into a monopoly of those who can show themselves to be credible partners. This exhibits incumbency bias which in social context we call track record. It's not nearly as exclusionary as you're making it out to be.
> Then there's the assumption that the monopolised vendors are trustworthy which is 100% impossible to validate and therefore invalid
This is common in trust problems. You don't need to be 100% sure everyone you're dealing with is trustworthy to work with them because we don't live in a single-iteration game. Again, iterations of retaliation and forgiveness remove the need to have 100% certainty about a player's intentions.
[1] https://en.wikipedia.org/wiki/Ultimatum_game
No one is credible here. The very nature of a closed agreement of secrecy between arbitrary parties is the opposite of credibility.
Sure, but eventually you get called out on it in a public forum, like this one, and people stop giving you goodies going forward. I would consider it acceptable practice to, when considering dealing with OpenBSD (or people who are close to them), (a) withhold vulnerabilities until after the embargo date or (b) refuse to give any information unless they sign a binding non-disclosure agreement committing them to the deadline under pain of penalty. (The latter is an option because it appears, in this case, they broke the spirit if not letter of the agreement. The solution to that problem is legalese.)
I didn't break any agreement. I agreed with Mathy on what to do, and that's what I did.
The fact that Mathy decided to get CERT involved and subsequently had to extend the embargo has nothing to do with me.
(edit: typo)
If Mathy was concerned, why did he wait to notify CERT? Should that not have been the first priority?
If you don’t limit mitigation to "a config setting" (and why would you?!), a patch/new version is the best mitigation you can get.
I've been doing that for years and recommend others do so as well.
The rise of HTTPS nearly everywhere helps mitigate things a bit. This same type of exploit 5 years ago would wreak havoc exploited at the local Starbucks WiFI.
I was informed on July 15.
The first embargo period was already quite long, until end of August. Then CERT got involved, and the embargo was extended until today.
You can connect the dots.
I doubt that I knew something the NSA/CIA weren't aware of.
There's only a few courses of actions. One is to sit quietly and let everyone eventually do the solution. And that doesn't work. No fire under peoples' asses, and the work is delayed.
The other, is to release it promptly. Then, at least we can decide to triage by turning down X service (even if wifi), requiring another factor like tunnel-login or what have you.
But truthfully, defect in a Prisoners Game played out here was the best choice. The rest of the community is "agree".
You also can not guarantee me that no one who gets this information early is not working for a bad actor.
Think about it in a different way: What if a vulnerability was discovered in TLS and FOSS implementations patched it, but there is an embargo for supposedly protecting some banking software? What if NSA/CIA/other agencies find out about it (they would know immediately) and use it to target users/activists?
But pretending as though co-ordination of any kind is somehow bad (and then resorting to emotional arguments and so on) is pretty reckless.
> even users of non-proprietary projects
Actually many FOSS projects get only notified on the disclosure date.
Hiding the vulnerability for such a long time makes more harm good. The vulnerability can potentially be exploited by security agencies that necessarily know about them and could also be leaked to a bad actor by an employee of one the vendors.
Hopefully WPA2 isn't that important, but potentially security sensitive users trusted something that was known by some to be vulnerable for 3 months! Bad actors could have used it against them.
The embargo resulted in potentially bad actors knowing about the issue, but not vulnerable users.
Do you seriously expect the other billions of people on the planet to be that great too?
No. I also don't expect them to choose device based on security. That is very bad as vendors won't care about patching their older devices (look at Android devices, home routers...) and vendors won't care about patching their flagship devices fast as they have the possibility to request very long embargos.
Making compromises for those vendors and giving more time for security agencies and other bad actors to silently exploit the vulnerabilities (where FOSS projects would have made patches for users that care) is not the way to go. That philosophy actually makes everybody less safe.
If you don't agree with an embargo and decide to break it, that's on you. But the consequence is that you shouldn't be surprised if next time you're informed later, or not at all. What OpenBSD proponents and developers are doing right now, is damage control. It may work this time, it may work next time, but it won't keep working every time so pick your fights right. It isn't the first debacle OpenBSD has with full disclosure either (hint: OpenSSH).
There are also millions upon millions of devices which won't get patched. Given the vulnerability is apparently the most vulnerable on Linux and hence Android, do you think all the smartphones running Android 4.3, 4.4, 5.0, and 6.0 will be patched [1]?
[1] https://en.wikipedia.org/wiki/Android_(operating_system)#Pla...
It's precisely the correct word. Prisoner's dilemma are simple, mathematically. This was one. OpenBSD defected. The joke's on the security researcher, though, since this doesn't appear to have been their first time [1][2].
Robert Axelrod outlined, in his 1984 classic The Evolution of Cooperation [3] four requirements for a successful iterative prisoner's dilemma strategy. One is retaliating. Security researchers are letting OpenBSD play an iterating game as if it's an N=1, i.e. they're not retaliating. Given the community is playing "always cooperate," OpenBSD's best move is actually "always defect".
[1] https://lwn.net/Articles/726585/ thank you 0x0 [a]
[2] https://lwn.net/Articles/726580/ thank you 0x0 [a]
[a] https://news.ycombinator.com/item?id=15481980
[1] https://en.wikipedia.org/wiki/The_Evolution_of_Cooperation
Real life is messier than any model.
https://www.quantamagazine.org/in-game-theory-no-clear-path-...
I'm mostly here just to correct misstatements of facts. You're welcome to your own interpretation, game theory optimization, etc.
The patch has obviously an explicit description:
"State transition errors could cause reinstallation of old WPA keys."
It's true, however, that anybody who analyzes the diffs would eventually figure that out, as Theo de Raadt argued.
My conclusion is also that the real error was even wanting to give the details to him at that moment, as there's apparently a history of him not respecting embargoes.
0 - https://github.com/openbsd/src/commit/2e40dd69ac29d6a858309b... 1 - https://github.com/openbsd/src/commit/cc66e8f557d6f3d4dea5ea...
"Because Android uses wpa_supplicant, Android 6.0 and above also contains this vulnerability. This makes it trivial to intercept and manipulate traffic sent by these Linux and Android devices. Note that currently 41% of Android devices are vulnerable to this exceptionally devastating variant of our attack."
Can anyone explain the timeline of releasing such significant security findings? Why is it disclosed to the public 1/2 year after submitting to review? I'd guess the (publicly funded) research behind it is a lot older than that.
e.g. Dan Kaminsky's discovery of DNS cache poisoning had a 5 month responsible disclosure embargo.
From my understanding of research at public institutions there is a long period of time and steps between finding something interesting and submitting a paper for review.
Why not disclose the vulnerability first to concerned parties and then write up a fancy research paper? Why the other way round?
Only two explanations I could come up with: Either there must be a very short time frame between identification of the vulnerability and writing of the paper or there was further research needed. Or....I don't know
It's 3 month. It's a reasonable delay if you have to alert lots of manufacturer and they need time to roll out critical patches to lots of devices.
Please stop confusing slowness with an intent to delay or ignore.
This will fool your client (eg: your phone) to connect to it, before it reaches your access point, then forward packets to your AP (basic man in the middle).
On the other hand, I am wondering if it manages to correctly forward packages back to the AP if that has MAC filtering on...
Remember, 'S' in IoT is for Security.
One of the best quotes I've heard in a while.
As much as this is a scare tactic to get people to demand vendor patches, it's been true for https for a while.
Browsers don't have any trick (that I know of) to enforce https on first connection. HSTS is defeated by simply rejecting connections to https - the user will retry the site from different devices and destroy their hsts cache in order to reach the site. Assuming the site used hsts.
[1]: https://hstspreload.org/
I'm not certain if uninstalling a browser clears the cache (do uninstalled browsers retain their profiles?), but preloaded sites would not be affected - they're included in the browser binary. Either way, let's not act like there's a massive hole in HSTS because there's a possibility that users might go as far as reinstalling their browser to visit a not-preloaded HSTS-enabled site that's being targeted.
"You wouldn't HSTS the whole internet, would you?"
Google: "Hold my beer..."
https://nakedsecurity.sophos.com/2017/10/03/google-is-making...
Right now it's mostly unimportant new domains, but it's a start, and they could convince other domain registrars to follow-suit.
A reason to use https even for the most basic websites, including the ones embedded in IoT devices on local networks.
Seconding this. I wonder if it is something fixable at the OS level, or if individual WiFi drivers need to be updated too.
Would love to see someone throw together a list of OS', Routers, and other WiFi stuff that is known to be patched/unpatched/unknown.
Microsoft's status is unclear at the time of writing.
Are manufacturers like linksys, d-link issuing patches now or will it be enough to have windows/os x/iOS/android updates enabled? Or do I need both?
On page 30 of the presentation: "Authenticator may (or may not) re-use ANonce"
From the source: 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.
Source: https://www.krackattacks.com/
This really does highlight the absolute disaster zone that the Android handset market has become as far as updates are concerned. I'm sure the Pixels will get a fix relatively quickly but almost every other Android user is going to be left in security limbo.
In general most bigger manufacturers have been somewhat decent in updating their flagship devices. With a Sony flagship from the last 18 months for example, you usually won't run more than two months behind on security updates. Samsung is similar if I remember correctly. Hopefully a big exploit like this will be enough of a kick in the butt to get manufacturers releasing security updates faster.
I totally agree with your hope that this will kick both the manufacturers and Google in the butt enough to get something done about this. I don't like our chances though!
Hopefully Android Orea 8 with Project Treble will stop this ridiculous trend for the rest of us. Together with the smartphone market being saturated (budget phones of 200 EUR are very decent these days), we may end up with long term support on older yet still decent devices.
There is a problem with handset abandonment, but this is true across all vendors, and it does not underline sequence7's claim that this is solely an Android problem.
And they are more expensive than many computers you can buy on the market. 2 years support on a device that can cost $500+ isn't acceptable.
We are 4-5 years into the period where people have had sub $300 choices, so there is an alternative to spending $500+ on a device that comes with 2 years of support. Maybe not a fantastic alternative, but the $300-$500 extra that people choose to spend says something about what they care about.
For example, under the Consumer Rights Act 2015 in the UK the product must last for as long as a reasonable person would expect it to, and Apple's interpretation of that is five/six years (see https://www.apple.com/uk/legal/statutory-warranty/).
The Consumer Rights Act 2015 also covers unfair terms in sales contracts (and at least in Scotland EULAs are part of the sales contract, per Beta Computers (Europe) Ltd v Adobe Systems (Europe) Ltd; I don't know the status elsewhere in the UK), and it's quite likely you could just go through most of the possible contractual outs and argue they are unfair terms.
You don't know that. Apple could very well release an iOS 10 update for this.
But in both cases the stated policy is that the devices will not receive any more updates, either feature or security.
https://download.lineageos.org/pme
[0] https://www.postmarketos.org/
It's just a word that means you paid more for having all the bells and whistles that the OEM could offer at the time, instead of going for the next-best model or such.
Fortunately, whether you can afford the best of the best with all the optional extras or a cheaper second-tier model doesn't affect the security of the device. And it shouldn't, because if you can't afford a "flagship" device, doesn't mean you can afford to get hacked either.
Unfortunately, while the security-update frequency ought to be comparable, it turns out that it's mainly comparably bad :-/
Although websites or apps may use HTTPS as an additional layer of protection, we warn that this extra protection can (still) be bypassed in a worrying number of situations. For example, HTTPS was previously bypassed in non-browser software, in Apple's iOS and OS X, in Android apps, in Android apps again, in banking apps, and even in VPN apps.
Either way, this disclosed vulnerability only involves link layer man-in-the-middle in order to collect traffic. Active manipulation of traffic (Required for TLS intercept) is more complicated.
That's still truly terrible compared to Apple's legacy device support. iOS 11 and future patches still support even the iPhone 5s, a phone from 2013.
You get updates every week.
Your advice is valid, but it’s important to not have a false sense of security.
https://w1.fi/cgit/hostap/commit/?id=a00e946c1c9a1f9cc65c729...
Well, hopefully this means no kernel patch will be needed.
[0]: "Finally, although an unpatched client can still connect to a patched AP, and vice versa, both the client and AP must be patched to defend against all attacks!"
[1]: "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)."
But it's very difficult to ensure that all the communications your device is making (background services, vendor apps...) go through that channel.
Reality is that DNS remains and will continue to remain a giant hole in TLS.
Also you could install a better version of Android on your phone rather than an outdated vendor version. That will probably fix more security related issues than just this one :)
If this is an actual in the wild exploitable issue, there will be patches very quickly for handsets in the support period, as quickly as there is for iOS. This has been the case repeatedly before as well.
What a weird post in general. Maybe wait to complain about this a month down the line or so? Instead it's just effectively noisy rhetoric.
The use of the word hopelessly was probably unnecessarily dramatic I agree but I'll leave it there so your comment makes sense.
If you choose not to use public WiFi because you can't "trust" it, then you now need to stop using your private WiFi too (until your systems get appropriate patches).
In practice, everything of value should be going over TLS. If you're worried you should be using a VPN on untrusted networks. This attack, if I'm reading it right, doesn't do anything someone on your wlan or lan can't do right now via ARP poisoning and other attacks. So being on that work connection or restaurant wifi is almost the same risk level of this attack.
In a case that it is, its curious how you would inject data into a smb stream and not fail checksums from client-side chechking. Maybe its trivial to deal with this, not sure.
If the WPA2 protected wifi network is using AES, which is the most common in my experience, then they won't be able to inject any data. From the Krack website:
If the victim uses either the WPA-TKIP or GCMP encryption protocol, instead of AES-CCMP, the impact is especially catastrophic. Against these encryption protocols, nonce reuse enables an adversary to not only decrypt, but also to forge and inject packets.
I found it interesting that, in his article, he said: "With our novel attack technique, it is now trivial to exploit implementations that only accept encrypted retransmissions of message 3 of the 4-way handshake. In particular this means that attacking macOS and OpenBSD is significantly easier than discussed in the paper"
but elsewhere it said recent versions of OS X and iOS are not impacted. I wonder if the "safe" OSes are only vulnerable to the blocking/replay but not the decryption of data?
My UniFi AP-PROs show up today so I'll make sure to update them first thing.
Also, I'm having a bit of a hard time understanding the attack. It sounds like he forces them to connect to his AP, performs the attack, then allows them to connect to the intended network with the zeroed key, THEN is able to sniff that client's traffic because he knows their key? If I understand correctly, this means he cannot sniff the whole network's traffic, only the traffic between the attacked client and the AP? This makes me wonder about the meaning of a pre-shared key, but I'm guessing the PSK is only used to setup the relationship between client and AP, and then after the initial connection/pairing the pre-shared key is no longer used...
https://blog.cryptographyengineering.com/2017/10/16/falling-...
He forces them to connect to his own AP and forwards all traffic to the destination so that the client is unaware it has been redirected.
He then forces the client to re-install the key which (on anything that is derived from wpa_supplicant e.g. Linux, Android, etc) the client has blanked out after first use, so the key it reinstalls is now all zero bytes.
He can continue to forward the traffic to the destination so that the client gets responses, but now he can decrypt all of the traffic too.
For clients that re-install the correct key (which the account does not recover in any way) the attacker has to rely on snooping enough encrypted data in order to perform a birthday attack as the key re-installation also resets the frame counters which leads to nonce-reuse which is a problem in ciphers like AES-GCM.
Relying on the efforts of unpaid volunteers doing their best to hack together binary blobs is also not the best idea...
Not all devices are supported by major ROM distributors, nor is the support guaranteed to be endless or current... (even some devices as major as the Galaxy S6 for example)
1. Beyond difficulty of porting blobs, you might well also simply get your updates from a custom ROM faster than you'll get them from the manufacturer, even if it's still supported. That in itself is an advantage.
2. Backporting updates to third party components can be simple (assuming a stable ABI/API); the easiest case is probably that of just dropping binaries from a similar phone that did get updated into a zip file and then flashing it. Look at busybox installers, for example; all you need is a version compiled for your hardware. Java components can sometimes be changed as well (see xposed). This works on desktop systems as well, sometimes: I've been able to 'fix' older games into working just by dropping a newer version of a dll into the game directory (directx, openal, etc))
3. Maybe the company is just stupid. Motorola (or is it Verizon?) has tried Marshmallow for the Moto E2 in Europe, but not in the US. I'd expand on this but I'm on mobile and I'm lazy.
Using a VPN is the best way to mitigate this until your device is patched, assuming you trust your VPN provider or run your own VPN.
Edit: Actually, even if you don't trust your VPN provider, you'll be protected against this attack (KRACK), given their client is implemented properly.
Unfortunately this is a big part of trusting your VPN provider. It’s shocking how bad the situation is, especially it seems on those marketed via Android apps. [1]
[1] https://arstechnica.com/information-technology/2017/01/major...
I'm sure, given the size of that list, that they tested some of the biggest players on the VPN space. I think it'd be good to know which apps were tested and didn't show any issues, especially in light of Krack and the Android bug on wpa_supplicant.
With critical bugs like these, it's certain Google will require recent devices that have enough affected users to be updated ASAP. Expect an update within in a few weeks.
https://git.lede-project.org/?p=source.git;a=commit;h=bbda81...
> As Hudson notes, the attacker would have to be on the same base station as the victim, which restricts any attack's impact somewhat.
If I understand it correctly then there has to be a connection already present for the attack to work?