Closed qz-fordham closed 3 years ago
hi, Is cruisecontrol affected by this vulnerability CVE-2019-17571 (https://nvd.nist.gov/vuln/detail/CVE-2019-17571) ?
I read somewhere: "log4j is vulnerable to remote code execution (RCE). A malicious user can pass a malicious binary to the system that when deserialized, executes arbitrary code. This only affects applications that are using the TCP socket server or the UDP socket server to receive log events from another application"
in case of cruise-control does it open any server port or it only interacts via log4j library?
@qz-fordham Also, I see this being discussed in kafka github and looks there is a patch, may be useful to you. please see below https://github.com/apache/kafka/pull/7898
@qz-fordham @priyavj08 Do you need some help? I am the author of the PR above (KIP-653: Upgrade log4j to log4j2) and some of my friends told me that lots of kafka-ecosystem tools are also suffering from this problem. :cry:
@priyavj08 @qz-fordham This vulnerability does not affect Cruise Control as it does not listen to untrusted network traffic for log data.
That being said, Cruise Control uses SLF4J API
with Log4j
implementation, which it should migrate away from. I created a PR to make SLF4J API
use Log4j2
as the implementation. Once it is merged to master
, we will make it available in migrate_to_kafka_2_5
, as well.
@dongjinleekr Thanks for chiming in! We look forward to your future contributions to CC.
Hope it helps!
Thank you @efeg
I saw quite a lot of code change in that PR. It was an impressive speed to have this fixed.
This is regarding log4j deserialization vulnerability .
I am looking at branch migrate_to_kafka_2_5 and I think it's still using log4j 1.2.x, which may expose to potential attack. Is there a plan to remediate this issue or what will be the approach to resolve this from a LinkedIn point of view?
Thank you in advance.