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

491–500 of 531 posts

Re: Log4j RCE Found

#491

Post by janto »

unclebucknasty wrote: post #486
smsm42 wrote: post #482

Earlier quoted context omitted.

That's stunning. People are screaming about SQL injections and such for decades now, every "programming 101 for complete doofuses" course has a chapter about it in the first ten pages, we have tools upon tools to detect patterns of using untrusted data as control... And yet, one of the most popular logging toolkits in one of the most popular languages has it built in as a feature - literally using untrusted and unfil…

I mean it's so inexplicably bad that it's hard to imagine it being an innocent mistake. You have to wonder if opening a ticket for such a feature then having someone (or yourself under another account) build it in such an egregious way is a possible vector for deliberately creating such exploits. If this feature was default enabled, then it's even more suspect. It's just such an esoteric thing. When you factor in thi…

OSS definitely has a reliability and credibility problem on its hands. Codes of Conduct that prioritize belonging over, say, competence and truthfulness is not helping. We need more people like the old Linus that are more concerned with the quality of the artifact than increasing the size of a community

Re: Log4j RCE Found

#492

Post by spion »

smsm42 wrote: post #484
janekm wrote: post #272

Earlier quoted context omitted.

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

TBH, this is a huge antipattern. You have to put some context in your logs, so it must be something like "debug.log("Got from peer: {}", stuffIGotFromPeer) or something like that. You can't complain printf(stuffIGotFromPeer) is dangerous, so here is the same. But in log4j, debug.log("Got from peer: {}", stuffIGotFromPeer) is as unsafe as the other one, too! There's no way to make it safe, as I understand.

Don't see why not. Evaluate the `${}` stuff first, then do the `{}` substitutions.

Re: Log4j RCE Found

#493

Post by chmod775 »

rank0 wrote: post #481
chmod775 wrote: post #460

Earlier quoted context omitted.

"You cannot use this character in your name because it trips up our logging library".

Are you seriously arguing that you don’t think input validation is required for untrusted input? There’s a myriad of security vulnerabilities based off failing to escape special characters. Use output encoding if you need usernames to have special chars. There’s really no excuse to not sanitize input it’s a basic security principle.

My original comment is a joke to security minded people, because if pentesters/crooks see you're handling your inputs in that manner, they know to keep looking.

Nobody in their right mind will sanitize (and specifically not encode), on receipt, something like a name to be safe for every logging library, query language, or output in HTML/terminal/etc their backend may use. Such an undertaking is even provably impossible for combinations where one component requires escape sequences that again would need to be escaped for something else - in a circular manner. And that's just one thing that's objectively wrong about the idea.

Beyond the rules applicable to the specific type of input (for example: it should be a correctly UTF-8 encoded string with a maximum length), you treat all user inputs as opaque binary/character/whatever blobs within your system. That means your system certainly never parses such a blob looking for 'magic characters'. And only once you're going to do absolutely anything with it you apply sanitation as required for the target - and you make sure it always happens automatically as a matter of process. For example: your SQL client library will automatically build queries in a safe manner, your HTML template library will escape all provided strings by default, and your logging library will not look for magic characters in format string arguments - that's what the damn format string itself is for!

By all means use whitelists of characters for user-provided inputs (if you know what you're doing and are not going to prevent 2 billion people from using your software because you just deleted their alphabets). But don't even try to accommodate your random assortment of current and future backend technology at that point.

Re: Log4j RCE Found

#494

Post by spion »

jcheng wrote: post #344
layer8 wrote: post #302

Earlier quoted context omitted.

> I agree that the input should be sanitized but only if the formatting behavior is a bug and was not intentional. Non-pattern arguments should not do any substitution, because otherwise developers have to jump through hoops to output strings verbatim. You don’t want "Invalid identifier: '${ }'" to be turned into "Invalid identifier: ' '" when the actual invalid identifier (e.g. from user input) was the "${…}" syntax…

I was so surprised by the behavior your comment describes that I didn't believe it, but it's true. And it's not a bug, they do this on purpose! From https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/... : > Variable replacement works in a recursive way. Thus, if a variable value contains a variable then that variable will also be replaced. And an example where this caused problems for someone: https://www.t…

Recursive replacement is somewhat of a WTF yes but not really in a causitive relationship ro this vulnerability, right? The main cause is the order in which ${} variables are evaluated. They are evaluated after substitution of `{}` in the format string, instead of before. That's the key behavior problem.

A simple rule such as "If you evaluate a placeholder of type `{}` you should stop evaluating further recursively" would maintain most of existing behavior while only removing vulnerable behavior.

Re: Log4j RCE Found

#495

Post by 400thecat »

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

can you show an example how that would work ?

Re: Log4j RCE Found

#496

Post by einpoklum »

unclebucknasty wrote: post #486
smsm42 wrote: post #482

Earlier quoted context omitted.

That's stunning. People are screaming about SQL injections and such for decades now, every "programming 101 for complete doofuses" course has a chapter about it in the first ten pages, we have tools upon tools to detect patterns of using untrusted data as control... And yet, one of the most popular logging toolkits in one of the most popular languages has it built in as a feature - literally using untrusted and unfil…

I mean it's so inexplicably bad that it's hard to imagine it being an innocent mistake. You have to wonder if opening a ticket for such a feature then having someone (or yourself under another account) build it in such an egregious way is a possible vector for deliberately creating such exploits. If this feature was default enabled, then it's even more suspect. It's just such an esoteric thing. When you factor in thi…

Alexander Dumas once said:

> Une chose qui m'humilie profondément est de voir que le génie humain a des limites, quand la bêtise humaine n'en a pas.

So, never discount human stupidity :-(

Re: Log4j RCE Found

#497

Post by cplusplusfellow »

abhishekjha wrote: post #415
cplusplusfellow wrote: post #400

Earlier quoted context omitted.

In this case the library is using JNDI to go get a class from an LDAP server to execute.

But where does it get used? I mean the loading of a remote class on an LDAP server. Was this an opt-in or is it like properly baked in?

You would call out to JNDI in a logging statement. That would cause the remote class to be loaded and executed during the log statement evaluation.

A nefarious attacker could inject such a JNDI reference in a field (like username or whatever) and if you wrote your log statements in a manner that didn’t expect such injection to happen, it could become part of the log format instead of a log field value, and this would be executed.

Think of it like SQL injection but with log statements and way worse because it calls a class that can be hosted on a server of choice. And the code that can execute is arbitrary and not limited to the database.

Re: Log4j RCE Found

#498

Post by rank0 »

chmod775 wrote: post #493
rank0 wrote: post #481

Earlier quoted context omitted.

Are you seriously arguing that you don’t think input validation is required for untrusted input? There’s a myriad of security vulnerabilities based off failing to escape special characters. Use output encoding if you need usernames to have special chars. There’s really no excuse to not sanitize input it’s a basic security principle.

My original comment is a joke to security minded people, because if pentesters/crooks see you're handling your inputs in that manner, they know to keep looking. Nobody in their right mind will sanitize (and specifically not encode), on receipt, something like a name to be safe for every logging library, query language, or output in HTML/terminal/etc their backend may use. Such an undertaking is even provably impossib…

> Nobody in their right mind will sanitize (and specifically not encode), on receipt, something like a name to be safe for every logging library, query language, or output in HTML/terminal/etc their backend may use. Such an undertaking is even provably impossible for combinations where one component requires escape sequences that again would need to be escaped for something else - in a circular manner. And that's just one thing that's objectively wrong about the idea.

You aren't understanding. You should only need one regex per input. It's super easy. Developers should understand what data their applications expect to receive from a client.

From OWASP:

"Input validation is performed to ensure only properly formed data is entering the workflow in an information system, preventing malformed data from persisting in the database and triggering malfunction of various downstream components. *Input validation should happen as early as possible in the data flow*, preferably as soon as the data is received from the external party."

See https://owasp.org/www-community/Injection_Flaws for more details.

> For example: your SQL client library will automatically build queries in a safe manner, your HTML template library will escape all provided strings by default, and your logging library will not look for magic characters in format string arguments - that's what the damn format string itself is for!

Except when those libraries fail. Just like in the headline for TFA. Libraries can't always fix insecure application logic.

I don't understand how you think additional security checks are somehow detrimental. If I know some URL parameter should be a 16 character alphanumeric string, it should take you about 10 seconds to make a regex for that.

Post reply on HN