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

Log4j: The pain just keeps going

thenewstack.io

Post reply on HN
Print view View original

261–270 of 291 posts

Re: Log4j: The pain just keeps going

#261

Post by vips7L »

hedora wrote: post #24
bgro wrote: post #16

When are they going to release Log5j? Or even Log4k to address these issues?

The log4j author already did this about a decade ago. No one could understand log4j back then, so the replacement is much, much simpler, and API compatible for 99+% of use cases. Few projects seem to have bothered moving to it, probably becuase log4j is such a collosal pain to set up or modify.

> Few projects seem to have bothered moving to it, probably becuase log4j is such a collosal pain to set up or modify.

Every new project I see defaults to slf4j/logback.

Re: Log4j: The pain just keeps going

#262

Post by krmboya »

SamuelAdams wrote: post #252
secabeen wrote: post #221

Earlier quoted context omitted.

So then what do you do with software that doesn't meet this standard? Software that works, that meets a need you have, but that is a fixed artifact, or at least will be in the foreseeable future. Do you refuse to use said software, and instead choose a less useful alternative that is actively developed?

We see this all the time in healthcare. MRI imaging machine that cost 500k 20 years ago still works fine but only on Windows XP. Cost to rewrite the software for windows 10 is more than 500k so rather than paying for that instead they firewall the shit out of it so it can only talk to some printing / output device. That’s just one example. Medical machines are expensive as hell and companies don’t want to rebuy or co…

Not familiar with such kind of software, but if it were written for, say, Linux, would it need such an expensive rewrite to work with current versions?

Re: Log4j: The pain just keeps going

#263

Post by freeqaz »

aahortwwy wrote: post #260
SomeCallMeTim wrote: post #117

Earlier quoted context omitted.

>"Use a build tool to do dependency checks!" > >And then what? > >"Only update libraries if they have vulnerabilities." > >So, should this be a manual process where I have to dig through obscure warnings every time I build something? > >"No, you can automate it!" > > Congrats, you've just outsourced the decision making process about which versions of libraries to use to some 3d party. You've also made your build proc…

> If I don't think the change is worth it or the vulnerability is relevant, I can go to the Snyk site and mark a vulnerability to be ignored, or even tell it to ignore it for a month or whatever. I am currently fighting with our security team because they refuse to allow developers to do this, and instead require my team to file tickets with their team, wait hours for that ticket to be picked up, explain why a thing…

This is compliance vs security. Finding vulns checks a box for SOC2, but in reality detection is the easy part. Figuring out what to fix, based on real-world usage and risk, requires much more work and is often ignored.

I'm sorry you're on the receiving end of this problem!

Shill notice: I'm working on an Open Source tool[0] that makes this problem less horrible. My colleague wrote a post about our hypothesis[1] about how we can avoid this false positive trap.

I'd love to chat with anybody feeling this pain (even just as therapy lol).

0: https://github.com/lunasec-io/lunasec

1: https://www.lunasec.io/docs/blog/the-issue-with-vuln-scanner...

Re: Log4j: The pain just keeps going

#264

Post by freeqaz »

horsawlarway wrote: post #78
tekchip wrote: post #33

Earlier quoted context omitted.

So somehow false positives negate all the actual positives caught and corrected? The only true solution is what? Manual audit of everything by some perfect human security practitioner? I suppose the same applies to automated development tools then. I will concede there probably are some firms out there acting poorly that way. When aren't there? Humans sigh . But by in large automation and the problems inherent are re…

I was in this industry for a while (I did 5 years full time for a security company). > I will concede there probably are some firms out there acting poorly that way. This is a hilarious take. Here's mine: The vast majority of these firms are here for liability. They do not provide security, they provide security theater so that if/when something goes wrong, the client can claim to have followed best practices, and th…

This post is amazing. Thank you. This captures my thoughts on this problem space very well!

Security vs compliance is real. I love how you just map "compliance = security theater" because that is really the best way to describe it. The TSA bit has me in tears!

Re: Log4j: The pain just keeps going

#265

Post by shepherdjerred »

philosopher1234 wrote: post #132
shepherdjerred wrote: post #128

Earlier quoted context omitted.

> So the exact software you compile will depend on whether or not you can connect to a 3d party service? Do you understand the actual implications of this? This is already true with the vast majority of software using any an online software repository, e.g. Go, NodeJS, Java, Rust, etc.

Not Go

Can you give me an example of a popular Go project that doesn't have any dependency on GitHub?

Re: Log4j: The pain just keeps going

#266

Post by shepherdjerred »

laughingbovine wrote: post #148
shepherdjerred wrote: post #128

Earlier quoted context omitted.

> So the exact software you compile will depend on whether or not you can connect to a 3d party service? Do you understand the actual implications of this? This is already true with the vast majority of software using any an online software repository, e.g. Go, NodeJS, Java, Rust, etc.

Yeah but you can cache the packages or store them in some fashion. I've seen JAR files in git repos far too many times... With security, you need some online service so you can find the new CVEs every day.

Oh I completely agree. I was referring to the parent saying that a third party is dictating what to build -- for security this is inevitable. For dependencies this can be solved by caching your .jars or whatever, but at some point you still always have a third party dictating what you're building.

Re: Log4j: The pain just keeps going

#267

Post by ithkuil »

krmboya wrote: post #262
SamuelAdams wrote: post #252

Earlier quoted context omitted.

We see this all the time in healthcare. MRI imaging machine that cost 500k 20 years ago still works fine but only on Windows XP. Cost to rewrite the software for windows 10 is more than 500k so rather than paying for that instead they firewall the shit out of it so it can only talk to some printing / output device. That’s just one example. Medical machines are expensive as hell and companies don’t want to rebuy or co…

Not familiar with such kind of software, but if it were written for, say, Linux, would it need such an expensive rewrite to work with current versions?

I still run software I wrote for Linux in 1998. It runs in a LXC container with all the old libraries and it must run in an Xvnc session with a window manager of the era because there is a Qt1 widget that opens a kind of drop down menu that just doesn't work with any modern window managers.

I probably wouldn't bother to try to port it to modern versions of Qt or whatnot even if I hadn't lost the source code 15y ago.

So yes, it happens, it's possible, it sucks

Re: Log4j: The pain just keeps going

#268

Post by skybrian »

kllrnohj wrote: post #155
jewel wrote: post #20

Earlier quoted context omitted.

That's fantastic. Since Go has gone all-in on static compiling, it'd be awesome if they made it possible to update a dependency without recompiling (or even having the source code for) the rest of the program. In addition to making it easier to do security updates in situations like log4j, it'd also make it easy to comply with LGPL license terms.

That doesn't seem possible. The benefits of static linking are that unused methods, symbols, etc... can be stripped as well as cross-library optimizations like in-lining. There's not necessarily going to be library lines left at all, at least not in any way that looks anything like upstream. And it's also going to vary from binary to binary, depending on what exactly they used from the dependency. What you're describ…

Instead of "update without compiling", maybe it would be better to attach an archive of the source to the binary, so you can update by compiling? Or maybe attach some suitable intermediate format?

Re: Log4j: The pain just keeps going

#269

Post by Nursie »

d4mi3n wrote: post #28
Nursie wrote: post #23

Earlier quoted context omitted.

Been in similar situations, it is not fun. "You have a vulnerable version of netty" "No, we don't, that's a false positive" "No see, the tool says you need netty 4.x and that's version 1.x, you need to update" "OK, but the tool is wrong, it's just picking up anything with 'netty' in the name, and that component is a wrapper around netty for some other thing, it only goes up to 1.8" "You have to update it to 4.x, this…

Security engineer here. This is sadly common. The grim fact seems to be that we have a dearth of information security analysts with engineering experience. If they don't have "Engineer" or similar in their title, odds are they haven't had the pleasure of building or maintaining a non-trivial unit of software over more than a quarter or so. That said, I've seen the inverse problem: engineering staff that either don't…

> Trust can be built between engineering and infosec teams

Yes it can, and I have worked with 'good' infosec people who were all about improving practices together. That attitude goes a long way - developers (well, the good ones) want to ship secure stuff and want to fold in best practices.

But the profession is unfortunately rife with people who don't know as much as they think they do, and who wade in heavy-handed, laying down the law to developers who might have been round the block once or twice themselves...

I wonder if it wouldn't be better to have a hybrid role that is part of engineering but has specific responsibility in this area, rather than as is often the case, an external party (or a separate team) which is perceived as adversarial.

Re: Log4j: The pain just keeps going

#270

Post by Nursie »

mbreese wrote: post #51
Nursie wrote: post #23

Earlier quoted context omitted.

Been in similar situations, it is not fun. "You have a vulnerable version of netty" "No, we don't, that's a false positive" "No see, the tool says you need netty 4.x and that's version 1.x, you need to update" "OK, but the tool is wrong, it's just picking up anything with 'netty' in the name, and that component is a wrapper around netty for some other thing, it only goes up to 1.8" "You have to update it to 4.x, this…

It sounds like some of this should be automated. If all the infosec person is doing is running a tool against a repo and reporting results, that should be automated. When there are false positives, that should be annotated in the repo with multiple people checking off on it. I’ve been impressed by automated bug checking tools in the past and I see this as part of the same issue. I don’t see why this would need an FTE…

In this case they weren't even running the tool, just looking over reports generated by the dev team.
Post reply on HN