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

Log4jmemes.com: for those of us that need a laugh

log4jmemes.com

Post reply on HN
Print view View original

101–110 of 115 posts

Re: Log4jmemes.com: for those of us that need a laugh

#101

Post by AnotherGoodName »

kerblang wrote: post #76
Finnucane wrote: post #21

Earlier quoted context omitted.

Okay, I know I am not a Real Programmer, but even I know that user content is to be Not Trusted. Isn't it like a Security 101 principle that user content is always potentially dangerous, and to be treated accordingly?

As best I've been able to tell, this was not an intentional feature; it was added by the original author for configuration , so that they could drop LDAP URL's into the log4j configuration file, thus using LDAP as a "configuration server". I don't think they realized this would cross paths with every single log message as well. Mind you, I also think that original intention was idiotic: Now your java application can'…

If you look at the change that caused this it was intended that incoming log statements pattern match jndi requests and run those. The only configuration in the change was to specify the pattern match for jndi. There was no intention to run jndi from the configuration, the intention was always to read log statements and run those.

It uses the routing appender that's intended to send logs different ways via string matching and added code that said if the string matching has ${jndi... it should run that jndi code.

The change did what it said it would do. Akin to someone submitting a patch to run eval(log_statment).

That it passed review and was accepted is frightening.

Re: Log4jmemes.com: for those of us that need a laugh

#102

Post by cesarb »

Sohcahtoa82 wrote: post #94
antsar wrote: post #43

Earlier quoted context omitted.

Not every application developer realized that writing a string to a log required trusting that string (its just a text file, what could go wrong!). Meanwhile, library developers didn't realize app devs would be feeding untrusted strings to their library. I guess its debatable who's more at fault. I'd argue a logging library that executes the log entries as code is a hell of a footgun. (Not a Java dev. Maybe log4j had…

> Meanwhile, library developers didn't realize app devs would be feeding untrusted strings to their library. What?! It's a logging library. I would expect users of it to be feeding user input, so that in the case of a bug, I can look at logs to see what input triggered a bug.

> It's a logging library. I would expect users of it to be feeding user input,

I agree with you, but I did see a couple of days ago someone with the diametrically opposite opinion: that we should never log user input, with a link to https://owasp.org/www-community/attacks/Log_Injection (plus this bug) as the justification.

Re: Log4jmemes.com: for those of us that need a laugh

#103

Post by Sohcahtoa82 »

mFixman wrote: post #98

Disclaimer: I know nothing about web development. My understanding is that Log4Shell vulnerabilities come from parsing `${jndi:ldap:path}` files coming from HTTP requests, which raises the question of why wasn't that input sanitised in the first place. Aren't `[${}]` in `$GET` and other HTTP headers normally replaced with sanitised strings to prevent these kinds of vulnerabilities?

What kind of sanitation needs to be done based on where the data is going. There is no "one size fits all" method of sanitizing because what sanitizes for one purpose will just make the data look like garbage in another.

ie, if the User-Agent is being reflected back to a user on the web page, then HTML entities such as need to be changed to < and > respectively. If it's being put in a SQL query, then quotes (both single and double) and backticks needs to be filtered. Of course, really you should be using parameterized queries so sanitation isn't necessary at all.

If your data is going straight into a log, nobody would expect that data needs to be sanitized, beyond possibly filtering \r and \n to prevent log forging via CRLF injection. I would expect it to not be sanitized, since then it's not clear based on the log what a user actually sent.

Re: Log4jmemes.com: for those of us that need a laugh

#104

Post by piva00 »

zaphar wrote: post #55
junon wrote: post #26

Earlier quoted context omitted.

I think you misunderstand the point of log4j. Logging is not free, and outputting to all three of those is quite expensive (especially in the Docker case, and it can even be dangerous as Docker - at least for a long time - did not implement proper backpressure and instead dropped logs). log4j allows libraries to implement logging and allow the end user to worry about where the logs go, at the application level, usual…

I'm not entirely sure libraries logging is a good idea anyway. I think there is a strong case that logging should be entirely an application concern not a library concern.

Have you never had to rely on logs from some JDBC library to figure out an issue in production? There are absolutely many reasons for a library to have logging, specially in the case of libraries providing tooling for anything that deals with networking (clients to any kind of services, serving requests through the network, etc.).

I think that an opaque library in terms of logging is absolutely hell to deal with, I already have my fair share of issues with libraries that don't do enough logging and require painful hours of debugging instead of reading a log...

Re: Log4jmemes.com: for those of us that need a laugh

#105

Post by Sohcahtoa82 »

cesarb wrote: post #102
Sohcahtoa82 wrote: post #94

Earlier quoted context omitted.

> Meanwhile, library developers didn't realize app devs would be feeding untrusted strings to their library. What?! It's a logging library. I would expect users of it to be feeding user input, so that in the case of a bug, I can look at logs to see what input triggered a bug.

> It's a logging library. I would expect users of it to be feeding user input, I agree with you, but I did see a couple of days ago someone with the diametrically opposite opinion: that we should never log user input, with a link to https://owasp.org/www-community/attacks/Log_Injection (plus this bug) as the justification.

Seems like a strange conclusion to draw. I mean, taking input from one user and presenting it to another creates the opportunity for XSS attacks, but obviously you wouldn't use that to argue that you should never show one user's input to another, because then no website could contain user-generated content. Forums would not exist and the entire web would be non-interactive.

Nah...logging user input is a must to be able to perform digital forensics and incident response. Certainly knowing exactly how an attack was triggered would help in preventing it in the future.

Just filter the CRs and LFs to prevent log forging, and make sure log files are not accessible from the web app. They should be in /var/log, not in the web root.

Re: Log4jmemes.com: for those of us that need a laugh

#106

Post by watwut »

tialaramex wrote: post #74
watwut wrote: post #60

Earlier quoted context omitted.

You would expect the foundation to prevent bugs? When did Apache even even claimed to be bug free?

I would expect the foundation's "Apache Way" to have the effects it claims, rather than in fact being a way to dismiss concerns and pretend everything is on track when it isn't. In particular the Apache Way includes: Responsible Oversight and The ASF Security Committee which you might think would be trying to stop stuff like this happening but really exists so that they can say they're responding to whatever new horr…

You don't know what responsible oversight is. You don't even know what foundation does do or does not do.

Re: Log4jmemes.com: for those of us that need a laugh

#107

Post by ArchOversight »

zinekeller wrote: post #92
upheaval7276 wrote: post #67

Earlier quoted context omitted.

I have this specific rule turned on in NextDNS. It’s sometimes annoying, but seems like a reasonable policy to block any newly registered domains as extra protection against phishing attempts.

Spamhaus et al. (corporate subscription), but same thing. If there's a noteworthy new domain, we'll check and whitelist it but otherwise silently disables phishing attempts. The one we have (which I don't know which specific lists) also detect new GitHub, AWS (S3), Azure (Windows Blob), and Google (Appspot et al.) subdomains.

As a former red-teamer, we would have long registered but otherwise dormant domains that did usual activities that is expected, like get TLS certs, and show some mail and whatnot...

It bypasses things of this nature ;-)

Re: Log4jmemes.com: for those of us that need a laugh

#108

Post by zaphar »

shagie wrote: post #66
zaphar wrote: post #55

Earlier quoted context omitted.

I'm not entirely sure libraries logging is a good idea anyway. I think there is a strong case that logging should be entirely an application concern not a library concern.

I've got a bug... the application that I've deployed isn't working in this configuration. It's not even hitting my controller for me to be able to log to a file. So, I kick the log level from warn to debug and I see that Spring is booting it because it failed a CORS check. This was much easier than trying to reproduce it in my local system and attach a debugger to it. There is a lot that goes on beneath and behind th…

Is this partly due to the fact that everyone is depending on the libraries having logs instead of throwing the correct exception? Then the application could log it.

Re: Log4jmemes.com: for those of us that need a laugh

#109

Post by shagie »

zaphar wrote: post #108
shagie wrote: post #66

Earlier quoted context omitted.

I've got a bug... the application that I've deployed isn't working in this configuration. It's not even hitting my controller for me to be able to log to a file. So, I kick the log level from warn to debug and I see that Spring is booting it because it failed a CORS check. This was much easier than trying to reproduce it in my local system and attach a debugger to it. There is a lot that goes on beneath and behind th…

Is this partly due to the fact that everyone is depending on the libraries having logs instead of throwing the correct exception? Then the application could log it.

A program working correctly with incorrect input isn't an exceptional case.

"This endpoint cannot be accessed in a CORS improper way" is caught in the library/framework level and doesn't even touch my code - there's no exception for me to catch.

Throwing a checked exception for no access rather than returning "false" from a library call because you passed in all upper case on case sensitive role check would be a decision that I wouldn't agree with.

Another example would be "I want to see the sql generated by hibernate" - that's not exception throwing at all, its me trying to debug what the query is and why the performance is awful.

Re: Log4jmemes.com: for those of us that need a laugh

#110

Post by kiney »

xunn0026 wrote: post #36
exabrial wrote: post #4

On a serious note, I think it's a good time to remember to donate some $ to open source, especially the Apache foundation for their incredible work over the years!

Biggest mistake EVER. The Apache Foundation DOES NOT redistribute any money to actual contributors. All money donated to Apache gets spend on their own infrastructure and salaries, etc.

same problem with wikipedia / wikimedia foundation
Post reply on HN