Live data from Hacker News

Apache Log4j vulnerability shows the importance of SBOMs of running apps

codenotary.com

11–20 of 58 posts

Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps

#12
post #2

"Oh, just run `node install` and you'll be fine..."

If anything, the log4j problem goes a long way to highlight that the "package hell" of node_modules isn't limited to JS apps. log4j is a problem that affects compiled apps written in a mature language. All of the usual complaints about JS apps apply (lots of dependencies, code that's not been audited, developers just adding things without proper consideration, etc), but without the usual "lol javascript isn't a real language!" undertone.

Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps

#13

Since Log4Shell I have asked this question a few times and never really had a solid answer. Why are we not all using some sort of outbound firewall for our apps? Is there something fundamental (other than the administration of it) that stops it being the standard, or even possible? With everyone using un-curated package managers such as NPM and PiPy there is also the chance of a package being compromised. At least if…

I was on a team that tried to implement this at a bank, using azure. The idea was not at the app level but at machine (vm) level.

Machines in the legacy data center didn’t have internet access, and so they didn’t want could machines to have it either.

But once we locked down the network so many things broke. Not just user level stuff like doing code builds in maven, but also machine level stuff like enabling drive encryption.

Preventing out of band exfiltration on of data and downloading of exploit materials is very important to a defence in depth approach and none of the clouds seem to embrace it.

The problem was that all azure services were provided on public IP ranges, so given them at VM services needed to communicate with azure Ana gent endpoints we couldn’t block on the IP, so had to implement via HTTP proxies.

Using explicit HTTP proxies was a config night mare as not everything honoured the HTTPS_PROXY env var (e.g. Java). And using an implicit proxy was a nightmare of MITM, custom certs, updating a myriad of trust roots and then the proxy would use a ‘captive portal’ and cause broken redirects.

Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps

#14
post #10

Since Log4Shell I have asked this question a few times and never really had a solid answer. Why are we not all using some sort of outbound firewall for our apps? Is there something fundamental (other than the administration of it) that stops it being the standard, or even possible? With everyone using un-curated package managers such as NPM and PiPy there is also the chance of a package being compromised. At least if…

Windows has an enabled by default outbound firewall. The problem is that most apps want to connect to the net these days (check for updates, telemetry, ....) so when an app is installed it adds a firewall exception.

Sure, on desktop.

But for a server app (which you built and manage) where you are only talking to known endpoints everything else should be blocked, but we don’t do it. We all use platforms for our apps where anything we use could be compromised and connect to the outside world!

Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps

#15
post #2

"Oh, just run `node install` and you'll be fine..."

Actually me who's running a stack of services on Node.JS written in TypeScript had a wonderful weekend. I had my birthday on Sunday and took my girls to Christmas fare. So did my colleagues. The other half of the company were busy resolving the incident ;-)

Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps

#17

Since Log4Shell I have asked this question a few times and never really had a solid answer. Why are we not all using some sort of outbound firewall for our apps? Is there something fundamental (other than the administration of it) that stops it being the standard, or even possible? With everyone using un-curated package managers such as NPM and PiPy there is also the chance of a package being compromised. At least if…

I was on a team that tried to implement this at a bank, using azure. The idea was not at the app level but at machine (vm) level. Machines in the legacy data center didn’t have internet access, and so they didn’t want could machines to have it either. But once we locked down the network so many things broke. Not just user level stuff like doing code builds in maven, but also machine level stuff like enabling drive en…

Exactly! There has got to be a billion dollar company in this if the UX for administering it was done right so it wasn’t a pain.

Little Snitch as an example of UX in this area is perfect as you can run it for a while first to see what is connecting to what, then start looking down everything else.

Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps

#18
post #10

Earlier quoted context omitted.

Windows has an enabled by default outbound firewall. The problem is that most apps want to connect to the net these days (check for updates, telemetry, ....) so when an app is installed it adds a firewall exception.

Sure, on desktop. But for a server app (which you built and manage) where you are only talking to known endpoints everything else should be blocked, but we don’t do it. We all use platforms for our apps where anything we use could be compromised and connect to the outside world!

> where you are only talking to known endpoint everything else should be blocked

I just realized that neither the Windows Firewall, nor the Linux one (ufw/iptables at least) allow you to block based on domain names. They only allow IP address rules.

Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps

#19
post #12
post #2

"Oh, just run `node install` and you'll be fine..."

If anything, the log4j problem goes a long way to highlight that the "package hell" of node_modules isn't limited to JS apps. log4j is a problem that affects compiled apps written in a mature language. All of the usual complaints about JS apps apply (lots of dependencies, code that's not been audited, developers just adding things without proper consideration, etc), but without the usual "lol javascript isn't a real…

Fully agree! The point I was trying for is that dependencies have to be managed -- something I've been blathering into the void for a decade, now, without any noticeable impact. Maybe now I'll get those juicy consulting gigs... ;)
Post reply on HN