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

Apache Log4j vulnerability shows the importance of SBOMs of running apps

codenotary.com

Post reply on HN
Print view View original

51–58 of 58 posts

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

#51

Post by mrweasel »

mnd999 wrote: post #16

No, we’re not gonna buy your shitty SAAS just to parse some .pom files. If we’re feeling particularly lazy we might even just do mvn dependency:tree

If you’re me, doing operations for X number of clients, having a tool that would have allowed me to know which clients use which version of log4j would have saved me hours yesterday. I don’t know exactly what library random developer at each customer use, nor do I have access to their code. It would have been nice to be able to easily look up which few clients I need to call.

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

#52

Post by franga2000 »

samwillis wrote: post #5

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…

A big part of this is that outbound connections are constantly changing. I tried to firewall a web scraper a while ago that as part of its operation had to execute some untrusted JS. It sounded easy - it only ever connects to one site, so just let that pass through. But that site used shared hosting of some kind and their IP address would change on a surprisingly regular basis. The scraper didn't care at all since it used DNS, but firewalls can't do that.

The solution we ended up implementing was to run the scraper through a local HTTP proxy, block all other connections, then use the proxy's config to whitelist the site by the Host header. This, of course, meant doing SSL stripping on the proxy, which was only acceptable because the proxy was ours. If a hosting provider suggested something like this we'd laugh them away.

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

#53

Post by gundmc »

richardwhiuk wrote: post #44
gundmc wrote: post #34

Earlier quoted context omitted.

"SBOM" almost always refers to Service Bill of Materials in my experience. So not even the acronym would stand out in this usage.

Usually "Software Bill of Materials".

Yeah, popular usage seems to have shifted over recent years. I'm sure my experience is biased by my close work with discrete manufacturing.

Searching Google incognito does seem to validate your assertion.

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

#54

Post by ThePowerOfFuet »

jaywalk wrote: post #31
notreallyserio wrote: post #23

Earlier quoted context omitted.

Google offers a way to access Google services from your VM 1918 IPs so you don't need to use NAT. I wonder if Azure would consider doing the same.

If you do the blocking in Azure via a Network Security Group, it's simple. You can allow outbound traffic to Azure services and deny anything else.

Until an Azure service is misused for exfil.

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

#55

Post by Zababa »

onion2k wrote: post #12
mikro2nd wrote: 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…

It also shows that you have to care not only about the dependencies of your application, but also about the dependencies of applications that you use like Elasticsearch.

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

#56

Post by johnisgood »

simion314 wrote: post #30
cabernal wrote: post #11

Earlier quoted context omitted.

Even when the supply chain attacks are not related to the JS ecosystem, JS/NPM gets mocked - inaccurately even...

>Even when the supply chain attacks are not related to the JS ecosystem, JS/NPM gets mocked - inaccurately even... js/npm really desirves it, I lost many hours last week because the shitty philosophy of spiting things not in libraries but in mainly functions and add on top of that packages with incorrect package.json, packages that depend on git repositories or shit where package X is bugged on node version Y so you…

Exactly. People think it is modular and such a great thing to do, but it is not. Maybe it just has to do with flexing. How many libraries do you have? I have 9000! And then in reality it is just one function per library. Or... I have no idea why they think that this is a good thing to do. Can anyone in favor of having "isOdd" function as a library tell me?

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

#57

Post by dogma1138 »

mnd999 wrote: post #16

No, we’re not gonna buy your shitty SAAS just to parse some .pom files. If we’re feeling particularly lazy we might even just do mvn dependency:tree

You don’t need to buy anything just use CycloneDX and OWASP Dependency Track https://news.ycombinator.com/item?id=29542271

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

#58

Post by michaelbuckbee »

samwillis wrote: post #5

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…

For Heroku - Expedited WAF does filter (inbound) for log4j - but I'm not sure there's a good way to outbound, even with Private Spaces. You can start a dyno that only has access to the other apps in the space, but if log4j was on one of the connected web app servers you'd still be in trouble.

https://expeditedsecurity.com/heroku/how-to-block-log4j-vuln...

Post reply on HN