Waratek ARMR Remediation Patch
Only Waratek provides a fully programmable security platform that can remediate vulnerabilities, including CVE-2021-45046, CVE-2021-4104, CVE-2021-44228, and CVE-2021-45105.
The Log4Shell Problem
What this Means?
The vulnerability allows for unauthenticated remote code execution or Denial of Service (DoS) attacks, depending on the version of Log4j your code or dependencies depend on.
The severity of the vulnerabilities range from low severity due to requiring a non-standard Log4J configuration to the highest severity score that a vulnerability can have.
What can I do?
Within 12 hours of the Zero Day announcement Waratek delivered our first ARMR Remediation Patch. Waratek’s fully programmable security Platform ARMR enables you to fully remediate the vulnerable Log4j code inside your application’s live executing code in real-time without making changes to your codebase.
When you apply the ARMR Remediation Patch it applies to your entire stack of technologies that your application depends on, including obscure dependencies. To secure your vulnerable application with the ARMR Remediation Patch, click here.
ARMR Remediation Patch
Apply custom security rules as well as current and historical virtual patches for instant protection.
- Create and apply custom virtual patches
- Library of past CPUs
- Instant protection
- No downtime
- No source code changes
- Functional equivalent physical patches
- No break / No exploit guarantee
Physically patching known software flaws is time consuming and risky. That’s why traditional virtual patching, also referred to as virtual shielding, is often mentioned as a way to quickly protect applications against known CVEs. But, traditional virtual patches still leave you vulnerable to attack.
Only Waratek can fix the vulnerable code of a CVE with no downtime, no source code changes, and no tuning.
Waratek’s runtime virtual patching is fundamentally different. A runtime virtual patch is the functional equivalent of a physical binary patch that is applied while the application runs with no source code changes and no tuning required.
The known vulnerabilities are remediated, reducing the time-to-patch across an enterprise from weeks, months, or years to a matter of minutes.
CVE-2021-45105 explains how Log4j versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3) allows attackers to cause denial of service when a crafted string is interpreted causing a recursive lookup.
CVE-2021-45046 explains how Log4j version 2.15.0 was incomplete in certain non-default configurations.
Posted in the GitHub Advisory Database, CVE-2021-44228 explains how Log4j versions prior to 2.15.0 are subject to a remote code execution vulnerability via the ldap JNDI parser.
CVE-2021-4104 explains how Log4j version 1.2 is vulnerable to deserialization of untrusted data when the attacker causes JMSAppender to perform JNDI requests that result in remote code execution.