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

511–520 of 531 posts

Re: Log4j RCE Found

#511

Post by ptx »

mshanu wrote: post #504
jameshart wrote: post #474

Earlier quoted context omitted.

Because the string concatenation requires allocation of a new string, which will need to be garbage collected, regardless of whether or not the log.debug actually needs it. Using a format and args lets you call the method with only references to existing objects, no additional string needs to be allocated unless the log method actually needs to generate the string to log (and it might even be able to use streaming to…

ok, so its only gc overhead, and no security issue with it?

The first argument is code and the rest of the arguments are data, much like an SQL statement and its parameters. You could try to prove that whatever interprets the code in the first argument will never do anything dangerous no matter what it's supplied with, but then someone might add that dangerous feature later, as happened in this case.

To make it always work correctly, don't pass the data values as code. Although apparently[1] Log4j complicates this by mixing code with data even if you separate them, unless you tell it not to by saying "$m{nolookups}" instead of "%m".

[1] https://www.tasktop.com/blog-under-construction/log4j-2-the-...

Re: Log4j RCE Found

#513

Post by rank0 »

chmod775 wrote: post #505
rank0 wrote: post #498

Earlier quoted context omitted.

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

First off, how nice of you to quote only the first and last part of my comment while paraphrasing the middle part as if you're telling me something new: > 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) versus > You aren't understanding. You should only need one regex per input. Also you're hopping between sanitation and vali…

> Also you're hopping between sanitation and validation as if you believe they're the same thing. My original example was a case of doing specifically validation badly and you specifically spoke about validation in your original comment. You then replied with a comment suggesting one should apply encoding, specifically escaping, to inputs. That is not called validation.

You know what, I admit my writing isn't excellent. I'm fully aware of the difference between sanitization and validation and frequently lump them together in technical conversations. Input validation/sanitization along with OUTPUT encoding, are major security controls that should be present in your application and proper use of these techniques will protect you most of the time with your dependencies have a security flaw.

> At this point I don't know how to talk to you because you seem to make this conversation about something new with each comment and I'm past humoring it.

You replied to me saying that regex whitelists on untrusted input was "a horrible idea" and "objectively wrong". You argued that libraries should safely handle the untrusted input for you. You argued that validation/sanitization should not happen immediately upon receipt on the input. These points are just wrong. I'm not trying to be a dick, and I think its possible to have a constructive conversation here.

Full disclosure: My day job is as a web application pentester. I've tested/reviewed hundreds of applications.

I don't expect devs to be experts on security, but what triggered my ORIGINAL comment was all the software engineers ITT bashing open source libraries without considering security in their own code.

Re: Log4j RCE Found

#514

Post by unclebucknasty »

raxxorrax wrote: post #503
unclebucknasty wrote: post #486

Earlier quoted context omitted.

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…

That is a pretty far out security assessment. You have the same exploits in commercial software, just security through obscurity helps because of far less usage.

>That is a pretty far out security assessment

Yeah, I kind of thought that too as I was typing it, but it's so egregiously bad that I couldn't get around that conclusion.

>You have the same exploits in commercial software

Sure, virtually all software is susceptible to exploit. But, if someone were sending unsanitized strings to a database, and without using query parameters, etc., then we would all agree that's inexcusable after all of these years of knowing better.

IMO, this is in that category.

Re: Log4j RCE Found

#516

Post by KarlKemp »

janto wrote: post #491
unclebucknasty wrote: post #486

Earlier quoted context omitted.

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

I think we need fewer people that somehow manage to mangle logic to such a degree that they blame security vulnerabilities on the willingness of some project to state that it's generally preferred to treat each other with some respect.

Linus' insults were always cringeworthy. Sometimes they may have been justified, at other times they were just needlessly hurtful and revealed some sort of weakness on his part. In any case, he always had the power to say no with just that single word.

Log4J doesn't even have a code of conduct in its source tree, though I guess Apache probably has one. You'll get a free Log4j update if you find any instances of it having an impact on the project.

Re: Log4j RCE Found

#517

Post by mike22 »

rixed wrote: post #450
dikei wrote: post #215

Earlier quoted context omitted.

I'm not defending Log4j, but this error can really happen to many logging libraries. All logging libraries contain some kind of template engine as a performance optimization, in order to avoid actually generating the output string (can be costly) if logging is disabled. And template engines have always been a major source of vulnerabilities.

Apparently, from recent posts on this page, the problem is not solely caused by the fact that log4j perform some substitutions from a preset map, but that it performs substitution recursively, thus interpreting again the data injected into the string, with apparently no way to escape it, which I think very few logging libraries are doing. Imagine, you write SQL commands using the proper parametric form, such as: > ex…

> You would be right to expect the DB library to escape the string so that no SQL injection is possible.

SQL in some (hopefully good number of) cases is much safer than that. Going with MySQL prepared statements here: parameters are not sustituted into the SQL statement string, but rather sent as seperate data packets in the wire protocol.

Re: Log4j RCE Found

#518

Post by xpe »

janto wrote: post #491
unclebucknasty wrote: post #486

Earlier quoted context omitted.

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

> Codes of Conduct that prioritize belonging over, say, competence and truthfulness is not helping.

Example, please?

Re: Log4j RCE Found

#519

Post by xpe »

janto wrote: post #491
unclebucknasty wrote: post #486

Earlier quoted context omitted.

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

> Codes of Conduct that prioritize belonging over, say, competence and truthfulness is not helping.

What is your reasoning for suggesting that (i) codes of conduct are in tension with (ii) competence and truthfulness?

Re: Log4j RCE Found

#520

Post by xpe »

janto wrote: post #491
unclebucknasty wrote: post #486

Earlier quoted context omitted.

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

> 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

There is a difference between (a) maintaining high code quality and review standards and (b) yelling at people and/or degrading them.

With this in mind, think through the first-order and second-order effects that happen when toxic leadership behavior is allowed, tolerated, or encouraged in an open source project.

Toxic leadership in an open source project, all other things equal, harms the project and the people.

Of course, historically, there are cases where intelligent and committed people exhibit toxic behaviors -- but this is not a pattern of behavior for us to aspire to. Quite the opposite.

I understand that many people (including software developers) struggle in interpersonal interactions. I don't demonize people when they are unaware or lack the tools to treat others with respect. But these behaviors have huge negative effects, so it reasonable and beneficial to have fair, humane codes of conduct to mitigate such negative patterns of behavior.

Post reply on HN