Live data from Hacker News

CISA Director on Log4j Vulnerability

cisa.gov

61–70 of 85 posts

Re: CISA Director on Log4j Vulnerability

#61
post #16
post #14

Someone should tell them that any system that it logging user supplied data can be affected. Not only "user facing" systems. Not even a WAF can protect these.

If the WAF blocks any request containing "{", that would be fairly safe, right? Yes, some attacks could still get through (e.g. a backend that receives requests base64-encoded), but that's the case generally with WAFs I think.

The devil is in the details. As a random example, you might have a process where all the pre-WAF requests (or explicitly the requests blocked by WAF) get forwarded to a log analysis system that itself uses log4j and is vulnerable, allowing the attacker to gain RCE in your monitoring infrastructure.

Also, blocking any request containing "{" is tricky - like, that's so generic that it's time-consuming to verify that it won't break anything, and it's very likely that JSON is used somewhere in that application traffic, so you can't simply do that.

Re: CISA Director on Log4j Vulnerability

#62
post #48
post #45

Earlier quoted context omitted.

I work as a software engineer in cybersecurity. > embarrassed... for some of the offerings Welcome to the club.

I am half convinced you can build a successful cyber security business putting a box in a network that does absolutely nothing. I think there's a requirement to at least show a blinking led and have a, not necessarily patched, cable plugged in. But that's about it. My thinking is, that if you show a cool enough interface (not connected to the box), with lots of widgets and stats, and they don't detect a hack in the t…

This reminds me a lot of audiophile woo as well. It seems like this sort of grift could be applied to just about anything where the technology is indistinguishable from magic.

Re: CISA Director on Log4j Vulnerability

#63
post #48
post #45

Earlier quoted context omitted.

I work as a software engineer in cybersecurity. > embarrassed... for some of the offerings Welcome to the club.

I am half convinced you can build a successful cyber security business putting a box in a network that does absolutely nothing. I think there's a requirement to at least show a blinking led and have a, not necessarily patched, cable plugged in. But that's about it. My thinking is, that if you show a cool enough interface (not connected to the box), with lots of widgets and stats, and they don't detect a hack in the t…

I'm sure you would make money, though the law might catch up with you eventually. A similar tale:

https://www.bbc.com/news/uk-29459896

Re: CISA Director on Log4j Vulnerability

#64
post #48

Earlier quoted context omitted.

I am half convinced you can build a successful cyber security business putting a box in a network that does absolutely nothing. I think there's a requirement to at least show a blinking led and have a, not necessarily patched, cable plugged in. But that's about it. My thinking is, that if you show a cool enough interface (not connected to the box), with lots of widgets and stats, and they don't detect a hack in the t…

This reminds me a lot of audiophile woo as well. It seems like this sort of grift could be applied to just about anything where the technology is indistinguishable from magic.

Got any examples of audiophile scams?

Re: CISA Director on Log4j Vulnerability

#65

Earlier quoted context omitted.

This reminds me a lot of audiophile woo as well. It seems like this sort of grift could be applied to just about anything where the technology is indistinguishable from magic.

Got any examples of audiophile scams?

This comes to mind

http://audiophile.rocks/index.html

Re: CISA Director on Log4j Vulnerability

#66
post #5

Unless they spell out how they proactively support the one man hobbyist maintainer I don't believe them. https://xkcd.com/2347

I wholehearted agree that we, as an industry, need to sort out the issue of open source maintenance compensation, but out of all the projects that we could pick to make a stand, I can't think of a worse example. There's no need to support these hobbyists in particular, it's a logging library for Java that had no reason to be written, that fulfills no need, that no one forced them to write and makes the entire ecosystem worse by piggying back on the "log4j" fame. By the time log4j2 was released, slf4j + logback was already the spiritual successor to log4j 1, superior in all aspects, and maintained by someone who actually knows what they are doing.

log4j2 has no reason for existing, other than the hubris of their own authors, who, as the entire world just found out, are not qualified to write a logging library. sl4fj + logback is the saner (3rd party) logging interface. More logging interfaces make it harder for every JVM developer who need to keep track of them all, perform exclusions in their build system and then explicitly include an SLF4J bridge for whatever "logging interface du jour" the author of some other library that you actually want to use picked. So you can't really say the log4j2 authors are doing it "out of the goodness of their own heart", they're injecting unwanted garbage onto my dependencies because someone who wrote an actually useful library just wanted logging to work and bumped a log4j1 dependency to log4j2, usually because they're focused on writing a useful library that people want to use and are unaware logging in Java is a shitshow (can't blame them). Would you say that we should also be thankful of malware developers who are doing it for free?

The log4j2 team can whine about how they're being unfairly attacked when they're doing unpaid work, but the fact is that they wrote software that had no business existing and actively makes the life of everyone WORSE by simply existing. If they don't like it, they can do the honorable thing, put the project on security maintenance mode and and redirect everyone to slf4j + logback.

Re: CISA Director on Log4j Vulnerability

#67
post #35

Earlier quoted context omitted.

The JVM running with a security policy can do this. It's pretty rarely done though.

The idea of having different declarative security realms is fine but it's not what the Java Security Manager is. The Java Security Manager is an API that allows to intercept and run codes, so devs use it as a Trojan Horse to patch code instead of fixing the root of the issue. The Java Security Manager should die.

Good news, it is going to die.

https://openjdk.java.net/jeps/411

Re: CISA Director on Log4j Vulnerability

#68
post #50

Earlier quoted context omitted.

In the production of electronic things I've been pointing out that software needs to be on the BOM for other reasons. It is so often overlooked and considered zero cost even though companies pay people to develop it. Making people look at a BOM would also discourage the mess that is npm.

Most systems use package management now; npm is only the poster child. Reviewing a stack of BOMs is going to be a challenge for any organization. Say your production Linux has 1000 packages. Each of those might have hundreds or thousands of deps in varying versions, in their respective package managers (BOMs). Business needs to step up its process game. How are BOMS (dep lists) reviewed? Do we expect zero CVEs? How d…

One outcome of reviewing a BOM will be people asking "why do we have 5000 little dependencies? I thought we were paying YOU to write software."

Re: CISA Director on Log4j Vulnerability

#70
post #27
post #17

Earlier quoted context omitted.

No. The stakeholders are busy patching their shit. Pulling folks into meetings shouldn't be the priority when teams around the world in virtually every tech organizations are in firefighting mode. This type of a call would likely be focused on assessing current state at that point.

Could you share links to any threads or accounts people are sharing regarding tech organisations in firefighting mode against this? I work for a large non-US based tech company and have not heard anything about this beyond HN.

There are many: https://www.techsolvency.com/story-so-far/cve-2021-44228-log...
Post reply on HN