Closed teinertt closed 3 years ago
Hello @teinertt, we are planning to include all the security fixes for the next release of Mangle scheduled for end of Jan 2021. Upgrade of the packages will require additional testing effort and that is the reason why we are clubbing the changes with the next release. Will that timeline work for you? If not let me know.
Hi @aswathy-ramabhadran, we are trying to be finished with our project by end of Dec 2020 so waiting until end of Jan 2021 would not work for us unfortunately. Is there anything that can be done about just the critically vulnerable packages mentioned?
Hello @teinertt we will get back to you on when we can resolve the security vulnerabilities for 2.0.0. We will see if we can accommodate and push that change earlier.
Thanks @aswathy-ramabhadran. We have also found the following that need to be updated. Any newer version should suffice.
com.fasterxml.jackson.core_jackson-databind - 2.9.8 libbz2-1.0,bzip2 - 1.0.6-8.1 log4j_log4j - 1.2.17 Java - 1.8.0_181 - critical patch update available through Oracle
We've identified the same vulnerabilities in our scans. We're making these updates as we speak and would be happy to share it with the community as soon as we can. I'm hoping within the next couple weeks, if we can get the CLA pushed through legal on our end, but this may (unfortunately) be early January as well.
@rglastra Thank you for the update.
@teinertt We have upgraded to latest version of the dependencies and the changes are now available in the repo and the .ova + container images. Some of the packages that you have mentioned here are not direct dependencies for Mangle however we expect most of the vulnerabilities to be addressed now. Let us know if you see any issues.
@aswathy-ramabhadran Thank you for this update, and thanks to everyone who helped get this resolved. If there any more issues I will let you know.
@aswathy-ramabhadran I see that you mentioned you were able to pull latest version and it had the issue fixed, but wondering which version was this exactly. Was it mangle 2 itself? OR was it mangle 3? We are currently using mangle 2 for our POC and wondering if we should be pulling mangle 3 or not for our POC.
@aswathy-ramabhadran I see that you mentioned you were able to pull latest version and it had the issue fixed, but wondering which version was this exactly. Was it mangle 2 itself? OR was it mangle 3? We are currently using mangle 2 for our POC and wondering if we should be pulling mangle 3 or not for our POC.
The vulnerabilities are fixed in Mangle version 2.0.1 as well as 3.0. If you are looking for a POC, it would be better to pull the latest version 3.0.
The above reported vulenerabilties seem to be still existing on newer versions. Couldnt attach files so pasting information. First list correlelates with secodn list items in the order listed.
com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind apache tomcat_tomcat-embed-core io.netty_netty-codec com.fasterxml.jackson.core_jackson-databind log4j_log4j com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind io.netty_netty-codec io.netty_netty-codec
FasterXML jackson-databind 2.x before 2.9.10.4 mishandles the interaction between serialization gadgets and typing, related to br.com.anteros.dbcp.AnterosDBCPConfig (aka anteros-core).
FasterXML jackson-databind 2.x before 2.9.10.4 mishandles the interaction between serialization gadgets and typing, related to com.ibatis.sqlmap.engine.transaction.jta.JtaTransactionConfig (aka ibatis-sqlmap).
FasterXML jackson-databind 2.x before 2.9.10.4 mishandles the interaction between serialization gadgets and typing, related to org.apache.hadoop.shaded.com.zaxxer.hikari.HikariConfig (aka shaded hikari-config).
FasterXML jackson-databind 2.0.0 through 2.9.10.2 lacks certain xbean-reflect/JNDI blocking, as demonstrated by org.apache.xbean.propertyeditor.JndiConverter.
When using the Apache JServ Protocol (AJP), care must be taken when trusting incoming connections to Apache Tomcat. Tomcat treats AJP connections as having higher trust than, for example, a similar HTTP connection. If such connections are available to an attacker, they can be exploited in ways that may be surprising. In Apache Tomcat 9.0.0.M1 to 9.0.0.30, 8.5.0 to 8.5.50 and 7.0.0 to 7.0.99, Tomcat shipped with an AJP Connector enabled by default that listened on all configured IP addresses. It was expected (and recommended in the security guide) that this Connector would be disabled if not required. This vulnerability report identified a mechanism that allowed: - returning arbitrary files from anywhere in the web application - processing any file in the web application as a JSP Further, if the web application allowed file upload and stored those files within the web application (or the attacker was able to control the content of the web application by some other means) then this, along with the ability to process a file as a JSP, made remote code execution possible. It is important to note that mitigation is only required if an AJP port is accessible to untrusted users. Users wishing to take a defence-in-depth approach and block the vector that permits returning arbitrary files and execution as JSP may upgrade to Apache Tomcat 9.0.31, 8.5.51 or 7.0.100 or later. A number of ch
The ZlibDecoders in Netty 4.1.x before 4.1.46 allow for unbounded memory allocation while decoding a ZlibEncoded byte stream. An attacker could send a large ZlibEncoded byte stream to the Netty server, forcing the server to allocate all of its free memory to a single decoder.
FasterXML jackson-databind 2.x before 2.9.10.2 lacks certain net.sf.ehcache blocking.
Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data. This affects Log4j versions up to 1.2 up to 1.2.17.
A Polymorphic Typing issue was discovered in FasterXML jackson-databind 2.0.0 through 2.9.10. When Default Typing is enabled (either globally or for a specific property) for an externally exposed JSON endpoint and the service has the apache-log4j-extra (version 1.2.x) jar in the classpath, and an attacker can provide a JNDI service to access, it is possible to make the service execute a malicious payload.
A Polymorphic Typing issue was discovered in FasterXML jackson-databind before 2.9.10. It is related to net.sf.ehcache.hibernate.EhcacheJtaTransactionManagerLookup.
A Polymorphic Typing issue was discovered in FasterXML jackson-databind 2.0.0 through 2.9.10. When Default Typing is enabled (either globally or for a specific property) for an externally exposed JSON endpoint and the service has the p6spy (3.8.6) jar in the classpath, and an attacker can find an RMI service endpoint to access, it is possible to make the service execute a malicious payload. This issue exists because of com.p6spy.engine.spy.P6DataSource mishandling.
A Polymorphic Typing issue was discovered in FasterXML jackson-databind 2.0.0 through 2.9.10. When Default Typing is enabled (either globally or for a specific property) for an externally exposed JSON endpoint and the service has the commons-dbcp (1.4) jar in the classpath, and an attacker can find an RMI service endpoint to access, it is possible to make the service execute a malicious payload. This issue exists because of org.apache.commons.dbcp.datasources.SharedPoolDataSource and org.apache.commons.dbcp.datasources.PerUserPoolDataSource mishandling.
A Polymorphic Typing issue was discovered in FasterXML jackson-databind before 2.9.10. It is related to com.zaxxer.hikari.HikariDataSource. This is a different vulnerability than CVE-2019-14540.
A flaw was discovered in FasterXML jackson-databind in all versions before 2.9.10 and 2.10.0, where it would permit polymorphic deserialization of malicious objects using the xalan JNDI gadget when used in conjunction with polymorphic type handling methods such as enableDefaultTyping()
or when @JsonTypeInfo is using Id.CLASS
or Id.MINIMAL_CLASS
or in any other way which ObjectMapper.readValue might instantiate objects from unsafe sources. An attacker could use this flaw to execute arbitrary code.
A flaw was discovered in jackson-databind in versions before 2.9.10, 2.8.11.5 and 2.6.7.3, where it would permit polymorphic deserialization of a malicious object using commons-configuration 1 and 2 JNDI classes. An attacker could use this flaw to execute arbitrary code.
A Polymorphic Typing issue was discovered in FasterXML jackson-databind before 2.9.10. It is related to com.zaxxer.hikari.HikariConfig.
SubTypeValidator.java in FasterXML jackson-databind before 2.9.9.2 mishandles default typing when ehcache is used (because of net.sf.ehcache.transaction.manager.DefaultTransactionManagerLookup), leading to remote code execution.
HttpObjectDecoder.java in Netty before 4.1.44 allows a Content-Length header to be accompanied by a second Content-Length header, or by a Transfer-Encoding header.
HttpObjectDecoder.java in Netty before 4.1.44 allows an HTTP header that lacks a colon, which might be interpreted as a separate header with an incorrect syntax, or might be interpreted as an \"invalid fold.\"
The above reported vulenerabilties seem to be still existing on newer versions. Couldnt attach files so pasting information. First list correlelates with secodn list items in the order listed.
python2.7 file nss bzip2 systemd glibc ch.qos.logback_logback-core glibc glibc glibc libidn python2.7 io.netty_netty-all io.netty_netty-all java
Python 2.7.x through 2.7.16 and 3.x through 3.7.2 is affected by: Improper Handling of Unicode Encoding (with an incorrect netloc) during NFKC normalization. The impact is: Information disclosure (credentials, cookies, etc. that are cached against a given hostname). The components are: urllib.parse.urlsplit, urllib.parse.urlparse. The attack vector is: A specially crafted URL could be incorrectly parsed to locate cookies or authentication data and send that information to a different host than when parsed correctly. This is fixed in: v2.7.17, v2.7.17rc1, v2.7.18, v2.7.18rc1; v3.5.10, v3.5.10rc1, v3.5.7, v3.5.8, v3.5.8rc1, v3.5.8rc2, v3.5.9; v3.6.10, v3.6.10rc1, v3.6.11, v3.6.11rc1, v3.6.12, v3.6.9, v3.6.9rc1; v3.7.3, v3.7.3rc1, v3.7.4, v3.7.4rc1, v3.7.4rc2, v3.7.5, v3.7.5rc1, v3.7.6, v3.7.6rc1, v3.7.7, v3.7.7rc1, v3.7.8, v3.7.8rc1, v3.7.9.
cdf_read_property_info in cdf.c in file through 5.37 does not restrict the number of CDF_VECTOR elements, which allows a heap-based buffer overflow (4-byte out-of-bounds write).
In Network Security Services (NSS) before 3.46, several cryptographic primitives had missing length checks. In cases where the application calling the library did not perform a sanity check on the inputs it could result in a crash due to a buffer overflow.
BZ2_decompress in decompress.c in bzip2 through 1.0.6 has an out-of-bounds write when there are many selectors.
A vulnerability in unit_deserialize of systemd allows an attacker to supply arbitrary state across systemd re-execution via NotifyAccess. This can be used to improperly influence systemd execution and possibly lead to root privilege escalation. Affected releases are systemd versions up to and including 239.
stdlib/canonicalize.c in the GNU C Library (aka glibc or libc6) 2.27 and earlier, when processing very long pathname arguments to the realpath function, could encounter an integer overflow on 32-bit architectures, leading to a stack-based buffer overflow and, potentially, arbitrary code execution.
QOS.ch Logback before 1.2.0 has a serialization vulnerability affecting the SocketServer and ServerSocketReceiver components.
An SSE2-optimized memmove implementation for i386 in sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S in the GNU C Library (aka glibc or libc6) 2.21 through 2.27 does not correctly perform the overlapping memory check if the source memory range spans the middle of the address space, resulting in corrupt data being produced by the copy operation. This may disclose information to context-dependent attackers, or result in a denial of service, or, possibly, code execution.
The glob function in glob.c in the GNU C Library (aka glibc or libc6) before 2.27 contains a buffer overflow during unescaping of user names with the ~ operator.
The GNU C Library (aka glibc or libc6) before 2.27 contains an off-by-one error leading to a heap-based buffer overflow in the glob function in glob.c, related to the processing of home directories using the ~ operator followed by a long string.
Integer overflow in the decode_digit function in puny_decode.c in Libidn2 before 2.0.4 allows remote attackers to cause a denial of service or possibly have unspecified other impact.
urllib in Python 2.x through 2.7.16 supports the local_file: scheme, which makes it easier for remote attackers to bypass protection mechanisms that blacklist file: URIs, as demonstrated by triggering a urllib.urlopen(\'local_file:///etc/passwd\') call.
HttpObjectDecoder.java in Netty before 4.1.44 allows a Content-Length header to be accompanied by a second Content-Length header, or by a Transfer-Encoding header.
HttpObjectDecoder.java in Netty before 4.1.44 allows an HTTP header that lacks a colon, which might be interpreted as a separate header with an incorrect syntax, or might be interpreted as an \"invalid fold.\"
Vulnerability in the Java SE, Java SE Embedded, JRockit component of Oracle Java SE (subcomponent: Scripting). Supported versions that are affected are Java SE: 8u182 and 11; Java SE Embedded: 8u181; JRockit: R28.3.19. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, JRockit. While the vulnerability is in Java SE, Java SE Embedded, JRockit, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Java SE, Java SE Embedded, JRockit. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), that load and run untrusted code (e.g. code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g. through a web service which supplies data to the APIs. CVSS 3.0 Base Score 9.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H).
The above reported vulenerabilties seem to be still existing on newer versions. Couldnt attach files so pasting information. First list correlelates with secodn list items in the order listed.
com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind apache tomcat_tomcat-embed-core com.fasterxml.jackson.core_jackson-databind log4j_log4j com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind org.apache.tika_tika-core
FasterXML jackson-databind 2.x before 2.9.10.4 mishandles the interaction between serialization gadgets and typing, related to br.com.anteros.dbcp.AnterosDBCPConfig (aka anteros-core).
FasterXML jackson-databind 2.x before 2.9.10.4 mishandles the interaction between serialization gadgets and typing, related to com.ibatis.sqlmap.engine.transaction.jta.JtaTransactionConfig (aka ibatis-sqlmap).
FasterXML jackson-databind 2.x before 2.9.10.4 mishandles the interaction between serialization gadgets and typing, related to org.apache.hadoop.shaded.com.zaxxer.hikari.HikariConfig (aka shaded hikari-config).
FasterXML jackson-databind 2.0.0 through 2.9.10.2 lacks certain xbean-reflect/JNDI blocking, as demonstrated by org.apache.xbean.propertyeditor.JndiConverter.
When using the Apache JServ Protocol (AJP), care must be taken when trusting incoming connections to Apache Tomcat. Tomcat treats AJP connections as having higher trust than, for example, a similar HTTP connection. If such connections are available to an attacker, they can be exploited in ways that may be surprising. In Apache Tomcat 9.0.0.M1 to 9.0.0.30, 8.5.0 to 8.5.50 and 7.0.0 to 7.0.99, Tomcat shipped with an AJP Connector enabled by default that listened on all configured IP addresses. It was expected (and recommended in the security guide) that this Connector would be disabled if not required. This vulnerability report identified a mechanism that allowed: - returning arbitrary files from anywhere in the web application - processing any file in the web application as a JSP Further, if the web application allowed file upload and stored those files within the web application (or the attacker was able to control the content of the web application by some other means) then this, along with the ability to process a file as a JSP, made remote code execution possible. It is important to note that mitigation is only required if an AJP port is accessible to untrusted users. Users wishing to take a defence-in-depth approach and block the vector that permits returning arbitrary files and execution as JSP may upgrade to Apache Tomcat 9.0.31, 8.5.51 or 7.0.100 or later. A number of ch
FasterXML jackson-databind 2.x before 2.9.10.2 lacks certain net.sf.ehcache blocking.
Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data. This affects Log4j versions up to 1.2 up to 1.2.17.
A Polymorphic Typing issue was discovered in FasterXML jackson-databind 2.0.0 through 2.9.10. When Default Typing is enabled (either globally or for a specific property) for an externally exposed JSON endpoint and the service has the apache-log4j-extra (version 1.2.x) jar in the classpath, and an attacker can provide a JNDI service to access, it is possible to make the service execute a malicious payload.
A Polymorphic Typing issue was discovered in FasterXML jackson-databind before 2.9.10. It is related to net.sf.ehcache.hibernate.EhcacheJtaTransactionManagerLookup.
A Polymorphic Typing issue was discovered in FasterXML jackson-databind 2.0.0 through 2.9.10. When Default Typing is enabled (either globally or for a specific property) for an externally exposed JSON endpoint and the service has the p6spy (3.8.6) jar in the classpath, and an attacker can find an RMI service endpoint to access, it is possible to make the service execute a malicious payload. This issue exists because of com.p6spy.engine.spy.P6DataSource mishandling.
A Polymorphic Typing issue was discovered in FasterXML jackson-databind 2.0.0 through 2.9.10. When Default Typing is enabled (either globally or for a specific property) for an externally exposed JSON endpoint and the service has the commons-dbcp (1.4) jar in the classpath, and an attacker can find an RMI service endpoint to access, it is possible to make the service execute a malicious payload. This issue exists because of org.apache.commons.dbcp.datasources.SharedPoolDataSource and org.apache.commons.dbcp.datasources.PerUserPoolDataSource mishandling.
A Polymorphic Typing issue was discovered in FasterXML jackson-databind before 2.9.10. It is related to com.zaxxer.hikari.HikariDataSource. This is a different vulnerability than CVE-2019-14540.
A flaw was discovered in FasterXML jackson-databind in all versions before 2.9.10 and 2.10.0, where it would permit polymorphic deserialization of malicious objects using the xalan JNDI gadget when used in conjunction with polymorphic type handling methods such as enableDefaultTyping()
or when @JsonTypeInfo is using Id.CLASS
or Id.MINIMAL_CLASS
or in any other way which ObjectMapper.readValue might instantiate objects from unsafe sources. An attacker could use this flaw to execute arbitrary code.
A flaw was discovered in jackson-databind in versions before 2.9.10, 2.8.11.5 and 2.6.7.3, where it would permit polymorphic deserialization of a malicious object using commons-configuration 1 and 2 JNDI classes. An attacker could use this flaw to execute arbitrary code.
A Polymorphic Typing issue was discovered in FasterXML jackson-databind before 2.9.10. It is related to com.zaxxer.hikari.HikariConfig.
SubTypeValidator.java in FasterXML jackson-databind before 2.9.9.2 mishandles default typing when ehcache is used (because of net.sf.ehcache.transaction.manager.DefaultTransactionManagerLookup), leading to remote code execution.
Apache Tika before 1.14 allows Java code execution for serialized objects embedded in MATLAB files. The issue exists because Tika invokes JMatIO to do native deserialization.
BTW the above findings are based on twistlock scans. 3 posts above, one for each of (mangle 3, cassandra 1, mangle vc adapter 3). I am still trying to get the information about which corresponding latest versions for the above are the fixes for these. Sorry for multiple posts above, but this is the best I could do as I cant edit the posts for some reason from with in our corporate network
Hello,
Hello @tektalent,
Apologize for the late response.
You can add the version number at the end of the command to pull specific versions (eg: docker pull mangleuser/mangle:2.0.1). Please refer to the attached screenshot.
[cid:image001.jpg@01D709E5.22321FB0]
From: tektalent notifications@github.com<mailto:notifications@github.com> Sent: Wednesday, February 17, 2021 11:41 PM To: vmware/mangle mangle@noreply.github.com Cc: Aswathy Ramabhadran aramabhadaran@vmware.com; Mention mention@noreply.github.com Subject: Re: [vmware/mangle] Security Vulnerabilities (#42)
@aswathy-ramabhadranhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Faswathy-ramabhadran&data=04%7C01%7Caramabhadaran%40vmware.com%7C26d23762290d446bd6f408d8d36f56f5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637491822477990368%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gjXzufdanB9Kp07T73mwN3TyBkd5zQwohYw5rFgY3IU%3D&reserved=0 From the docker hub how do I get specific versions? All I see is the following on docker hub that probably pulls which ever is the latest, but if I want to pull and play with different versions, pls provide specific pull commands for 2.0.1 as well as version 3. I need to have our internal repo management team pull specific version 3 and have them security scanned, before we use them, so we need to make sure they can pull with specific version numbers.
docker pull mangleuser/mangle_vcenter_adapter docker pull mangleuser/mangle docker pull mangleuser/mangle_cassandradb
- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvmware%2Fmangle%2Fissues%2F42%23issuecomment-780746589&data=04%7C01%7Caramabhadaran%40vmware.com%7C26d23762290d446bd6f408d8d36f56f5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637491822477990368%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TGYV1ObwPG2rizhIQ4l%2FpKPwUUG1TQ3kpHXqRLPL00g%3D&reserved=0, or unsubscribehttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAIOWKYYNJ5UXERTTVZWB7FDS7QBCDANCNFSM4TPVGEZQ&data=04%7C01%7Caramabhadaran%40vmware.com%7C26d23762290d446bd6f408d8d36f56f5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637491822478000354%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=T0FC63M6fNZIEibdI0RQ6StSyWengGyPOkcytQNcu%2Bg%3D&reserved=0.
Hello @tektalent,
There are internal recommendations from VMware as to what is the expected versions to upgrade to. We rely on IBM app scan and are following the same recommendations.
If there are specific versions that you need to upgrade to and if it doesn't align with what we have pushed, you can pull the code from the public repository update the dependencies and create your own container images as well. That would probably work out faster for you.
Let us know what support you need from us to proceed.
Regards, Aswathy
From: tektalent notifications@github.com Sent: Friday, February 19, 2021 10:51 PM To: vmware/mangle mangle@noreply.github.com Cc: Aswathy Ramabhadran aramabhadaran@vmware.com; Mention mention@noreply.github.com Subject: Re: [vmware/mangle] Security Vulnerabilities (#42)
We did "twistlock" scan on latest versions available (cassandra 1, mangle 3, mangle vc adapter 3). The following are the criticals that still showing up. Due to this our Infosec team are not happy so far. It doesnt seem like any of the above reported vulnerabilties from previous versions (cassandra 1, mangle 2.0.0, mangle vc adapter 2.0.0) are fixed at all. We were hopefull that version 3 would have fixes for these. I am still in the process of getting which corresponding higher versions for the below are supposed to have fixes.
Mangle 3
dockerdevregistry.fhlmc.com com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind apache tomcat_tomcat-embed-core io.netty_netty-codec com.fasterxml.jackson.core_jackson-databind log4j_log4j com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind io.netty_netty-codec io.netty_netty-codec
Cassandra 1
python2.7 file nss bzip2 systemd glibc ch.qos.logback_logback-core glibc glibc glibc libidn python2.7 io.netty_netty-all io.netty_netty-all java
mangle vcenter
com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind apache tomcat_tomcat-embed-core com.fasterxml.jackson.core_jackson-databind log4j_log4j com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind com.fasterxml.jackson.core_jackson-databind org.apache.tika_tika-core
- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvmware%2Fmangle%2Fissues%2F42%23issuecomment-782216384&data=04%7C01%7Caramabhadaran%40vmware.com%7Cade87801530f4c9de09d08d8d4faae71%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637493520524273291%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7qsBpd4uuH6%2Bxjnih9eIIPvWRWQGOEcKDXGoWhvhrOo%3D&reserved=0, or unsubscribehttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAIOWKY6RRI2QPKVGDQTS4X3S72MWRANCNFSM4TPVGEZQ&data=04%7C01%7Caramabhadaran%40vmware.com%7Cade87801530f4c9de09d08d8d4faae71%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637493520524283284%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Xp8KWN6bJ2Cl5F2UIeuMNT8DP8Rm3XqF86qGDF5lX3w%3D&reserved=0.
Hi Mangle Team,
My team and I are trying to deploy Mangle for use on a client engagement and ran a vulnerabilities check against the dependencies and executables packages. We have found numerous critical vulnerabilites and were hoping to get some help updating the versions of these packages. Would it be possible for this to be done? Below is a list of the critical security vulnerabiltes and known fixed versions. If you need any more information please let me know.
package > current version > fixed version
apache tomcat_tomcat-embed-core 9.0.19 fixed in 9.0.31, 8.5.51, 7.0.100 ch.qos.logback_logback-core 1.1.3 fixed in 1.2.0 com.fasterxml.jackson.core_jackson-databind 2.9.8 fixed in 2.9.10.4 io.netty_netty-all 4.0.44.Final fixed in 4.1.44 io.netty_netty-codec 4.1.33.Final fixed in 4.1.46 libbz2-1.0,bzip2 1.0.6-8.1 open libc-bin,multiarch-support,libc6 glibc 2.24-11+deb9u3 fixed in 2.24-11+deb9u4 libidn11 1.33-1 fixed in 1.33-1+deb9u1 libmagic-mgc,libmagic1,file 1:5.30-1+deb9u2 fixed in 1:5.30-1+deb9u3 libpython2.7-stdlib,libpython2.7-minimal,python2.7-minimal,python2.7 2.7.13-2+deb9u3 fixed in 2.7.13-2+deb9u4 libsystemd0,libudev1 232-25+deb9u6 fixed in 232-25+deb9u10 org.apache.tika_tika-core 1.7 fixed in 1.14