SVM performs many features not permitted by web browsers, so leverages an ActiveX control to accomplish these tasks (like patch publishing, remote scan, and software suggestions). We recently launched a new browser-agnostic user interface at svm.flexera.com but left out these ActiveX-dependent features. Instead, important tasks like patch publishing are being moved to the SVM Patch Publisher. We expect to launch the patching capability soon, but in the meantime, news of Internet Explorer reaching EOL may prompt you to seek an alternative sooner.   While many have moved away from Internet Explorer as their default browser, many have maintained it for specific use cases including running the SVM admin console. Others have gotten in front of this challenge by employing MS Edge and it’s IE mode feature that mimics the functionality of IE within Edge. Only those sites that you specifically configure (via policy) will use IE mode. To have sites open in IE mode, see the below steps: Step 1: Create an Enterprise Mode Site List or update your existing one; then, upload it to the Cloud Site Management experience. Microsoft Edge uses the site list to open sites in IE mode. To create a site list and configure neutral sites, read this documentation or use the Configure IE mode tool. You can now upload and manage your site list in a compliant cloud location. Step 2: Configure IE mode. Use group policies to configure IE mode. You will need to configure either an Internet Explorer or Microsoft Edge policy to open sites from the Enterprise Mode Site List in IE mode in Microsoft Edge. To learn how to configure these group policies, see this page.  You can configure all intranet sites to open in IE mode via policy as well, but using an Enterprise Mode Site List is the preferred method. This recording also steps through the setup. Once the above is completed you simply need to follow the same process as setting up SVM for use within IE. Launch MS edge with run as administrator and navigate to https://csi7.secunia.com to download and install the plugin (also using run as admin). Your patch publisher does not have to be changed nor anything else for the functionality of SVM to function as expected.  Please continue to watch for updates here in the community as we introduce important new updates to the SVM Patch Publisher in the weeks ahead.   ... View more

The following summary of Log4j is credited to Flexera Secunia Research's Lars Wiebusch CVE References CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-44832, CVE-2021-4104 Introduction In December 2021, a vulnerability in Apache Log4j drew widespread attention as the product is widely used, vulnerability is easily exploitable and, in many cases, offers direct and indirect remote vectors. This vulnerability is referenced by the CVE identifier CVE-2021-44228 and was responsibly disclosed to the maintainer by Chen Zhaojun of Alibaba Cloud's security team. It triggered an unprecedented run to analyze about every infrastructure imaginable. Software developers scrambled and still scramble to identify the effects of the Log4j vulnerability on their own products, right before and through a holiday season. Of course, entities wanting to exploit the vulnerability quickly jumped into action as well and soon after the initial disclosure, first Proof of Concepts (PoCs) were detected being tested within live environments and subsequently exploitation campaigns made use of more refined attacks [1] . This vulnerability disclosure also started further investigations through vulnerability researchers and Apache Log4j team members to see if further vulnerabilities exist and their search didn’t turn up empty: more issues came to light. Apache Log4j Overview The open-source project Apache Log4j is a logging package for the Java platform. What started with just basic logging functionality evolved into a framework that, among other features, can be expanded through plugins, custom layouts, filters, and lookups and offers audit capable logging (no loss of events during reconfiguration) [2] . The current, supported version is based on the Java 8 platform since the 2.13.x branch. The previous branches were based on Java 6 and Java 7 respectively and are not supported by the maintainer of Apache Log4j anymore. Such an amount of configurability and customizability can be used for great benefit in your own projects. However, one needs to be aware that such extensive functionality can also be more readily used against your own infrastructure through an attacker. The Java platform, which is the base for the Apache Log4j project, comes with several security concerns on its own already. Deserialization and serialization vulnerabilities frequently show up in Java platform-based applications and its manifold capabilities to load and create Java classes on the fly and remotely can be easily used both in beneficial and nefarious contexts. Vulnerability Details The Beginning (Remote Code Execution, CVE-2021-44228, 2.x) To have a look at how the vulnerability works, we must look at the Log4j functionality of lookups. Essentially, this functionality allows values to be added to the Log4j configuration [3] . One part of the functionality allows JNDI lookups where multiple protocols are supported – one being LDAP. If an attacker can control parts of what gets logged, then arbitrary code might be downloaded from an attacker-controlled LDAP server (or other JNDI endpoints). The request for the download will be initiated from your own system. Such control is not uncommon, just think about servers logging User-Agent HTTP headers, user names or chat messages from chat interfaces. A logged string may contain something like  and an attack will potentially go ahead. This vulnerability affects Apache Log4j versions prior to 2.15.0 and can be referenced via the CVE identifier CVE-2021-44228. Thread Context Map (Remote Code Execution, CVE-2021-45046, 2.x) However, the fix for CVE-2021-44228 in version 2.15.0 was incomplete, which led to the acknowledgement of a further vulnerability that is exploitable in certain configuration scenarios [4] . Essentially, exploitability relies on the use of a non-default Pattern Layout with a Context Lookup and where an attacker has control over Thread Context Map (MDC) input data. Said variant received the additional CVE identifier CVE-2021-45046. This vulnerability has been fixed in version 2.16.0 of Apache Log4j. Initially, the vulnerability was only expected to be exploitable to result in a Denial of Service (DoS) impact and was rated with a lower severity, but Apache revisited their analysis and admitted that arbitrary code execution is possible [5] . Thread Context Map Part 2 (Denial of Service, CVE-2021-45105, 2.x) The story could have ended there, but, unfortunately, a further vulnerability has been acknowledged shortly after [6] . The vulnerability, associated with the CVE identifier CVE-2021-45105, has a lower impact, namely, its remote exploitation through Thread Context Map data results in a Denial of Service (DoS) condition solely. The issue results from an uncontrolled recursion when handling self-referential lookups and causes a stack overflow and process termination in the end. The Apache Log4j team has released the version 2.17.0 to fix this CVE. To note, there are also fixed version releases in the 2.3.x and 2.12.x branches even though the Apache Log4j team doesn’t support the Java 6 and Java 7 platforms anymore. Users of Log4j need to keep in mind, that such lack of support will result in unfixed security issues down the road and thus such an update cannot be recommended. JDBC Appender (Limited Vector Code Execution, CVE-2021-44832, 2.x) Just when we were about to prepare for the arrival of the new year, another issue with the CVE identifier CVE-2021-44832 has been acknowledged by the Apache Log4j team and was fixed in the 2.17.1 release [7] . The use of the word ‘issue’ versus ‘vulnerability’ is intentional here as the issue requires an attacker to have the capabilities to modify a Log4j configuration to point the JDBC Appender to a malicious JNDI URI and thus hardly any real-world exploitation scenario seems imaginable when security best practices are being followed. In the case of remotely loading such configurations, the transfer must be adequately protected against Man-in-the-Middle (MitM) attacks for example. To call this issue a “Remote Code Execution (RCE) Vulnerability” appears to be a stretch with such requirements. Again, the Apache Log4j team also released versions in the 2.3.x and 2.12.x branches without supporting these branches properly. These fixed releases cannot be seriously recommended due to lack of future support. Apache Log4j End of Life Branch (Limited Vector Code Execution, CVE-2021-4104, 1.x) Even the Log4j 1.x version branch, which is End of Life (EOL) though, could be exposed to an exploitation scenario like the original vulnerability in the 1.2 version. However, similar to the JDBC Appender issue, the vector is severely more limited as any potential attacker needs to be able to modify the Log4j configuration [8] . Typically, such write access will be restricted to privileged persons when following security best practices and thus will likely result in a lower risk from this specific variation of the vulnerability. This variation affecting Apache Log4j versions 1.2.x can be referenced via the CVE identifier CVE-2021-4104. It is also typically referred to as “Log4Shell” even though the vectors and nature of the issue differ due to different feature sets of and implementation in Log4j when comparing the branches. Everyone must keep in mind that using any product version that is EOL constitutes a large risk on its own as security issues won’t get fixed. The recommendation, as always, is to upgrade any EOL versions to a supported and secure product version.   Stay secure!   References [1] https://blog.cloudflare.com/actual-cve-2021-44228-payloads-captured-in-the-wild/ [2] https://logging.apache.org/log4j/2.x/manual/index.html [3] https://logging.apache.org/log4j/2.x/manual/lookups.html [4] https://lists.apache.org/thread/83y7dx5xvn3h5290q1twn16tltolv88f [5] https://logging.apache.org/log4j/2.x/security.html [6] https://lists.apache.org/thread/6gxlmk0zo9qktz1dksmnq6j0fttfqgno [7] https://lists.apache.org/thread/s1o5vlo78ypqxnzn6p8zf6t9shtq5143 [8] https://lists.apache.org/thread/0x4zvtq92yggdgvwfgsftqrj4xx5w0nx   Related information Information about Flexera products Flexera's response to recent Apache Log4j vulnerabilities Getting informed, identifying, and assessing Log4j vulnerabilities with Flexera’s products Information about Revenera products Revenera's response to recent Apache Log4j vulnerabilities CVE definitions https://nvd.nist.gov/vuln/detail/CVE-2021-4104 https://nvd.nist.gov/vuln/detail/CVE-2021-44228 https://nvd.nist.gov/vuln/detail/CVE-2021-44832 https://nvd.nist.gov/vuln/detail/CVE-2021-45046 https://nvd.nist.gov/vuln/detail/CVE-2021-45105 ... View more