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

331–340 of 531 posts

Re: Log4j RCE Found

#331

Post by HelloNurse »

svick wrote: post #306
michaelt wrote: post #242

Earlier quoted context omitted.

> A logging framework's job is to ship strings to stdout or files or something. I've seen people (including here on HN) dismiss libraries as "abandoned" when they went a year without a release. The software industry will never get bug-free, feature-complete software so long as we're selecting for the opposite.

How do you differentiate between "actually abandoned and probably dangerous" and "actively maintained, but updated only very rarely, because there's nothing left to do"?

By reputation, adoption, type of changes being made (e.g. "implemented correct alphabetical ordering with proper normalization" is less mature than "updated to latest Unicode standard, Cypro-Minoan is now allowed"), update schedules (e.g. once or twice a year right after someone opens an infrequent issue vs. once or twice a year during the maintainer's vacations), type of issues that remain open (e.g. "crashes if the description is too long", answer "use a shorter description", is less mature than "bad-looking text wrapping if the description is too long", answer "default column widths are compact, but you can customize them").

Re: Log4j RCE Found

#332

Post by HelloNurse »

Appallingly severe because instead of having to carefully corrupt the stack or guess malicious SQL queries the adversary is deliberately provided with a general interpreter, ready to run arbitrary downloaded code without checks.

Re: Log4j RCE Found

#333

Post by testplzignore »

raesene9 wrote: post #188
jsiepkes wrote: post #184

What adds to the confusion is that log4j2 rebrands itself as log4j. For example the Log4j2 artifact name is: `org.apache.logging.log4j:log4j-api` but it is actually Log4j2, not the original Log4j. There is plenty of stuff out there that still uses Log4j 1.7, 1.8, etc. I assume this is all about Log4j2? And not about the original Log4j? Or is the original Log4j also affected?

There are indications ( https://twitter.com/dlitchfield/status/1469199750452822017?s... ) that log4j1 can be affected too...

That tweet has since been deleted. I haven't seen anything so far to indicate that log4j v1 is affected.

Re: Log4j RCE Found

#334

Post by dystroy »

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.…

But you log strings, not bytes, meaning that the escape sequences are escaped, unless there's a severe bug in the logger.

Re: Log4j RCE Found

#335

Post by NelsonMinar »

spullara wrote: post #209
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…

This is just stupid. Logging should not do any side effects except writing to the log.

I agree. It reminds me a lot of XXE attacks on XML. You wouldn't expect parsing an XML file to open arbitrary network connections, would you? The spec says an XML parser should do that. A lot of parsers used to have that feature turned on by default, although I think by now most folks have wised up.

Re: Log4j RCE Found

#336

Post by lvh »

a-dub wrote: post #84
lvh wrote: post #73

Earlier quoted context omitted.

Eh. I think it's pretty reasonable that people assume their logging library doesn't have random RCE, and I think it's pretty reasonable people aren't going to be able to filter every parameter based on Log4J having a relatively obscure bug.

think about the complexity involved in a modern backend. those log messages are flowing through logging libraries and a local syslog at an absolute minimum. more exotic setups involve consolidators, indexing/searching, user interfaces that may be controlled by any number of operators. moreover, those who use these tools typically have the keys to the kingdom for their respective environments.

Right! What would filtering even look like? This seems like an unreasonable burden on the developer.

Re: Log4j RCE Found

#337

Post by lvh »

janekm wrote: post #272
brabel wrote: post #175

Earlier quoted context omitted.

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.

Though of course "debug.log(stuffIGotFromPeer)" is also very common (and as you point out should always be avoided).

Fortunately (and for reasons I can't begin to understand), debug and info logging levels seem to be safe, but error is not. Technically better, but somehow... morally worse?

Re: Log4j RCE Found

#338

Post by skim_milk »

TheRealDunkirk wrote: post #308

176K LOC. For a logging library? Oh! It's for Java. It all makes sense now. (Yes, I've written in Java, and, of course, I used log4j in the project.) Just reminds me of this: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

For comparison, in .NET Core the default logger and all extensions in the dotnet/runtime repo are 9014 LOC (19.5k if including tests)

    find -E src/libraries -iregex '.*\.cs$' | grep 'src/libraries/Microsoft.Extensions.Logging' | grep -v 'tests' | xargs cat | grep -v -e '^$' | wc -l

Re: Log4j RCE Found

#339

Post by twic »

_wldu wrote: post #324

A LSM in enforcing mode (such as SELinux or Tomoyo) on a Linux system would prevent this. I configure and run tomoyo on all my Internet facing servers. https://tomoyo.osdn.jp/

Or just a firewall rule to block outgoing connections. Basic security precautions prevent this attack against servers.

Re: Log4j RCE Found

#340

Post by d3nj4l »

dikei wrote: post #227
jsiepkes wrote: post #220

Logback has an interesting commit[1]: "disassociate logback from log4j 2.x as much as possible". They also updated their landing page [2]: "Logback is intended as a successor to the popular log4j project, picking up where log4j 1.x leaves off. Fortunately, logback is unrelated to log4j 2.x and does not share its vulnerabilities." Can't say I blame them. [1] https://github.com/qos-ch/logback/commit/b810c115e363081afc7…

This is such a cheap move by Logback, which comes from the former lead developer of Log4j 1. I used to like it for its technical merits: it's really much better than Log4j 1. But its development has stagnated, and it doesn't offer anything over Log4j2 nowadays. Furthermore, it's not an Apache project, it doesn't even use the Apache License, but LGPL.

Logback is dual licensed as LGPL and EPL (Eclipse Public License).
Post reply on HN