When we receive a security issue we evaluate it and, if we identify it as a vulnerability, we will work to fix it or to propose a remediation according to the issue severity.
This section lists functionnal issues requiring urgent upgrade or mitigation actions. If the level of the issue does not require immediat actions the issue only apears in releases notes.
Always feel free to raise an issue on the help desk.
Punchplatform security advisories include a severity level. This severity level is based on our self-appreciation for each specific vulnerability for the Punchplatform product.
Severity Level: Critical
Vulnerabilities that score in the critical range usually have most of the following characteristics:
- Exploitation of the vulnerability likely results in root-level compromise of servers or infrastructure devices.
- Exploitation is usually straightforward, in the sense that the attacker does not need any special authentication credentials.
For critical vulnerabilities, is advised that you patch or upgrade as soon as possible, unless you have other mitigating measures in place.
For example, a mitigating factor could be if your installation is not accessible from the Internet.
Severity Level: High
Vulnerabilities that score in the high range usually have some of the following characteristics:
- The vulnerability is difficult to exploit.
- Exploitation could result in elevated privileges.
- Exploitation could result in a significant data loss or downtime.
Severity Level: Medium
Vulnerabilities that score in the medium range usually have some of the following characteristics:
- Vulnerabilities where exploitation provides only very limited access.
- Vulnerabilities that require user privileges for successful exploitation.
Severity Level: Low
Vulnerabilities in the low range typically have very little impact on an platform’s business. Exploitation of such vulnerabilities usually requires local or physical system access.
|Affects||Vulnerability summary||Mitigation||fixed in|
|CVE 2020-26296||2021-02-10||low||Vega||all versions before 6.4.0||Vega before version 5.17.3 there is an XSS vulnerability in Vega expressions||Upgrade to 6.4.0 or change settings
|CVE-2020-8203||07/15/2020||low||lodash||all versions before 6.3.4||Prototype pollution attack when using _.zipObjectDeep in lodash before 4.17.20.||Work in progress to upgrade internal dependency on punchplatform-plugin and punchplatform-feedback.||6.3.4|
|CVE-2020-7676||06/08/2020||low||angular||N/A||angular.js prior to 1.8.0 allows cross site scripting.||None of the embedded components provides a CVE based on this vulnerability.|
|CVE-2020-7017||07/27/2020||low||kibana||all versions before 6.4.0||The region map visualization in Kibana contains a stored XSS flaw.||Upgrade to 6.4.0 or change settings
|CVE-2020-7016||07/27/2020||low||Timelion||all versions before 6.4.0||Kibana versions before 6.8.11 and 7.8.1 contain a denial of service (DoS) flaw in Timelion.||Upgrade to 6.4.0 or change settings
|CVE-2018-6341||12/31/2018||low||reactN/A||N/A||React applications which rendered to HTML using the ReactDOMServer API were not escaping user-supplied attribute names||None of the embedded components provides CVE based on this vulnerability.||
This critical vulnerability allows attackers to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack. This vulnerability must be mitigate as soon as possible.
When can it occurs:
Several use cases are vulnerable. The most likely use case that could be faced is the runtime execution of the print method on a tuple containing a jndi pattern.
|Issue ID||Date||Level||Component||Affects||Issues summary||Mitigation||fixed in|
from 6.0 to 6.3.3 included
incorrect committing of unacknowledged offsets that can lead to unprocessed data in incident context
|#1742||2021-08-11||Minor||Standalone channels – Sourcefire and websense||
wrong version of geoip operator embedded in standalone
Last update 2022/01/10 : correction on Facing permission issues (replacing chmod by chown).
Update 2022/01/03 : Following returns from our customers, we detect permissions issues when applying the mitigation published on 2021/12/15.
Initial published date 2021/12/15.
The following ansible command allows you to remove all org/apache/logging/log4j/core/lookup/JndiLookup.class from the punchplatform’s jar.
ansible -m shell -a 'for file in $(find <punchplatform-setups_root> -name *.jar); do zip -sf $file | grep org/apache/logging/log4j/core/lookup/JndiLookup.class; if [ $? -eq 0 ]; then echo found in $file; zip -q -d $file org/apache/logging/log4j/core/lookup/JndiLookup.class; fi; done' -u <deploy-user> --become-user <punchplatform-daemon-user> -i <servers-inventory> <pattern-server> -b
- <punchplatform-setups_root> is defined by the setting setups_root of your punchplatform-deployment.settings
- <deploy-user> is a user with sufficient access to the setups_root directory and sub directories
- <punchplatform-daemon-user> is the user as defined in punchplatform-deployment.settings by platform.punchplatform_daemons_user
- <pattern-server> is a pattern matching all the servers of the punchplatform.
- <servers-inventory> is the inventory available in your deployer node at $PUNCHPLATFORM_CONF_DIR/generated_inventory/current-deployment.inv
Restart the impacted services
|WARNING : this steps can lead to outage and data loss. You must be sure to follow the best practices when you restart the services of your COTS.|
Restart services of the following cots:
Facing permission issues?
If you applied the mitigation before the update of the 2022/01/03 you might face issues to restart your application. It comes from a permission issue. The previous command changes the user of the modified jars to root. The following command allows you to set the good owner and group:
ansible -m shell -a 'for file in $(find <punchplatform-setups_root> -name *.jar -user root); do echo changing owner of $file; chown <punchplatform-daemon-user>:<punchplatform-daemon-user> $file; done' -u <deploy-user> -i <servers-inventory> <pattern-server> -b
"enable.auto.commit": false setting in the settings section of all your kafka input nodes. You can confirm that this setting is in effect by reading the settings applied by the consumer, at the start of the storm/shiva worker task logs.