Home |
Search |
Today's Posts |
|
Electronics Repair (sci.electronics.repair) Discussion of repairing electronic equipment. Topics include requests for assistance, where to obtain servicing information and parts, techniques for diagnosis and repair, and annecdotes about success, failures and problems. |
Reply |
|
|
LinkBack | Thread Tools | Display Modes |
#41
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-useattack yet?
On 2017-10-18, harry newton wrote:
He who is William Unruh said on Wed, 18 Oct 2017 02:25:28 -0000 (UTC): And the closed source community has a problem with never actually fixing the problems (see most of the wireless router manufacturers). Hi William, I'm not sure what you mean, but I guess what you're saying is that firmware is only available for the newest routers, which I would agree with. Is that what you're saying? No. Many closed source vendors do not bother trying to fix things unless their feet are really roasted. In the case of routers, since the primary attack vector is to clients, and since routers rarely act as clients (most are not in bridge mode) they do not bother. And other closed source vendors do not bother since fixing it only affects the bottom line negatively. As can be seen from the debate that occured re Krack and OpenBSD. Theodore felt that leaving his users hanging completely exposed was not a good idea, and eventually the Krack finder agreed (only to regret it later). Thanks William for understanding what I was talking about. I do see the conundrum, which is the following, put bluntly: 1. Researcher finds vulnerability on day 0 & secretly informs vendors 2. Proprietary-code vendors fix & release code & nobody is the wiser 3. Open-source vendors fix & release code & anyone can do a "diff" The problem is that the bad guys can do the diff and then get a jump in the wild on building an attack vector. The problem is less than you would expect since it requires that the bad guys actually do the diff. I doubt that there are many who take each update or kernel/programs, diff them and try to figure out whether it was a security update they could use, or some other update that which is of no use to them. Ie, Unless the code or the press point direct fingers at it, they have no particular reason to zero in on the changes. I don't know *how* to solve this, and I don't understand what the Krack Attack researcher proposed for what Theordore should have done. Their position now seems to be that Theodore should have waited until Oct 16 when they announced it, and immediately rolled out the fixes on that date (as for example Debian did). It is a real moral connundrum. Did anyone actually notice that OpenBSD could be used to reveal the bug? William, Can you help me understand what the researcher prefers for next time? He used the words "sit on a diff", which I took to mean that someone *knew* what the changes were and had to "sit on it" (and not tell anyone). (Yes, I'm well aware of what a "diff" is in the Bash world anyway, which is just a command revealing what's different.) Make the fix, but do not release it until the embargo is over. I'm confused about one of two events, as to what the researcher wanted: 1. Did he want Theordore to just *sit* on the fix & wait? He wanted him to sit on the fix until the bug was announced and everyone could release the fix at the same time. Note that Theo asked him for permission to release the fix arguing that it was important for his users not to open to attack. But he asked permssion. That permission was given, but regretted. 2. Or did he propose not giving Theordore enough info to fix it next time? No, "all" vendors were notified of the problem in August. So everyone had the opportunity to fix it. The request was to hold off on the implimentation until a certain date so everyone could fix it at the same time without warning the bad guys beforehand. Ofttimes fear makes one think that everyone in the world can see right through you and see what you are trying to hide, while actually noone does. So it was not a problem, but a true moral connundrum where no answer is right. But what is the *standard* approach in this situation for open-source code? What did the researcher propose for open-source code vendors? 1. Did he propose that they not release the code until it's public? 2. Or did he propose not *telling* the open-source community early? I'm confused what the suggested "solution" by the researcher was. See above. |
#42
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-useattack yet?
On 2017-10-18, Doomsdrzej wrote:
On Wed, 18 Oct 2017 02:25:28 -0000 (UTC), William Unruh wrote: On 2017-10-17, harry newton wrote: He who is s|b said on Tue, 17 Oct 2017 22:36:45 +0200: Microsoft releases statement on KRACK Wi-Fi vulnerability https://www.windowscentral.com/microsoft-releases-statement-krack-wi-fi-vulnerability What's interesting is that the open-source community has a problem with diffs letting the cat out of the bag too soon (witness openbsd). And the closed source community has a problem with never actually fixing the problems (see most of the wireless router manufacturers). As can be seen from the debate that occured re Krack and OpenBSD. Theodore felt that leaving his users hanging completely exposed was not a good idea, and eventually the Krack finder agreed (only to regret it later). It is a real moral connundrum. Did anyone actually notice that OpenBSD could be used to reveal the bug? Ofttimes fear makes one think that everyone in the world can see right through you and see what you are trying to hide, while actually noone does. So it was not a problem, but a true moral connundrum where no answer is right. I have to disagree with the first statement. The open-source community does fix bugs which are very well-known and widespread. That is why Note that the fix for Krack was not a fix in the distributions, but a fix to wpa_supplicant, an external program. So the key person who should be notified was the developer of wpa_supplicant. Note that the "zero password" problem, probably the worst of the lot, could have been fixed privately as if it were a minor improvement (eg instead of zeroing the password, it could have been filled with random chaacters and released without inciting much suspicion. Of course making sure that users actually upgraded would have been a challenge without the urgency of it being a major flaw that could be attacked. Krack already has a fix. It's the smaller issues, like graphical glitches that only affect about 25% of their users which they might not actually fix. They only prioritize whatever they know they can't get away without fixing. Who are you talking about here? There is a big difference between a bug which only annoys and a bug which is a security issue. |
#43
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-useattack yet?
On 2017-10-18, William Unruh wrote:
No. Many closed source vendors do not bother trying to fix things unless their feet are really roasted. In the case of routers, since the primary attack vector is to clients, and since routers rarely act as clients (most are not in bridge mode) they do not bother. And other closed source vendors do not bother since fixing it only affects the bottom line negatively. In some cases it may be possible to run alternative firmware, such as dd-wrt or tomato, once the appropriate versions for your router have been patched. -- ----------------------------------------------------------------------------- Roger Blake (Posts from Google Groups killfiled due to excess spam.) NSA sedition and treason -- http://www.DeathToNSAthugs.com Don't talk to cops! -- http://www.DontTalkToCops.com Badges don't grant extra rights -- http://www.CopBlock.org ----------------------------------------------------------------------------- |
#44
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-use attack yet?
He who is William Unruh said on Wed, 18 Oct 2017 18:25:42 -0000 (UTC):
The problem is less than you would expect since it requires that the bad guys actually do the diff. I doubt that there are many who take each update or kernel/programs, diff them and try to figure out whether it was a security update they could use, or some other update that which is of no use to them. Ie, Unless the code or the press point direct fingers at it, they have no particular reason to zero in on the changes. Thanks William (and Marek), for explaining what the problem is, but what did the researcher propose as the *solution* for open-source code? Did he propose that OpenBSD *wait* until the announcement 50 days later? How is the researcher going to *enforce* that 50-day waiting period? I don't know *how* to solve this, and I don't understand what the Krack Attack researcher proposed for what Theordore should have done. Their position now seems to be that Theodore should have waited until Oct 16 when they announced it, and immediately rolled out the fixes on that date (as for example Debian did). I see you answered my fundamental confusion (see below). 1. Researcher finds bug on day 0 & plans to announce it 50 days later. 2. OpenSource community has to *wait* until the announcement to ship fixes. 3. Closed-source community can ship when? (any time or wait the 50 days?) If that's the rules, it seems like it's going to be difficult to *enforce*. He used the words "sit on a diff", Make the fix, but do not release it until the embargo is over. Thank you for confirming he wanted OpenBSD to sit and wait before releasing the code. I was worried that some *other* researcher ran a diff and had to "sit on his discovery of that diff" which would have revealed to the seconde researcher what the flaw in wpa_supplicant was. What you're telling me is that nobody did that manual third-party "diff" of the source code so it wasn't revealed in the wild to a third party to our knowledge before the 50-day waiting period was up. (Note Marek said 60 days but I think the researchers mentioned only 50 days but let's not quibble if either one of us is wrong as it's close enough.) I'm confused about one of two events, as to what the researcher wanted: 1. Did he want Theordore to just *sit* on the fix & wait? He wanted him to sit on the fix until the bug was announced and everyone could release the fix at the same time. That would mean *every* open-source vendor would have to "sit on the fix" until the announcement. That's fine if the researcher can enforce that. I guess that is what the standard *should* be but who decides such things? Note that Theo asked him for permission to release the fix arguing that it was important for his users not to open to attack. But he asked permssion. That permission was given, but regretted. Ah. THANK YOU FOR EXPLAINING. I *knew* there was regret, but to me, a "diff" is something a third party does of the open-source code to figure out what's different. The guy who wrote the code doesn't have to run a "diff" because he *knows* what he wrote. So I thought a third party who accidentally found out about the bug by doing a "diff" on the open-source code had to "sit" on it. But that didn't make sense given the rest of the conversation. So THANK YOU for explaining that: A. Researcher finds bug on day 0 & gives all vendors 50 days to fix. B. OpenBSD fixes it early and asks for permission to ship the code. C. Researcher provides permission but then regrets that decision. In the future, I guess, researcher wishes to deny *permission* of open-source code to ship the fix early, which is a moral conundrum indeed. And how does the researcher *enforce* this denial of permission to ship open-source code? 2. Or did he propose not giving Theordore enough info to fix it next time? No, "all" vendors were notified of the problem in August. So everyone had the opportunity to fix it. The request was to hold off on the implimentation until a certain date so everyone could fix it at the same time without warning the bad guys beforehand. I see the moral conundrum which pits the visibility of open-source code against the obfuscation of proprietary code for the case of a knowledgeable bad guy... I. In open-source code, a bad guy can do a *diff* to see what changed. II. If something interesting changed, a bad guy can take advantage of it. III. In effect, they get to have their own personal 0-day vulnerability. For the price of a "diff", the bad guy gets his own 0-day vulnerability. It's a moral conundrum I had never even thought about until today. |
#45
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-use attack yet?
He who is William Unruh said on Wed, 18 Oct 2017 18:41:25 -0000 (UTC):
Note that the fix for Krack was not a fix in the distributions, but a fix to wpa_supplicant, an external program. So the key person who should be notified was the developer of wpa_supplicant. Thanks William (although I know you're responding to someone else) for bringing up a second moral conundrum, which is how many people to tell. Since we all know that a secret is no longer a secret if everyone knows about it, do they normally enforce secrecy rules among *all* developers of code? I can imagine, for example, that the Chinese government has at least one programmer in their employ at *every* software company in the USA (as just one example), where that programmer is a sleeper (which is trivial for them to do so I can't believe they don't do it so I assume that they do). The moral question that arises is: Do you tell that sleeper if he is NOT the developer of "wpa_supplicant"? Note that the "zero password" problem, probably the worst of the lot, could have been fixed privately as if it were a minor improvement (eg instead of zeroing the password, it could have been filled with random chaacters and released without inciting much suspicion. Of course making sure that users actually upgraded would have been a challenge without the urgency of it being a major flaw that could be attacked. If we couple the fact that the bad guys (e.g., the Russian mafia, the Communist sleepers, the NSA/CIA/FBI/GCHQ, etc.,) have an immense bankroll with the fact that a 'diff' is so obvious to run on open-source code, I don't know what the *standard* solution is when it gets down to details. William and Marek already said that the researcher wanted OpenBSD to sit on the release of the fix until the vulnerability was announced, which opens up "fork" issues (which may be minor though). Worse - it opens up the "sleeper" issue depending on what the "need to know" classified level of who gets to know about the bug before it's released. Does everyone sign an NDA before they're told about the bug? Who enforces when/if that NDA is broken? |
#46
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-use attack yet?
harry newton writes:
I see you answered my fundamental confusion (see below). 1. Researcher finds bug on day 0 & plans to announce it 50 days later. 2. OpenSource community has to *wait* until the announcement to ship fixes. 3. Closed-source community can ship when? (any time or wait the 50 days?) If that's the rules, it seems like it's going to be difficult to *enforce*. Policies like this can be maintained by requiring recipients of vulnerability predisclosures to agree to maintain confidentiality prior to embargo dates. An organization could choose to break that agreement, but they shouldnt expect to be trusted with predisclosures in the future if they do so. I see the moral conundrum which pits the visibility of open-source code against the obfuscation of proprietary code for the case of a knowledgeable bad guy... I. In open-source code, a bad guy can do a *diff* to see what changed. II. If something interesting changed, a bad guy can take advantage of it. III. In effect, they get to have their own personal 0-day vulnerability. You can inspect object code to discover what the bugs were, too. A high-profile example was the 2015 analysis of the Juniper RNG vulnerability, where no source code was required. -- https://www.greenend.org.uk/rjk/ |
#47
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-useattack yet?
On 2017-10-18, harry newton wrote:
He who is William Unruh said on Wed, 18 Oct 2017 18:25:42 -0000 (UTC): The problem is less than you would expect since it requires that the bad guys actually do the diff. I doubt that there are many who take each update or kernel/programs, diff them and try to figure out whether it was a security update they could use, or some other update that which is of no use to them. Ie, Unless the code or the press point direct fingers at it, they have no particular reason to zero in on the changes. Thanks William (and Marek), for explaining what the problem is, but what did the researcher propose as the *solution* for open-source code? Did he propose that OpenBSD *wait* until the announcement 50 days later? How is the researcher going to *enforce* that 50-day waiting period? Yes, wait. Enforcement is a non-issue. He cannot force compliance. He can however let it be known what they did which will then cause others not to tell OpenBSD anything when the next problem arises. The people doing open source distros are responsible people and their intention is not to make it easy for the bad guys to do nasty things. I don't know *how* to solve this, and I don't understand what the Krack Attack researcher proposed for what Theordore should have done. Their position now seems to be that Theodore should have waited until Oct 16 when they announced it, and immediately rolled out the fixes on that date (as for example Debian did). I see you answered my fundamental confusion (see below). 1. Researcher finds bug on day 0 & plans to announce it 50 days later. 2. OpenSource community has to *wait* until the announcement to ship fixes. 3. Closed-source community can ship when? (any time or wait the 50 days?) If that's the rules, it seems like it's going to be difficult to *enforce*. He used the words "sit on a diff", Make the fix, but do not release it until the embargo is over. Thank you for confirming he wanted OpenBSD to sit and wait before releasing And that made Theo uncomfortable, so he asked permission to ship early. He did not simply go ahead and do it. the code. I was worried that some *other* researcher ran a diff and had to "sit on his discovery of that diff" which would have revealed to the seconde researcher what the flaw in wpa_supplicant was. What you're telling me is that nobody did that manual third-party "diff" of the source code so it wasn't revealed in the wild to a third party to our knowledge before the 50-day waiting period was up. WE will never know for sure of course. But there was apparently no evidence that this crack was actuallyused in the wild. Of course NSA may have discovered it 5 years ago, or perhaps ISIS did. (Note Marek said 60 days but I think the researchers mentioned only 50 days but let's not quibble if either one of us is wrong as it's close enough.) I'm confused about one of two events, as to what the researcher wanted: 1. Did he want Theordore to just *sit* on the fix & wait? He wanted him to sit on the fix until the bug was announced and everyone could release the fix at the same time. That would mean *every* open-source vendor would have to "sit on the fix" until the announcement. That's fine if the researcher can enforce that. What is your hang up about "enforce"? I guess that is what the standard *should* be but who decides such things? AGain you are hung up on a "enforce"/central authority thing. People can behave well all on their own, without legal sanctions or centralized laws. Note that Theo asked him for permission to release the fix arguing that it was important for his users not to open to attack. But he asked permssion. That permission was given, but regretted. Ah. THANK YOU FOR EXPLAINING. I *knew* there was regret, but to me, a "diff" is something a third party does of the open-source code to figure out what's different. The guy who wrote the code doesn't have to run a "diff" because he *knows* what he wrote. The permission was to release a patch for the problem. The bad guys could than run a diff on the released new code to see what was changed. That is where the diff comes in. So I thought a third party who accidentally found out about the bug by doing a "diff" on the open-source code had to "sit" on it. But that didn't make sense given the rest of the conversation. The worry was that by releasing a patched system, it made it easier for some bad guy to discover there was a problem and what it was. So THANK YOU for explaining that: A. Researcher finds bug on day 0 & gives all vendors 50 days to fix. B. OpenBSD fixes it early and asks for permission to ship the code. C. Researcher provides permission but then regrets that decision. In the future, I guess, researcher wishes to deny *permission* of open-source code to ship the fix early, which is a moral conundrum indeed. And how does the researcher *enforce* this denial of permission to ship open-source code? And again. Note that thousands of security holes have been found and annnouncent embargoed in the past. So there is a history of the open source community acting responsibly. 2. Or did he propose not giving Theordore enough info to fix it next time? No, "all" vendors were notified of the problem in August. So everyone had the opportunity to fix it. The request was to hold off on the implimentation until a certain date so everyone could fix it at the same time without warning the bad guys beforehand. I see the moral conundrum which pits the visibility of open-source code against the obfuscation of proprietary code for the case of a knowledgeable bad guy... I. In open-source code, a bad guy can do a *diff* to see what changed. II. If something interesting changed, a bad guy can take advantage of it. III. In effect, they get to have their own personal 0-day vulnerability. For the price of a "diff", the bad guy gets his own 0-day vulnerability. It's a moral conundrum I had never even thought about until today. Yes, but many many others have thought about it. |
#49
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-use attack yet?
He who is William Unruh said on Thu, 19 Oct 2017 01:09:07 -0000 (UTC):
For the price of a "diff", the bad guy gets his own 0-day vulnerability. It's a moral conundrum I had never even thought about until today. Yes, but many many others have thought about it. Thanks for explaining the situation, and the process. |
#50
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-use attack yet?
Does anyone know what *version* of wpa_supplicant contains the KRACK fix?
http://wetakepic.com/images/2017/10/20/wpa_supplicant.jpg LINUX: x@x:~$ which wpa_supplicant /sbin/wpa_supplicant x@x:~$ !$ -version wpa_supplicant -version wpa_supplicant v2.4 Copyright (c) 2003-2015, Jouni Malinen and contributors WINDOWS: c:\ wpa_supplicant 'wpa_supplicant' is not recognized as an internal or external command, operable program or batch file. |
#51
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-useattack yet?
On 2017-10-20, harry newton wrote:
Does anyone know what *version* of wpa_supplicant contains the KRACK fix? http://wetakepic.com/images/2017/10/20/wpa_supplicant.jpg None. It is at present a bunch of patches. However, most distributions have pushed out a fixed version by now. On Mangeia it is 2.6-1.1 on Mageia 6, 2.6-1 on Mageia 5 and 2.6-3 on Mageai Cauldron. You do not tell us which Linux you are refering to. Note that 2.4 probably does not have the fix. But it all depends on your distro. LINUX: x@x:~$ which wpa_supplicant /sbin/wpa_supplicant x@x:~$ !$ -version wpa_supplicant -version wpa_supplicant v2.4 Copyright (c) 2003-2015, Jouni Malinen and contributors WINDOWS: c:\ wpa_supplicant 'wpa_supplicant' is not recognized as an internal or external command, operable program or batch file. Windows does not use wpa_supplicant. That is an open source wpa program. It is used by Android, but again it is probably not a "stock" version, but may well have been altered by the phone manufacturer to include special features of the wireless chipset they use. |
#52
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-use attack yet?
He who is William Unruh said on Sat, 21 Oct 2017 00:57:13 -0000 (UTC):
You do not tell us which Linux you are refering to. Note that 2.4 probably does not have the fix. But it all depends on your distro. Thanks William for that detailed technical answer. I apologize for not providing complete information. http://wetakepic.com/images/2017/10/21/ubuntu_version.jpg $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.2 LTS Release: 16.04 Codename: xenial $ cat /etc/*release | grep VERSION VERSION="16.04.2 LTS (Xenial Xerus)" Windows does not use wpa_supplicant. That is an open source wpa program. It is used by Android, but again it is probably not a "stock" version, but may well have been altered by the phone manufacturer to include special features of the wireless chipset they use. Thanks William. It's so refreshing to deal with actual technical answers! Here is what my Android 4.3 phone just reported: http://wetakepic.com/images/2017/10/21/android_wpa.jpg $ wpa_supplication -version wpa_supplicant v2.1-d15el-4.3 2015-08-13/21:13:54 Copyright (c) 2003-2014, Jouni Malinen and contributors |
#53
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-useattack yet?
On 2017-10-21, harry newton wrote:
He who is William Unruh said on Sat, 21 Oct 2017 00:57:13 -0000 (UTC): You do not tell us which Linux you are refering to. Note that 2.4 probably does not have the fix. But it all depends on your distro. Thanks William for that detailed technical answer. I apologize for not providing complete information. http://wetakepic.com/images/2017/10/21/ubuntu_version.jpg Debian (on which Ubuntu is based) came out with those patches on Monday I think. Ie, the version on the Ubuntu sight by Wed was probably the patched version. If yours was installed befor Wed it almost certainly is not patched. Definitely if it was before Mon the 16th it is not patched. $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.2 LTS Release: 16.04 Codename: xenial $ cat /etc/*release | grep VERSION VERSION="16.04.2 LTS (Xenial Xerus)" Windows does not use wpa_supplicant. That is an open source wpa program. It is used by Android, but again it is probably not a "stock" version, but may well have been altered by the phone manufacturer to include special features of the wireless chipset they use. Thanks William. It's so refreshing to deal with actual technical answers! Here is what my Android 4.3 phone just reported: http://wetakepic.com/images/2017/10/21/android_wpa.jpg It really says nothing. They could have patched that version of 2.1 Or probably not. Although there is a claim in the original that it was wpa_supplicant 2.4 and later that were problematic. And that it is android 6 and later that is problematic. I have no idea whether that is because those are the only ones tested, or because earlier ones are OK. $ wpa_supplication -version wpa_supplicant v2.1-d15el-4.3 2015-08-13/21:13:54 Copyright (c) 2003-2014, Jouni Malinen and contributors |
#54
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-use attack yet?
harry newton writes:
He who is William Unruh said on Sat, 21 Oct 2017 00:57:13 -0000 (UTC): You do not tell us which Linux you are refering to. Note that 2.4 probably does not have the fix. But it all depends on your distro. Thanks William for that detailed technical answer. I apologize for not providing complete information. http://wetakepic.com/images/2017/10/21/ubuntu_version.jpg $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.2 LTS Release: 16.04 Codename: xenial $ cat /etc/*release | grep VERSION VERSION="16.04.2 LTS (Xenial Xerus)" You need 2.4-0ubuntu6.2. http://changelogs.ubuntu.com/changel...u6.2/changelog Use dpkg -l to check the package version. -- https://www.greenend.org.uk/rjk/ |
#55
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-useattack yet?
Richard Kettlewell wrote:
dpkg -l Or apt-cache: ~$ apt-cache policy wpasupplicant wpasupplicant: Installed: 2.4-0ubuntu6.2 Candidate: 2.4-0ubuntu6.2 Version table: *** 2.4-0ubuntu6.2 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 100 /var/lib/dpkg/status 2.4-0ubuntu6 500 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages Also latest version of 16.04 is: $ lsb_release -d Description: Ubuntu 16.04.3 LTS sudo apt-get update && sudo apt-get dist-upgrade -- Take care, Jonathan ------------------- LITTLE WORKS STUDIO http://www.LittleWorksStudio.com |
#56
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-useattack yet?
On 16/10/2017 13:46, harry newton wrote:
Did you update your router for the WPA2/PSK KRACK nonce re-use attack yet? https://www.krackattacks.com I reported it yesterday over here with links... https://groups.google.com/forum/#!forum/alt.internet.wireless They made it public a half hour ago: https://groups.google.com/d/msg/alt.internet.wireless/vn8yRnm7UF8/N89Wcd_OAAAJ Manufacturers apparently had 50 days to effect the fix: Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2 https://papers.mathyvanhoef.com/ccs2017.pdf Patches at the access point end are relatively unimportant. What you need to patch most are your client devices. -- Brian Gregory (in the UK). To email me please remove all the letter vee from my email address. |
#57
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-useattack yet?
Brian Gregory wrote:
Patches at the access point end are relatively unimportant. LEDE 17.01.4 includes the KRACK fixes, no point not upgrading. What you need to patch most are your client devices. True, but it includes an optional AP-side workaround for devices that haven't been (may never be?) patched ... https://lede-project.org/docs/user-guide/wifi_configuration#wpa_key_reinstallation_attack_w orkaround |
#58
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-use attack yet?
How does this colloquial summary for my family look - in case you want to
send one to YOUR family? ======== People are asking what to do about the KRACK Attack vulnerability (note the pleonasm), so I figured I'd let everyone know what it is & I figured I'd give folks the opportunity to ask question if they're concerned. The canonical site for the attack is written by the white hat who found it: https://www.krackattacks.com/ Here's my ad-hoc summary, written with respect to what you and I need to know & do. 1. In May, the white hat notified the government & vendors he found a bug in all WPA WiFi (e.g., WPA2) where someone who is *close* enough to intercept the signals can see everything you do. 2. It affects all WiFi but the worst affected is Android at or over version 6, macOS, Linux, and really fast (i.e., 802.11r fast roaming) routers set up as repeaters (i.e., as a second router). Far less affected are iPhones, WiFi iPads, WiFi iPods, older Android devices, Windows computers, and normal routers (e.g., 802.11n or 802.11ac), especially if they're set up as the main router (and not as a repeater). 3. There is only one viable solution, which is to *update* your device firmware or software, whether that be a mobile phone, a laptop, a desktop, a router working as a repeater, or the main router. The order of priority should be: a. If you have Android 6+, then you *should* update soon. b. If you have MacOS or Linux, then you should update soon. c. If you have an 802.11r router, then you should update soon. You can take your sweet time on everything else, but everything needs to be updated. 4. The problem, of course, is *how* to update each device. a. First look for your device to see if there is an update https://www.kb.cert.org/vuls/id/228519 b. Then try to find the update http://www.zdnet.com/article/here-is-every-patch-for-krack-wi-fi-attack-available-right-now/ c. Then update. What a pain. Let me know if you have questions. ======== |
#59
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-useattack yet?
On 2017-10-29, harry newton wrote:
How does this colloquial summary for my family look - in case you want to send one to YOUR family? ======== People are asking what to do about the KRACK Attack vulnerability (note the pleonasm), so I figured I'd let everyone know what it is & I figured I'd give folks the opportunity to ask question if they're concerned. The canonical site for the attack is written by the white hat who found it: https://www.krackattacks.com/ Here's my ad-hoc summary, written with respect to what you and I need to know & do. 1. In May, the white hat notified the government & vendors he found a bug in all WPA WiFi (e.g., WPA2) where someone who is *close* enough to intercept the signals can see everything you do. No, whose interception point is close enough. Thus your wirelessly connected fridge, which usually has attrocious security, could possibly be used as an interception point for an attacker who is in Mongolia say. 2. It affects all WiFi but the worst affected is Android at or over version 6, macOS, Linux, and really fast (i.e., 802.11r fast roaming) routers set up as repeaters (i.e., as a second router). All wifi is susceptible, including Windows. The problem with Android and Linux is they all use wpa_supplicant and it has a problem that, for security, it zeros the password after using it. But that means that when the replay occurs it uses that 0 password. Thus fixing wpa_supplicant fixes the problem, and it has in principle been fixed. Of course one needs to get that fixed version into the devices. Far less affected are iPhones, WiFi iPads, WiFi iPods, older Android devices, Windows computers, and normal routers (e.g., 802.11n or 802.11ac), especially if they're set up as the main router (and not as a repeater). The problem is a client side problem. But all of those devices are susceptible to at least some version of Krack, and should not assumed to be "far less affected". They are all affected. That they do not have the "zero password" problem is irrelevant since they have other attack vectors. 3. There is only one viable solution, which is to *update* your device firmware or software, whether that be a mobile phone, a laptop, a desktop, a router working as a repeater, or the main router. Yes, for all of them, not just Linux and Android. The order of priority should be: a. If you have Android 6+, then you *should* update soon. b. If you have MacOS or Linux, then you should update soon. c. If you have an 802.11r router, then you should update soon. If you have any wireless device you should update soon. I have no idea why you are categorizing them. You can take your sweet time on everything else, but everything needs to be updated. Why in the world would you say you can take your sweet time on them. They are all vulnerable. 4. The problem, of course, is *how* to update each device. a. First look for your device to see if there is an update https://www.kb.cert.org/vuls/id/228519 b. Then try to find the update http://www.zdnet.com/article/here-is-every-patch-for-krack-wi-fi-attack-available-right-now/ c. Then update. What a pain. Let me know if you have questions. So, 4 is the only thing you really need to say. Of course how you are going to update your fridge or your toaster is a bit obscure. Do you really want a "owned" wifi device anywhere on your internal network? |
#60
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-use attack yet?
He who is William Unruh said on Sun, 29 Oct 2017 14:47:35 -0000 (UTC):
No, whose interception point is close enough. Thus your wirelessly connected fridge, which usually has attrocious security, could possibly be used as an interception point for an attacker who is in Mongolia say. Interesting point. Thank you for that observation. I think what you're saying is that if they can get to *any* of your devices, over the Internet, then, *from those devices*, they can intercept your traffic to, for example, your Linux laptop or Android smart phone. But I'm confused about the risk in that case. Are they only intercepting from the refrigerator-to-the-client-device? Or are they then able to get from your router-to-your-client-device? (The latter would be more dangerous.) All wifi is susceptible, including Windows. The problem with Android and Linux is they all use wpa_supplicant and it has a problem that, for security, it zeros the password after using it. But that means that when the replay occurs it uses that 0 password. Thus fixing wpa_supplicant fixes the problem, and it has in principle been fixed. Of course one needs to get that fixed version into the devices. Here is a writeup I made for my family that others can use which shows just *one* example of fixing a WiFI device. In this case, it's a Ubiquti radio set up as an access point and only going about a half kilometer, but it could be set up to go for miles (as some of my other radios are set up). (0) Log into your radio http://wetakepic.com/images/2017/10/29/00_PB400_firmware_update_krack.jpg (1) Check the firmware version (noting the board revision, e.g., XW) http://wetakepic.com/images/2017/10/29/01_PB400_firmware_update_krack.jpg (2) Hit the "Check Now" button to see if you can update from here http://wetakepic.com/images/2017/10/29/02_PB400_firmware_update_krack.jpg (3) If not, go to the manufacturer's web site to locate the firmware file http://wetakepic.com/images/2017/10/29/03_PB400_firmware_update_krack.jpg (4) You may have to agree to the manufacturer's updated EULA http://wetakepic.com/images/2017/10/29/04_PB400_firmware_update_krack.jpg (5) Download the file to a known location on your computer http://wetakepic.com/images/2017/10/29/05_PB400_firmware_update_krack.jpg (6) Save the file in a logical location on your computer for future use http://wetakepic.com/images/2017/10/29/06_PB400_firmware_update_krack.jpg (7) Then in the radio, press the "Upload Firmware Choose File" button http://wetakepic.com/images/2017/10/29/07_PB400_firmware_update_krack.jpg (8) Wait for the firmware to upload (it may take a minute or two) http://wetakepic.com/images/2017/10/29/08_PB400_firmware_update_krack.jpg (9) Once uploaded, press the "Update" button to update the firmware http://wetakepic.com/images/2017/10/29/09_PB400_firmware_update_krack.jpg (10) Wait for the firmware to be updated (it may take a minute or two) http://wetakepic.com/images/2017/10/29/10_PB400_firmware_update_krack.jpg (11) Do not power down while you are waiting for the firmware to update http://wetakepic.com/images/2017/10/29/11_PB400_firmware_update_krack.jpg (12) When done, the radio will reboot; log back in to check results http://wetakepic.com/images/2017/10/29/12_PB400_firmware_update_krack.jpg (13) You should note that the firmware should now be updated http://wetakepic.com/images/2017/10/29/13_PB400_firmware_update_krack.jpg (14) Doublecheck now that everything is updated that it is working fine http://wetakepic.com/images/2017/10/29/14_PB400_firmware_update_krack.jpg So, 4 is the only thing you really need to say. Of course how you are going to update your fridge or your toaster is a bit obscure. Do you really want a "owned" wifi device anywhere on your internal network? I have over a dozen WiFi devices in my house.... so I'm updating them one by one. I'm more worried about my grandchildren not knowing how to update *their* devices, and my older siblings, etc. But I agree, it's a PITA to update *every* WiFi device in the house. I have over a half-dozen access point radios, for example, and a few on the roof, etc., some of which connect by WiFi to homes that are 10 miles away, so it's a pain for any of them. |
#61
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-useattack yet?
harry newton wrote:
I think what you're saying is that if they can get to *any* of your devices, over the Internet, then, *from those devices*, they can intercept your traffic to, for example, your Linux laptop or Android smart phone. I think in your case you say your house is out of wifi range of your neighbours; but since you're advising friends and family, it could be that one house's fridge/camera/thermostat hacks the neighbour's wifi traffic ... |
#62
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-use attack yet?
He who is Andy Burns said on Sun, 29 Oct 2017 16:53:03 +0000:
I think what you're saying is that if they can get to *any* of your devices, over the Internet, then, *from those devices*, they can intercept your traffic to, for example, your Linux laptop or Android smart phone. I think in your case you say your house is out of wifi range of your neighbours; but since you're advising friends and family, it could be that one house's fridge/camera/thermostat hacks the neighbour's wifi traffic ... I understand only the *basics* of that argument, which is that if you have device 0 (the router), and then client 1 (refrigerator) and client 2 (Android phone), and client 3 (linux laptop) that *all* are vulnerable. The basic argument is that if someone gets in on client 1, 2, or 3, then the *whole* network is compromised. But is it? If client 1 is a refrigerator with very poor security, I get it that they can hack easily into client 1. All I'm asking is how does access to client 1 give them access to router 0 which "controls" the entire LAN? |
#63
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
|
|||
|
|||
Did you update your router for the WPA2/PSK KRACK nonce re-useattack yet?
On 2017-10-29, harry newton wrote:
He who is Andy Burns said on Sun, 29 Oct 2017 16:53:03 +0000: I think what you're saying is that if they can get to *any* of your devices, over the Internet, then, *from those devices*, they can intercept your traffic to, for example, your Linux laptop or Android smart phone. I think in your case you say your house is out of wifi range of your neighbours; but since you're advising friends and family, it could be that one house's fridge/camera/thermostat hacks the neighbour's wifi traffic ... I understand only the *basics* of that argument, which is that if you have device 0 (the router), and then client 1 (refrigerator) and client 2 (Android phone), and client 3 (linux laptop) that *all* are vulnerable. The basic argument is that if someone gets in on client 1, 2, or 3, then the *whole* network is compromised. But is it? If client 1 is a refrigerator with very poor security, I get it that they can hack easily into client 1. All I'm asking is how does access to client 1 give them access to router 0 which "controls" the entire LAN? It doesn't directly. But they now have control of a wireless card, which they can adapt (software) to listen in on the traffic between your computer and the router (remember that the wireless signal goes everywhere), and can then subvert the communication between the computer and the router forcing the system into negotiation replay. I have no desire to figure out exactly how to do that, just that with fridges etc around with zero security, they have an in to your local network, and quite possibly can use that to run a Krack on the computer and the router. |
Reply |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
Severe flaw in WPA2 protocol leaves Wi-Fi traffic open to eavesdropping | Home Repair | |||
weller pyropen wpa2 | Electronics Repair | |||
Good morning or good evening depending upon your location. I want to ask you the most important question of your life. Your joy or sorrow for all eternity depends upon your answer. The question is: Are you saved? It is not a question of how good | Home Repair | |||
Good morning or good evening depending upon your location. I want to ask you the most important question of your life. Your joy or sorrow for all eternity depends upon your answer. The question is: Are you saved? It is not a question of how good | Woodworking | |||
Good morning or good evening depending upon your location. I want to ask you the most important question of your life. Your joy or sorrow for all eternity depends upon your answer. The question is: Are you saved? It is not a question of how good | UK diy |