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

Third High Severity CVE in Log4j Is Published

logging.apache.org

Post reply on HN
Print view View original

291–300 of 335 posts

Re: Third High Severity CVE in Log4j Is Published

#291

Post by marcosdumay »

lazide wrote: post #235
marcosdumay wrote: post #230

Earlier quoted context omitted.

> Prior company had a shared plugin that let you turn up the logging for a given logger remotely for 30 minutes (it self reset). And you really believe this should be a feature of you logging library, and not of you configuration system?

How is your logging system going to get that new configuration without restarting if it doesn’t support dynamic reconfiguration?

Why is there any problem in restarting your logging system? There is nothing in a logging system that could be harmed by a restart. Restarting it is exactly how you should handle changes, because it deals with plenty of stuff that isn't reconfigurable on a lower level.

The only way to make a "reconfigurable" logging system is by having a stable facade that restarts everything behind it. But that extra layer does not belong on a logging system, there are plenty of other things you need to make "reconfigurable", and now you are adding an extra layer into each of them, instead of having only one on your main entry point.

Pushing that feature down into the logging system is the choice that maximizes complexity and minimizes functionality.

Re: Third High Severity CVE in Log4j Is Published

#292

Post by ashtonkem »

marcosdumay wrote: post #291
lazide wrote: post #235

Earlier quoted context omitted.

How is your logging system going to get that new configuration without restarting if it doesn’t support dynamic reconfiguration?

Why is there any problem in restarting your logging system? There is nothing in a logging system that could be harmed by a restart. Restarting it is exactly how you should handle changes, because it deals with plenty of stuff that isn't reconfigurable on a lower level. The only way to make a "reconfigurable" logging system is by having a stable facade that restarts everything behind it. But that extra layer does not…

You act as if “restarting” the logging system is easy and doesn’t require the same facade that you decry for a reconfigurable one. With dependency injection, there are loggers everywhere in the system, possibly in sections of the code you didn’t even rewrite. Restarting such a system while continuing to run everything else is just as complex as reconfiguring, possibly more complex.

Also, I noticed you didn’t answer my question about whether you’re a Java developer.

Re: Third High Severity CVE in Log4j Is Published

#293

Post by isbvhodnvemrwvn »

tekknik wrote: post #277
lazide wrote: post #235

Earlier quoted context omitted.

How is your logging system going to get that new configuration without restarting if it doesn’t support dynamic reconfiguration?

You log and collect everything, then use your log aggregator to filter the appropriate content.

This turns gigabytes per hour of logs to hundreds of terabytes per hour during normal operation, in many cases it's an inferior solution for problems which pop up in a fraction of infrastructure several times a month.

Re: Third High Severity CVE in Log4j Is Published

#294

Post by isbvhodnvemrwvn »

doikor wrote: post #50
cnorthwood wrote: post #47

Earlier quoted context omitted.

because Log4J is also used by libraries. Which means you can configure the log level and capture logs from libraries and dependencies you use in a global configuration.

You really shouldn't use log4j in libraries. Instead use slf4j in a library and log4j (or whatever implementation for the facade you prefer) in the application using the library.

Tell that to thousands of existing libraries.

Re: Third High Severity CVE in Log4j Is Published

#295

Post by Macha »

jiggawatts wrote: post #228
FridgeSeal wrote: post #191

Earlier quoted context omitted.

> The source code is not what is deployed. There is typically no link back from a deployed system to its source, even if you compiled the binary within your organisation. Do you not have this? Our docker images are tagged with the git hash they were built from, so at any point, for any of our envs, I can pull up the lock file of that build. Our deployment config also describes everything that is running the relevant…

This happened last week, for real with ${dayjob} customer. Put yourself in their shoes for a second. Imagine you are Mr SecOps guy, and you've just ran some sort of Log4j tool across literally three thousand servers . Of those, several hundred came back positive. Those included about a dozen flavours of Linux, a smattering of manually built(!) containers, and every version of Windows from 2008 R1 to 2022. Most of the…

> No, seriously, now what do you do? You're in SEC OPS. Not dev ops. You're certainly not in the dev team with access to the Git repo of some random vendor product like Tableau, or JIRA, or whatever[2]. You didn't deploy it. It got installed by a contractor during a short-term project three years ago.

Your company has an inventory of hosts to teams which you can look up and contact. In addition the package manager tracks which package the file belongs to. Therefore you raise a ticket with the team from the inventory tracker that package XYZ on host ABC contains vulnerable file /x/y/z/log4j-xyz.jar (The reverse is also true, for each package we can find the corresponding repo and set of hosts its deployed on). Fixing it is now that team's problem, and secs ops guy's problem is now just to verify when they claim to have fixed it.

If the software is JIRA? Doesn't matter, still needs a package built before it gets deployed on our machine. "No really, the vendor's only supported installation method is sudo curl | bash" - into a container it goes, the owning team of the container can be identified much the same way as the owning team of the host.

Now the problem you find is sometimes the result is that the host belongs to team XYZ and you find the team was reorged by some exec's great idea in 2019 and only one guy who used to be on the team is still in the company, but he left the team in 2018 and has no idea what that team did since he left, but the application has been still runnning and power $millions of real revenue. That one is much harder to fix by automation. The business reality is the security team can't enforce to the execs to not lay anyone off or disband any teams without a concrete transition plan for their systems.

Re: Third High Severity CVE in Log4j Is Published

#296

Post by staticassertion »

tekknik wrote: post #272
staticassertion wrote: post #130

Earlier quoted context omitted.

Honestly, absolutely not, and I think money would be harmful. Lots of software doesn't need a lot of work. It can be simple . When people get paid to solve problems there's an incentive to add more code, to add new domains, etc. Use the standard java logger and move on, it's that easy.

Where’s my incentive to work the weekend supporting a project after a long week of supporting my production code? If we want solid and secure OSS, we gotta pay someone!

Presumably it's the same incentive that pushed you to write it the first time.

If you don't want to work on it anymore that's OK too. Open source libraries are generally not held to particularly stringent requirements by the vast majority of people - perhaps accepting an obvious patch in a critical situation, at most.

You obviously can pay people. They're called employees. The thing about employees is that your money translates to business value, which is much broader than a single library. This means that when a single library is done the developer doesn't have to think "ok but what's next for this library" and start adding more code. They can stop and move on to other tasks.

Paying for a single library is nice. I support multiple open source developers because I appreciate their work. I recommend everyone does so.

I don't at all believe it's going to help security though.

Re: Third High Severity CVE in Log4j Is Published

#297

Post by cutemonster »

to11mtm wrote: post #206
twunde wrote: post #145

Earlier quoted context omitted.

Regarding your questions, they make sense in the context of modern software built in the last 5 years. However, most large enterprises have a long tail of legacy applications built years ago. These may be inherited from a combination of acquisitions, from vendors that have since gone under, some from. The common factor is that the original developers are long gone, and they may be supported using a skeleton crew or n…

Egress is a very fair question IMO. I've worked at more than one place where Infosec would start integration talks at 'What are the static IPs and how do we rotate certs' Every layer you go lower (longer certs, domain whitelisting vs static IPs, etc.) is a tradeoff of maintenance and security. > What these applications are supposed to connect to are likely unknown. This is a major problem at enterprises Only if they…

I suspect that a manager that suggested / insisted on such properly staffed teams, would get fired or no longer promoted, at most big companies. Since it'd cost a lot, and not show any results the nearest time / years. And also, they might hire the wrong people, and just burn money for nothing

> Simple, if brutal solution ... properly staffed teams

The recruitment part is not simple, maybe bordering to impossible? for some larger companies. I say, based on my past experiences in how clueless big companies can be concerning what technical people they hire.

Re: Third High Severity CVE in Log4j Is Published

#298

Post by marcosdumay »

ashtonkem wrote: post #292
marcosdumay wrote: post #291

Earlier quoted context omitted.

Why is there any problem in restarting your logging system? There is nothing in a logging system that could be harmed by a restart. Restarting it is exactly how you should handle changes, because it deals with plenty of stuff that isn't reconfigurable on a lower level. The only way to make a "reconfigurable" logging system is by having a stable facade that restarts everything behind it. But that extra layer does not…

You act as if “restarting” the logging system is easy and doesn’t require the same facade that you decry for a reconfigurable one. With dependency injection, there are loggers everywhere in the system, possibly in sections of the code you didn’t even rewrite. Restarting such a system while continuing to run everything else is just as complex as reconfiguring, possibly more complex. Also, I noticed you didn’t answer m…

> about whether you’re a Java developer

I was once, but haven't used it professionally for a while. It's on my "I'd rather not" list, but not strongly so.

Oh, and now that you described it with so many details, the attachment to complexity does look more like addiction than love.

Re: Third High Severity CVE in Log4j Is Published

#299

Post by spockz »

lazide wrote: post #232
spockz wrote: post #180

Earlier quoted context omitted.

Besides this, who actually scans the deployed binaries? Just check which version of the binary was deployed, backtrack to the source, and get the dependency tree from there. Problem solved. (Except for shaded dependencies…, but scanning for that should happen at build time anyway.)

Good luck doing that on the custom software some vendor provided you 5 years ago and since has gone out of business.. and that’s a GOOD scenario for a lot of enterprise software. Sometimes it’s 20 years.

Okay. Just like any other software that should be firewalled in to only connect to what it should connect to. Moreover, I think meta sploit already has this vulnerability built in so it should be trivial to test/fuzz the application.

Re: Third High Severity CVE in Log4j Is Published

#300

Post by themerone »

themerone wrote: post #111
akeck wrote: post #52

Earlier quoted context omitted.

I read a post recently that said part of the open source funding issue comes down to a financial "structure" mismatch. Open source folks are often individuals or loose collections of individuals. Sometimes they have things like Patreons, ask to receive crypto currencies, etc. Companies don't/can't provide funding via these types of structures, so the writer of the post ended up incorporating a company, setting up a m…

My Fortune 500 company has to pay a third party to pay for Google Maps, because we can't pay a supplier with a credit card. If we can't find a way to pay Google, there is no hope for some random developer in Nebraska.

Nebraska is a reference to https://xkcd.com/2347/
Post reply on HN