Thanks. I think I understand now.
All except for one thing:
I can *barely* wrap my mind around the idea of getting executable code
from an RMI server, but what legitimate purpose could be served by
allowing a *logger* to resolve executable code?
--
JHHL
(And I have a fair amount of experienc
James,
On 12/13/21 14:48, James H. H. Lampert wrote:
On 12/13/21 10:53 AM, Mark Thomas wrote:
Log4j2 supports a log message format syntax that includes JNDI lookups.
Log4j2 processes log messages repeatedly until it doesn't find any
more format strings. This means the output of one format str
Jon,
On 12/13/21 12:48, jonmcalexan...@wellsfargo.com.INVALID wrote:
I understand Chris. I guess I was looking to see if he had contact
info for anyone on that particular project. I know it's not like a
"company".
It's just like Tomcat: they have a public mailing list.
-chris
-Original Me
On 12/13/21 10:53 AM, Mark Thomas wrote:
Log4j2 supports a log message format syntax that includes JNDI lookups.
Log4j2 processes log messages repeatedly until it doesn't find any more
format strings. This means the output of one format string can insert a
new format string.
. . .
Thanks. It
Le lun. 13 déc. 2021 à 14:11, Thomas Meyer a écrit :
> Hi,
>
> Interesting. I know a bit off topic..
>
> Does it make a difference for the vulnerability if I log with:
>
> a) log.warn("log msg param {}", userControlledParam);
>
> Or
>
> b) log.warn(log msg param " + userControlledParam);
>
>
No.
Hi,
Interesting. I know a bit off topic..
Does it make a difference for the vulnerability if I log with:
a) log.warn("log msg param {}", userControlledParam);
Or
b) log.warn(log msg param " + userControlledParam);
Mfg
Thomas
Am 13. Dezember 2021 19:53:04 MEZ schrieb Mark Thomas :
>On 13/12/
On 13/12/2021 18:31, James H. H. Lampert wrote:
The thing I'm still utterly unclear about is how simply logging traffic
could, by itself, create a vulnerability.
In our case, the log entries are not even viewable unless you are signed
on to a command line session on the server (ssh for headles
The thing I'm still utterly unclear about is how simply logging traffic
could, by itself, create a vulnerability.
In our case, the log entries are not even viewable unless you are signed
on to a command line session on the server (ssh for headless Linux; a
physical Twinax terminal, or a 5250 e
Ok, so I have been given clearance to share the stance that we are taking with
log4j. We have contacted Apache Security and are awaiting a response.
Before making a final decision around log4j 1.x, consider the following:
-Initially, 1.x wasn’t assessed for the vulnerability, because, it is end
I understand Chris. I guess I was looking to see if he had contact info for
anyone on that particular project. I know it's not like a "company".
Thanks though!
Dream * Excel * Explore * Inspire
Jon McAlexander
Infrastructure Engineer
Asst Vice President
Middleware Product Engineering
Enterpris
Jon,
On 12/13/21 11:51, jonmcalexan...@wellsfargo.com.INVALID wrote:
So, based on these entries on the log4j apache pages, I can't see
that any 1x product is vulnerable. Mark, is there some message from
Apache that we can share with those that need to know that for
certain 1x log4j is NOT vulner
So, based on these entries on the log4j apache pages, I can't see that any 1x
product is vulnerable. Mark, is there some message from Apache that we can
share with those that need to know that for certain 1x log4j is NOT vulnerable?
News
CVE-2021-44228
The Log4j team has been made aware of a s
Thanks, very useful information to channel back to my team and beyond.
-
Daniel Savard
Hi all,
thanks a lot to all for the quick replies. Not what I hoped to hear, but
hey - every new detail I learn about this issue turns out to be the
opposite of what I hope to hear.
Cheers,
Juri
On 12/13/21 4:17 PM, David Weisgerber wrote:
Hi,
our software was also affected but luckily not
> From: Juri Berlanda
> Sent: 13 December 2021 15:03
> Subject: [External] Re: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs
> compile time Java version
> Hi,
> we were affected - we use an AccessLogValve, which logs to Log4j2 and we
> use Log4j as java.util.logging LogManager. We already p
Hi,
our software was also affected but luckily not our Tomcat distribution.
I repeat, no JRE has a sufficient mitigation! You need to update log4j2 or set
the environment variables. The problem is that through log4j2 you can misuse
other library functions where the JRE mitigations would not prote
There have been multiple Patches for RMI and LDAP over time in Java.
The first article states which attack (from the one the researcher analyzed)
was possible in which version.
https://www.veracode.com/blog/research/exploiting-jndi-injections-java
https://github.com/mbechler/marshalsec/
If th
Hi,
we were affected - we use an AccessLogValve, which logs to Log4j2 and we
use Log4j as java.util.logging LogManager. We already patched, but only
on Saturday.
In any case: in a lot of places I saw "recent JRE versions have a
mitigation in place", but I can't seem to find which JRE version
HI Mark,
Thank you. That clarifies something I was not quite getting.
Surely setting a system property “log4j2.formatMsgNoLookups” does not require a
particular JRE version?
And no, it doesn’t.
Yes – we’d need to upgrade log4j2 and/or add that parameter. Whilst the JRE
version might deliver so
Tim,
Adding to what others have posted...
On 12/13/21 03:57, Scott,Tim wrote:
Suspecting that someone here knows the answer immediately, I thought I’d
ask.
If you do not know the answer, please don’t spend any time
investigating: I’ll do that later today and update everyone whether or
not I
On 13/12/2021 07:41, Saurav Sarkar wrote:
Hi All,
How does tomcat access valves/logs work ?
This is open source. You can look at the source code.
Since it prints the whole URL , will it be any issue if the access logs are
using Log4j2 implementation?
Again (with a minor update to the log4j
On 13/12/2021 09:21, David Weisgerber wrote:
Hi,
as far as I read through the details, it is a runtime option of the JRE. So, it
does not need any recompilation.
However, some websites pointed out that if you are using Tomcat you could
bypass the JRE protection.
Correct, it is the runtime ver
Hi,
as far as I read through the details, it is a runtime option of the JRE. So, it
does not need any recompilation.
However, some websites pointed out that if you are using Tomcat you could
bypass the JRE protection.
Best regards,
David
From: Scott,Tim
Sent: Monday, 13 December 2021 09:57
To:
Hi all,
Suspecting that someone here knows the answer immediately, I thought I'd ask.
If you do not know the answer, please don't spend any time investigating: I'll
do that later today and update everyone whether or not I find an answer.
Our security team advise that "Certain versions of the Ja
24 matches
Mail list logo
