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

Log4Shell update: second Log4j vulnerability published

lunasec.io

Post reply on HN
Print view View original

121–130 of 289 posts

Re: Log4Shell update: second Log4j vulnerability published

#121

Post by thow-58d4e8b »

boublepop wrote: post #80
geerlingguy wrote: post #3

This is the vulnerability that keeps on giving. The annoying thing is, since it is evolving and attacks are spreading (and it has rightly gotten the attention of nearly everyone's IT department), we're hitting a stage where almost every customer is emailing daily asking for updates on mitigations based on evolving CVE discussions. I'd rather people be over-vigilant rather than pass on it, but mitigation is taking a b…

It’s a process circus. Once something gets raised as a critical IT issue in a large org, it’s not enough to “just fix the problem” or state that you aren’t affected due to network security etc. You have to report about it, which means you likely need a comment from a vendor. The most humorous thing for me about this entire situation is that the way reporting is handle in many orgs is: Central IT: Are we vulnerable in…

Somewhat gruesome, because this is exactly how a lot of these vulnerabilities are "handled"

Re: Log4Shell update: second Log4j vulnerability published

#122

Post by mschuster91 »

boublepop wrote: post #80
geerlingguy wrote: post #3

This is the vulnerability that keeps on giving. The annoying thing is, since it is evolving and attacks are spreading (and it has rightly gotten the attention of nearly everyone's IT department), we're hitting a stage where almost every customer is emailing daily asking for updates on mitigations based on evolving CVE discussions. I'd rather people be over-vigilant rather than pass on it, but mitigation is taking a b…

It’s a process circus. Once something gets raised as a critical IT issue in a large org, it’s not enough to “just fix the problem” or state that you aren’t affected due to network security etc. You have to report about it, which means you likely need a comment from a vendor. The most humorous thing for me about this entire situation is that the way reporting is handle in many orgs is: Central IT: Are we vulnerable in…

The log4j v1 RCE is (IIRC!) only applicable when you run it in SocketServer mode... which most users don't.

So yes, a dumb scanner will whine, but intelligent users will see it's a false alarm.

Re: Log4Shell update: second Log4j vulnerability published

#123

Post by iSnow »

atoav wrote: post #114
bullen wrote: post #94

Calendar date = Calendar.getInstance(); PrintStream ps = new PrintStream(new FileOutputStream(new File("log.txt")), true, "UTF-8"); ps.write(new SimpleDateFormat("yy-MM-dd HH:mm:ss.SSS").format(date.getTime()) + " message that does not need LDAP".getBytes("UTF-8")); 3 lines that replace 1705KB of log4j-core-2.14.1.jar "It does more than that..." I hear you mutter... yes it does more than that! Please build something…

> From scratch and with minimalism as a guideline. I am not sure I ever saw a minimal Java program (but I am not a Java programmer, so maybe it is just my limited perspective).

Really, what's the point of a quip like this? That's like saying I never saw a Lisp program that didn't have a lot of brackets.

Minimal only makes sense within one language ecosystem. Java tends to be more verbose than some other languages, I guess that is common knowledge.

Re: Log4Shell update: second Log4j vulnerability published

#124

Post by gjulianm »

trasz wrote: post #113
madmax108 wrote: post #103

Earlier quoted context omitted.

"Alexa, define yak-shaving"

How is reminding of the fundamental problem of dependencies’ impact on security a yak-shaving?

I mean, if we decided to build everything from scratch using only the OS and a programming language, we wouldn't be building any products. Recommending using a hilariously basic log (straight to file, no modules/level control, no buffer to avoid performance hits, no multithread support) instead of using a established library for logging is pretty naive. Yes, one should know that dependencies can introduce security problems, but the protection against that is not "remove all dependencies and build everything yourself".

Re: Log4Shell update: second Log4j vulnerability published

#125

Post by iSnow »

trasz wrote: post #113
madmax108 wrote: post #103

Earlier quoted context omitted.

"Alexa, define yak-shaving"

How is reminding of the fundamental problem of dependencies’ impact on security a yak-shaving?

Because in a company setting at least, you will soon discover that you need more than file-based logs in the specific format some coder defined for his pet project. So, you start logging to a database which is easy enough and then you start writing some simple templating code so that different logalizers can work on the logs etc. And then you discover that your logging is slowing down the whole application as more users are added and so on.

In the end, you implement a subset of log4j, just worse. What you should have looked at is one of the lighter logging libraries and use slf4fj to switch them out if you need more.

Re: Log4Shell update: second Log4j vulnerability published

#126

Post by hvgk »

staticassertion wrote: post #117
hvgk wrote: post #70

Earlier quoted context omitted.

This is one reason I like Go. It’s exactly the opposite to Java in that respect.

Go packages its own templating language, doesn't quite scream "minimal".

I think that’s a separate point. It does include a template language because Go is “batteries included”.

You can write productive stuff without having to import any third party packages at all. Everything you need is properly supported by the core team and written to the same standard.

Re: Log4Shell update: second Log4j vulnerability published

#127

Post by rob74 »

jacquesm wrote: post #83
heyoni wrote: post #64

Earlier quoted context omitted.

Only once. At Facebook: https://krebsonsecurity.com/2019/03/facebook-stored-hundreds...

And google: https://www.theverge.com/2019/5/21/18634842/google-passwords...

...and you can assume that for every case you hear of, there are at least 50 that you didn't hear of, because if you do end up logging passwords, it's something you're likely to want to keep under wraps if possible.

Re: Log4Shell update: second Log4j vulnerability published

#128

Post by hvgk »

stickfigure wrote: post #58
NaturalPhallacy wrote: post #55

Earlier quoted context omitted.

I would run screaming from such an organization.

I run screaming towards such organizations. Higher bill rates!

This person gets it. As always if it’s a shit show, charge by the hour and get double time! If it’s easy charge by the job and spend two months getting paid to play solitaire!

Re: Log4Shell update: second Log4j vulnerability published

#129

Post by lnx01 »

albert_e wrote: post #57
mac-chaffee wrote: post #30

Earlier quoted context omitted.

Here's the alleged original Jira ticket: https://issues.apache.org/jira/browse/LOG4J2-313 PS: Don't post snarky comments on an 8-year old Jira ticket, please.

interesting that this feature request was turned around in one day!

The feature request and feature were written by the same person.

Re: Log4Shell update: second Log4j vulnerability published

#130

Post by Quekid5 »

staticassertion wrote: post #118
oneweekwonder wrote: post #102

Earlier quoted context omitted.

Played around with python for a similar attack and while it needs import and usage of f-string's i was rather taken back how easy it would be to spam the internet with `f"""{exec("import urllib.request;urllib.request.urlopen(' http://localhost:8000').read ()")}"""` and variants, see what servers bite and then try to send them a more potent attack. So i personally believe log4sh type attacks across languages will beco…

Can you elaborate? I don't see how you would exploit Python with a string like that unless there's an `eval` somewhere in Python's logger? I wouldn't exactly put it past the language, for sure, but I'm not aware of that being the case. The reason this works in the java library is that the library explicitly adds functionality to evaluate the strings that are passed in, and has a meta-language for computing based on t…

    Python 3.10.1 (main, Dec 11 2021, 17:22:55) [GCC 11.1.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> print(f"""{print("hello")}""")
    hello
    None
So Python runs the expression in { } and interpolates the result into the string.

Presumably the { } has access to anything that's in scope.

(I'm not quite sure how common patterns are, but I assume the person is replying to is imagining a scenario where an attack is able to put some string payload into the { } before interpolation.)

Post reply on HN