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

Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

techsolvency.com

Post reply on HN
Print view View original

201–209 of 209 posts

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#201

Post by raxxorrax »

bob1029 wrote: post #66

I have taken some flak over the years for rolling my own basics like logging, telemetry, tracing, authentication, session management, etc... Incidents like this remind me that it is sometimes OK to ignore those who constantly order you to "vendor it out" over some notion of principled development excellence wherein one never reinvents a single hypothetical wheel. Arguably, writing text to a log file on disk is a simp…

To be fair, log4j offers more than to write a file on the disk. Logging is also quite relevant for performance as these I/O operations are a bottleneck in many applications.

I think we cannot prevent bugs like this, but mitigation has to become easier.

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#202

Post by ineedasername »

unixbane wrote: post #168
ineedasername wrote: post #125

Earlier quoted context omitted.

>What if there are none? The problem is that "There are no bugs" approaches an unproveable statement as a codebase grows into even a modest size. It doesn't matter if you're a 10x developer or not, you aren't always going to immediately see all the implications and edge cases of a few hundred++ (at least) moving pieces the first time around with new code, and each additional piece adds a non-linear amount of complexi…

youre doing something incredibly wrong if there is a threat that your system can be taken over by logging. and java enterprise object store late bound remote naming system registry garbage non-solutions to non-problems are the thing that is being done incredibly wrong here. your opinion is literally just an admission that you misunderstand basic software engineering principles like pretty much all programmers edit: o…

You don't know what my world consists of, so I'm not sure where that comment comes from.

My comment was addressing the general sentiment from the GP regarding the potential presence of bugs in software, not the log4j issue in particular-- plenty if other have done that and I won't rehash it.

And of course your comment seems to ignitre the part of mine where I say that rolling your own version of something can be okay, but it's a decision to be made very carefully, along with my implication that trivial things are a different category. (your printf straw man would be about as trivial as it gets, so you're not making a string argument against my comment here)

And this is not just for issues of bugs, but also time and resources. Why spend your time writing a complex library for something that is not part of the core of your business if a well established OSS alternative that has had countless eyes reviewing the codebase, and it can do all you need? I don't go rewriting grep or other utilities. I don't roll my own equivalent of a nearly decade old library like python Requests. I use well established tools from trusted sources and then get down to my real work.

This is pretty much how most professions go about their jobs: use established tools, get to work. If there's a difference it's that many other engineering disciplines have had more than ~75 years to refine their established processes and basic tools.

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#203

Post by ineedasername »

mro_name wrote: post #134
ineedasername wrote: post #125

Earlier quoted context omitted.

>What if there are none? The problem is that "There are no bugs" approaches an unproveable statement as a codebase grows into even a modest size. It doesn't matter if you're a 10x developer or not, you aren't always going to immediately see all the implications and edge cases of a few hundred++ (at least) moving pieces the first time around with new code, and each additional piece adds a non-linear amount of complexi…

you're in responsibility land then. That's not where they buy IBM to avoid getting fired. You get paid not for being smart, but for just doing responsibility for standard engineering. Plain craft. And do it seriously, not for admiration but payment.

Ah, responsibility land. More freedom to do as you want, and more risk because you can make mistakes and then have to face the consequences. Though it also often means you get to work on things that are a bit more interesting as well.

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#204

Post by ineedasername »

mro_name wrote: post #116
hpoe wrote: post #70

Earlier quoted context omitted.

Given many of the engineers i have worked with and much more importantly the PMs and Managers that work over them, I would expect vulnerabilities like this to proliferate all over the place if people were to roll their own logging and telematry and especially authentication. I mean SQL injection is such an easy known mitigation yet is still on the OWASP top 10 even after so many years.

it's all about system boundaries. Would you have arbitrary racoons in your closet?

It seems like you're saying that I should let the racoons out of my closet. I'll consider it, but then getting my clothes every morning will be a lot less exciting.

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#205

Post by ineedasername »

My workplace uses a vendor potentially impacted by ransomware as the result of log4j. When asked, the vendor-- Kronos-- did not deny it as the issue [0], and we ourselves have not received any more substantive answer. Although they may not yet know the attack vector so I wouldn't read too much into it yet. However, regardless of the Kronos cause, I will not be surprised if the next year or so brings a strong uptick in ransomware.

(As a side note, this isn't a great time-- right before Christmas-- to have issues that could impact paying employees on time. Fortunately my workplace doesn't have many of our employees in in this system and Business Continuity can be achieved more easily by temporarily using plain old paper & manual processing than spending time on a temporary technical work around)

https://arstechnica.com/information-technology/2021/12/as-lo...

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#206

Post by foobiekr »

throwaway894345 wrote: post #197
foobiekr wrote: post #192

Earlier quoted context omitted.

You should do it on the network _anyway_. You want multiple layers because you often find that any given layer was not as robust as you assumed.

This doesn’t work. I often want my app to be able to talk over the network, but I want to restrict my logging library from making network calls. You can’t do this at layer 7 much less layer 3. But firewalls at those layers still obviously serve a purpose, just not this purpose.

Your app shouldn’t be talking to randos injected from the outside. This is trivial.

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#207

Post by royce »

Site author here. Thanks for helping to get the word out - every bit may help someone.

While I consider my page to provide useful color, and I validate and summarize and cache info updates locally to add value ... it won't scale for long. It's really a stopgap - to buy defenders time until better efforts emerge.

A few efforts likely to become higher leverage than mine, because they can be driven by pull requests:

* https://github.com/NCSC-NL/log4shell - already quite comprehensive

* Whatever CISA may spin up - https://github.com/cisagov/log4j-affected-db

* Kevin Beaumont (@GossiTheDog) - turns out he worked with CISA on this

That being said, I'll keep working on mine as long as it still provides value; updates/corrections welcome.

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#208

Post by throwaway894345 »

foobiekr wrote: post #206
throwaway894345 wrote: post #197

Earlier quoted context omitted.

This doesn’t work. I often want my app to be able to talk over the network, but I want to restrict my logging library from making network calls. You can’t do this at layer 7 much less layer 3. But firewalls at those layers still obviously serve a purpose, just not this purpose.

Your app shouldn’t be talking to randos injected from the outside. This is trivial.

"webhooks"

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#209

Post by foobiekr »

throwaway894345 wrote: post #208
foobiekr wrote: post #206

Earlier quoted context omitted.

Your app shouldn’t be talking to randos injected from the outside. This is trivial.

"webhooks"

Sorry, that's not a good answer. That server needs to be locked down, absolutely, in terms of __what kinds of requests it can originate__ and what is reasonable for that request to carry. Otherwise you can end up participating in a relay attack.
Post reply on HN