We have a user in our company that has Kicad 6.0.8 installed on their machine. In our security systems, this device is flagged as vulnerable due to a Log4j file in the location below:
Does the software still need this file? If yes, what can we do about eliminating the vulnerability? If not, we’ll delete the file.
\kicad\6.0\3rdparty\plugins\app_freerouting_kicad-plugin\jar\freerouting-1.6.2.jar
Thank you!
All “3rd party” tools “plugins” and Freerouting are all optional external stuff and not a part of the KiCad project itself and you can delete those files without damaging the base functionality of KiCad (but you would of course loose the functions that those plugins provide).
You can also unistal them from KiCad, with KiCad Project Manager / Plugin and Content Manager, and then type the name in the search box or browse though the list.
Don’t forget the Apply pending changes when you uninstall it.
I just used the email link under the plugin description to ask about this. We’ll see if they answer.
EDIT: This seems to be a strange one. The vulnerability seems to be related to running an Apache server and can be the victim of a DOS attack and was fixed in 2021. As the plugin was ported from an old version of JAVA it could be a false positive. Not sure it is exploitable outside of running a server, but, that’s about all the reading I’m prepared to do right now. 
Thank you @hermit for getting in touch with me directly.
The most recent version of the freerouting plugin is 1.8.0 which uses the latest log4j 2.20.
Could you try to update it?
We appreciate your taking the time to let us know. Welcome to the forum. I think the OP needs to update their Kicad as well.
Yes, KiCad is written in C++ and Python and does not use Java internally for exactly this sort of reason
Meh, no language or system is immune from vulnerabilities.
The language is not the main problem. It is the (ab)use of third party libraries and frameworks. KiCad has more than enough problems with wxWidgets
The reality though is that it’s impossible to write any sizable program without the use of libraries and frameworks. Unfortunately it means that a vulnerabilty in a widely used library will have a greater effect than one in a specialised one. Some years back there was an openssl flaw that affected a wide swathe of applications. After that more attention was paid to openssl development. Perhaps there should have been more diversity so that log4j wasn’t the only choice. Even languages are not immune, for example there once was a vulnerability in Perl’s default sort which used quicksort, which is O(n*log(n)) on average but could be turned into O(n^2) by choosing the data, which could lead to DoS.
Fortunately KiCad isn’t an application that will be Internet facing.
Heh, the log4j vulnerability in the context of desktop applications is absolutely the same as having Python be part of KiCad. Both allow arbitrary code execution lmao
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
