Four years ago, when I first started learning Python, I came across a problem that would later on become a “Famous Question” on StackOverflow. You may be reading this article because you encountered the same problem.
Traceback (most recent call last): File “C:\Users\myname\documents\visual studio 2010\Projects\PythonApplication 1\PythonApplication1\RunSikuliOnVM.py”, line 97, in logging.config.dictConfig(LOG_DICT_CONFIG_OnVM) AttributeError: ‘module’ object has no attribute ‘config’ Press any key to continue . . .
So, I will quickly suggest you check what turned out to be my problem.
I had imported a module into my code and later on made reference to that module by calling a specific attribute, but there was no such attribute in the module. Or at least so thought my Python interpreter. The quick fix for the error that I had gotten turned out to clear the cache of my interpreter. An example of how to do that with an interpreter is in the documentation for PyCharm.
This seems to be what is meant by the Python 3 documentation when it warns that “multiple evaluations of the same attribute reference may yield different objects.” I extrapolate and conclude that the error I am observing is somewhat of a “different” result I am getting.
Now for those interested in understanding the AttributeError for its own sake, another part of the Python documentation describes the exception in these terms:
AttributeError :Raised when an attribute reference (see Attribute references) or assignment fails. (When an object does not support attribute references or attribute assignments at all,
TypeError is raised.)
The problem with the case at hand is that the config module does have a config attribute. This is why I posit that it is the caching issue that is the problem here since the interpreter may be referring to a totally different module than the logging module your code may be calling in this instance.
Note: This article is still in development even though it has been published to offer some beginning of a solution to those dealing with the AttributeError: ‘module’ object has no attribute ‘config’ exception.
UPDATE3: On a website dedicated to the “Key Reinstallation Attacks,” https://www.krackattacks.com/, the researcher who brought attention to this vulnerability describes what it is, presents a demo of the attack against an Android device as client, and suggests practical steps in a rich Q&A article.
UPDATE2: More companies have updates available. Microsoft also has released an update for client devices. (Source: Pileum Corporation)
If you have a Meraki access point, they have released a patch to address this issue. See below link for more information.
If you have an Aerohive access point, they have released a patch to address this issue. See below link.
SonicWALL has announced that their firewalls and access points are not vulnerable to the flaws in WPA2.
Cisco has released patches for some of their products that are affected. You can check for those products and updates as they are released here:
Microsoft has released a patch that provides additional protection on the client workstation. We recommend that this be installed on all workstations immediately.
UPDATE1: Several Wi-Fi AP manufacturers have started developing and releasing Updates. Please check the CERT website below for updates. One of the most recent ones is Meraki access point.
In a research paper titled “Key Reinstallation Attacks: Forcing Nonce Reuse in WPA,” Leuven, Belgium researchers Mathy Vanhoef and Frank Piessens just proved that WPA2 handshake traffic can be manipulated to induce nonce and session key reuse. Here is an overview of the announcement from CERT:
Wi-Fi Protected Access II (WPA2) handshake traffic can be manipulated to induce nonce and session key reuse, resulting in key reinstallation by a wireless access point (AP) or client. An attacker within range of an affected AP and client may leverage these vulnerabilities to conduct attacks that are dependent on the data confidentiality protocols being used. Attacks may include arbitrary packet decryption and injection, TCP connection hijacking, HTTP content injection, or the replay of unicast and group-addressed frames.
The simplest solution is to install updates provided by your Wi-Fi device vendor.
More on this here:
In an article on their website, Piriform, a company recently acquired by Avast, published the following apology.
Dear CCleaner customers, users and supporters,
We would like to apologize for a security incident that we have recently found in CCleaner version 5.33.6162 and CCleaner Cloud version 1.07.3191. A suspicious activity was identified on September 12th, 2017, where we saw an unknown IP address receiving data from software found in version 5.33.6162 of CCleaner, and CCleaner Cloud version 1.07.3191, on 32-bit Windows systems. Based on further analysis, we found that the 5.33.6162 version of CCleaner and the 1.07.3191 version of CCleaner Cloud was illegally modified before it was released to the public, and we started an investigation process. We also immediately contacted law enforcement units and worked with them on resolving the issue. Before delving into the technical details, let me say that the threat has now been resolved in the sense that the rogue server is down, other potential servers are out of the control of the attacker, and we’re moving all existing CCleaner v5.33.6162 users to the latest version. Users of CCleaner Cloud version 1.07.3191 have received an automatic update. In other words, to the best of our knowledge, we were able to disarm the threat before it was able to do any harm.
An unauthorized modification of the CCleaner.exe binary resulted in an insertion of a two-stage backdoor capable of running code received from a remote IP address on affected systems.
While more articles on this subject can be found on Spiceworks, a very commendable article about the incident was published by the The Thalos group who first discovered the breach into Avast’s servers.