Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Log4j RCE Found

lunasec.io

Post reply on HN
Print view View original

431–440 of 531 posts

Re: Log4j RCE Found

#431

Post by cjcampbell »

nyxmare wrote: post #167
Fabricio20 wrote: post #6

Earlier quoted context omitted.

Yes, more specifically after Java 8u191 you need to flag the client with: -Dcom.sun.jndi.ldap.object.trustURLCodebase=true -Dcom.sun.jndi.rmi.object.trustURLCodebase=true While RCE is not possible without these flags, you will still get pingback, in minecraft's example, allowing you to get the IP of everyone connected.

so, thats mean its impossible to get RCE without those flag?

It is still possible to RCE, but you won’t be able to achieve it using the proof of concept code. See the article for resources that describe alternative methods to exploit.

Re: Log4j RCE Found

#432

Post by anuragrsk »

LOG4J2-2109 wrote: post #159
nightpool wrote: post #108

Earlier quoted context omitted.

Note that the formatMsgNoLookups workaround only applies to recent versions of the log4j library, while it's still unclear how far back this bug may stretch. Other options for patching are detailed in the thread: https://github.com/apache/logging-log4j2/pull/608#issuecomme... mentions that just removing the class providing the vulnerable behavior works well, and https://github.com/Glavo/log4j-patch is a JAR that you…

The 'formatMsgNoLookups' property was added in version 2.10.0, per the JIRA Issue LOG4J2-2109 [1] that proposed it. Therefore the 'formatMsgNoLookups=true' mitigation strategy is available in version 2.10.0 and higher, but is no longer necessary with version 2.15.0, because it then becomes the default behavior [2][3]. If you are using a version older than 2.10.0 and cannot upgrade, your mitigation choices are: - Modi…

is log4j also has this security issue or this is only in log4j2?

Re: Log4j RCE Found

#433

Post by abhishekjha »

Nursie wrote: post #284
GrayShade wrote: post #273

Earlier quoted context omitted.

I'm not the grandparent, but there's been a slew of deserialization-related vulnerabilities in Java and .NET libraries where user input is used to instantiate arbitrary classes and invoke methods on them.

Lot of them in jackson in recent years, IIRC.

Is that why ConcurrentHashmap uses a RB-tree in worst case scenario, as in if there are too many collisions in a bucket?

Re: Log4j RCE Found

#434

Post by dontchooseanick »

mcintyre1994 wrote: post #426

Does anyone know the details of how this got discovered and released? It definitely doesn’t sound like a normal responsible disclosure process if it was discovered a few hours before this post. Was it spotted being abused?

See the reddit netsec thread [0] . There is evidence of attackers having the exploit since April 2021, thus the disclosure.

> Was it spotted being abused.

No, not at 2021-12-10 AFAIK, just spotted being spread.

[0] https://reddit.com/r/netsec/comments/rcwws9/rce_0day_exploit...

Re: Log4j RCE Found

#436

Post by barkingcat »

hawk_ wrote: post #110
jrockway wrote: post #76

So a lot of people sound mad that the logging library is parsing the inputs, and maybe they should be, but the truly paranoid should also be aware that your terminal also parses every byte given to it (to find in-band signalling for colors, window titles, where the cursor should be, etc.). This means that if a malicious user can control log lines, they can also hide stuff if you're looking at the logs in a terminal.…

While that's an interesting vector for attack, is it realistically an issue? Terminals are run as root all the time. I would guess any mainstream ones are well reviewed to not have such exploits work. Are you aware of any actual attacks exploiting terminal parsing in the wild?

I'd be wary of the assumption that mainstream terminals are well reviewed. I'd think terminal software are one of those less glamorous software that doesn't get any attention at all.

similarly to shells and base/foundational software (like logging libraries).

Bash itself goes for long spans of time without updates in their release versions https://git.savannah.gnu.org/cgit/bash.git

Re: Log4j RCE Found

#437

Post by barkingcat »

FDSGSG wrote: post #300
hawk_ wrote: post #110

Earlier quoted context omitted.

While that's an interesting vector for attack, is it realistically an issue? Terminals are run as root all the time. I would guess any mainstream ones are well reviewed to not have such exploits work. Are you aware of any actual attacks exploiting terminal parsing in the wild?

>Terminals are run as root all the time. I would guess any mainstream ones are well reviewed to not have such exploits work This is a really ridiculous assumption.

yah this is saying "I use this all the time so someone else must be making it safe to use!"

Re: Log4j RCE Found

#438

Post by altdataseller »

Lots of things missing from everyone telling how to mitigate this:

1) how do I check what version of log4j I am using?

2) how do I upgrade my log4j version 2 to the latest? I download the new zip, then what?

Re: Log4j RCE Found

#439

Post by Nursie »

abhishekjha wrote: post #433
Nursie wrote: post #284

Earlier quoted context omitted.

Lot of them in jackson in recent years, IIRC.

Is that why ConcurrentHashmap uses a RB-tree in worst case scenario, as in if there are too many collisions in a bucket?

I'm not sure that's related here? Jackson is a JSON and XML serialiser/deserialiser, and it has a bunch of ways to automatically serialise and deserialise things into objects, without being provided a template. This is where the danger lies, if you just let it do its thing it can be exploited as it will load classes that the input data asks for. There have been a number of RCEs about this in recent years

I'm not sure what that has to do with the performance of concurrenthashmap under heavy collisions... ?

Re: Log4j RCE Found

#440

Post by abhishekjha »

Nursie wrote: post #439
abhishekjha wrote: post #433

Earlier quoted context omitted.

Is that why ConcurrentHashmap uses a RB-tree in worst case scenario, as in if there are too many collisions in a bucket?

I'm not sure that's related here? Jackson is a JSON and XML serialiser/deserialiser, and it has a bunch of ways to automatically serialise and deserialise things into objects, without being provided a template. This is where the danger lies, if you just let it do its thing it can be exploited as it will load classes that the input data asks for. There have been a number of RCEs about this in recent years I'm not sure…

If I understand correctly most of the query params or POST body JSON gets mapped to a hashmap via Jackson and then POJOs gets created which can actually be an attack vector in terms of collison.

[0]https://fahrplan.events.ccc.de/congress/2011/Fahrplan/attach...

[1]https://openjdk.java.net/jeps/180

[2]https://stackoverflow.com/questions/8669946/application-vuln...

Post reply on HN