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

91–100 of 115 posts

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

#91

Post by remram »

linkdd wrote: post #7

The one about using print/console.log/whatever lol. I've always done this, never have I used a library for this, because: - running manually? >myapp.log 2>&1 - using systemd? use journalctl - using docker/kubernetes? capture automatically the stdout/stderr of your containers and pipe them through logstash or something Real question: why would an application need to know where its logs go? This is not in the business…

Yeah as a non-Java user I have to say I'm very surprised. I wouldn't recommend just using print(), but a library needs to do very little (format like printf, filter by level (maybe depending on source file), output to text or JSON).

I don't understand how people would use a library as massive as log4j and not bother looking at what's in the box, and what they need to enable/disable. Blaming it on the opensource product seems weird when you grabbed it for free and didn't even read what's written on the box.

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

#92

Post by zinekeller »

upheaval7276 wrote: post #67
zinekeller wrote: post #40

Earlier quoted context omitted.

> Corporate VPN: "This site is blocked due to a security threat." IT: Domain too new, so we're blocking it out of abundance of caution. (Works for blocking new and targeted threats, but you get this false-positive block.)

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.

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

#93

Post by Sohcahtoa82 »

randomNumber7 wrote: post #10
linkdd wrote: post #7

The one about using print/console.log/whatever lol. I've always done this, never have I used a library for this, because: - running manually? >myapp.log 2>&1 - using systemd? use journalctl - using docker/kubernetes? capture automatically the stdout/stderr of your containers and pipe them through logstash or something Real question: why would an application need to know where its logs go? This is not in the business…

> Am I wrong? You are not a real Java Programmer then.

Being a Java programmer without being a "real" Java programmer would be a feature, not a bug.

Imagine being able to enjoy the Java syntax without feeling the need to write everything with a minimum of three levels of abstraction!

Break free of the tyranny of getters and setters! Make that integer public!

No more oppression from type introspection! Hang Spring and Hibernate from the gallows!

The Java revolution starts TODAY!

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

#94

Post by Sohcahtoa82 »

antsar wrote: post #43
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?

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.

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

#96

Post by Sohcahtoa82 »

truffdog wrote: post #32
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?

Yup. But sometimes people get excited about all the time saving convenience of 'eval()'.

`eval()` is such a serious code smell.

I will admit that I've used it, though. I have an IRC bot written in Python with a "!calc" command that calls eval(). But I use `ast` to build the syntax tree, then walk it and compare every AST object to a white list so you can only use numbers and math operators. Anything else, such as CALLs or strings will throw an error.

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

#97

Post by dotancohen »

kgeist wrote: post #52
IgorPartola wrote: post #33

As a Python developer, I am so happy right now.

Today I was tasked to audit our system for uses of log4j and I was so relieved to learn all our services are written in Go or PHP. Also noticed we were continously scanned for the vulnerability (random "jndi:ldap" in requests) from different IPs, some from China

  > ...relieved to learn all our services are written in ... PHP.
Testimony to just how bad this issue is!

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

#98

Post by mFixman »

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?

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

#99

Post by tomjen3 »

reaperducer wrote: post #65
mihaic wrote: post #47

I spent this weekend removing Elasticsearch usage in our project. Just earlier I saw that our API wasn't responding, and was wondering how the hell someone with log4j got to us. Turns our AWS West 2 was down. If it weren't for the fear of DDOS attacks, I'd put every webservice in a physical server in a basement somewhere and be done with it. I've been fighting this whole year to simplify and reduce the number of depe…

I'd put every webservice in a physical server in a basement somewhere and be done with it. One of the benefits of working in healthcare is that if it's not on-premesis, it's a non-starter for many organizations. My company's paranoia of cloud services has paid off several times in terms of security in the last few years, even if the cost in dollars was higher. At this very moment, a vendor is going through a ransomwa…

I hope no startups learn that lesson, but instead hone their products with quick turnaround from users and then when they have achieved marked fit then offer to sell their product to enterprise companies for a massive fee. And by package I mean they deliver some servers with Kubernetes on it and run the same software they run in the cloud.

If a startup tries to sell to the enterprise they are likely to die before they make enough in sales and enterprise concerns (such as on prem >> price) aren't usually shared with normal businesses.

Not saying you can't make a fortune selling overpriced products to large companies (hello Oracle) but it isn't a game for a start up.

Post reply on HN