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

CISA Director on Log4j Vulnerability

cisa.gov

Post reply on HN
Print view View original

41–50 of 85 posts

Re: CISA Director on Log4j Vulnerability

#41

Post by eitland »

nl wrote: post #35
eitland wrote: post #21

There's a lot of talk now about a number of things including web application firewalls and how we must fund open source and I hope something good comes out of it. However, the thing that I wonder is why we still are in a position where every single application and every single dependency can attempt to load dlls (ref npm hacks lately) or reach out to the network? Why is Deno the only one who seems to have a good solu…

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

> It's pretty rarely done though.

Exactly. That is why I like the Deno solution even as a long time Java user: it is on by default and so simple that there is no reason to disable it.

Re: CISA Director on Log4j Vulnerability

#42

Post by charcircuit »

Xylakant wrote: post #26
charcircuit wrote: post #23

Earlier quoted context omitted.

those don't run on the front end

It doesn’t matter. An nginx web server logging an odd user agent, elasticsearch picks it up. And then, due to some error triggered by the attacker, the content of the webserver log line gets logged on the ES side (for example if it violates a constraint). Frontend bypassed, attack owns ES. I’ve spent my weekend celebrating that I don’t have Java software in a stack that I’m responsible for right now - and feeling sor…

It does matter. To quote the original parent: "do I need to worry about this as a frontend web developer?"

A frontend web developer doesn't manage nginx, nor ES.

The backend should be patched. It is not safe to just mitigate the bug by using code in the frontend.

Re: CISA Director on Log4j Vulnerability

#43

Post by xwolfi »

asjfj9 wrote: post #27
ygjb wrote: 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.

Work in one of the largest financial org in the world as a Java dev for critical system (albeit not internet facing), learned of this just now on this thread...

Edit: upon checking, we're safe, it doesn't impact log4j1, only the second version. We're not cowboys using versions as young as 2012 lol.

Re: CISA Director on Log4j Vulnerability

#44

Post by phkahler »

mclarke wrote: post #2

I’m sure this is the only community that might pay attention to a software BOM as mentioned in the article, but this is a great idea and makes a lot of sense (to me as a consumer at least).

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.

Re: CISA Director on Log4j Vulnerability

#45

Post by naltun »

technion wrote: post #40
tex0 wrote: 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.

Sadly every WAF vendor is falling over themselves to claim otherwise. I've already had arguments with senior leadership suggesting there's no need to worry about patching because multiple vendors have promised their solutions are better. The further I get into security the more embarrassed I am for some of the offerings.

I work as a software engineer in cybersecurity.

> embarrassed... for some of the offerings

Welcome to the club.

Re: CISA Director on Log4j Vulnerability

#46

Post by xwolfi »

charcircuit wrote: post #42
Xylakant wrote: post #26

Earlier quoted context omitted.

It doesn’t matter. An nginx web server logging an odd user agent, elasticsearch picks it up. And then, due to some error triggered by the attacker, the content of the webserver log line gets logged on the ES side (for example if it violates a constraint). Frontend bypassed, attack owns ES. I’ve spent my weekend celebrating that I don’t have Java software in a stack that I’m responsible for right now - and feeling sor…

It does matter. To quote the original parent: "do I need to worry about this as a frontend web developer?" A frontend web developer doesn't manage nginx, nor ES. The backend should be patched. It is not safe to just mitigate the bug by using code in the frontend.

As a frontend dev shouldn't you worry about your clients, rather than the boundaries of your organisation ? Harass whomever is putting the log4j dependency in the backend until they patch, don't expect them to know by default.

Re: CISA Director on Log4j Vulnerability

#47

Post by beebeepka »

eitland wrote: post #32
beebeepka wrote: post #25

Earlier quoted context omitted.

I would like to use Deno but I am not in a position of power even if I was, it's not always easy to switch, especially with a full backlog. Anyway, how does Deno solve this?

I'll start with the question: Deno solves this by making you specify on the command line or in a config file what an application should have access to, for instance for a simple web application you can specify that it only has read acesss to one folder of static files, write access to the log folder and can only connect to the postgres server. It is also very simple, see: https://deno.land/manual@v1.16.4/getting_star…

Thanks for your time. I am about to start a new personal project and your post, combined with some curiosity, is all I needed to hear. I've reached a point where doing the same thing with the same tech is making me feel uneasy.

Re: CISA Director on Log4j Vulnerability

#48

Post by SCHiM »

naltun wrote: post #45
technion wrote: post #40

Earlier quoted context omitted.

Sadly every WAF vendor is falling over themselves to claim otherwise. I've already had arguments with senior leadership suggesting there's no need to worry about patching because multiple vendors have promised their solutions are better. The further I get into security the more embarrassed I am for some of the offerings.

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 time span of 2 years, you can probably walk away with pretty penny! If they do get hacked, just pretend you technically _did_ see the alert, but a junior employee on your side failed to act on it. Sack them, and then re-hire them later. They are the 'fall' person whose job is basically getting fired. Give your customer a discount and try to stay on for 2 more years!

Re: CISA Director on Log4j Vulnerability

#50

Post by imglorp »

phkahler wrote: post #44
mclarke wrote: post #2

I’m sure this is the only community that might pay attention to a software BOM as mentioned in the article, but this is a great idea and makes a lot of sense (to me as a consumer at least).

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 do you filter out false positives, or irrelevant ones? Do you dump everything with that dep or help the maintainer fix it? Many questions.

Post reply on HN