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

41–50 of 58 posts

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

#41

Post by infogulch »

notreallyserio wrote: post #23
diroussel wrote: post #13

Earlier quoted context omitted.

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…

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.

Not all services support it yet, but private endpoints are a great solution to this issue in azure.

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

#42

Post by samwillis »

formerly_proven wrote: post #28
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…

> 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? Not really, but it's important to keep in mind that these kinds of things are less effective than you might imagine. E.g. using the sys…

> How is this obvious?

By using a WAF you are explicitly blocking many standard hacking attempts such as SQLi. At least it seems obvious to me to take the precaution of having one, you can never trust that your code or the library’s you use don’t have security holes.

By using a hosted or managed WAF it means when there is a new venerability found (such as Log4Shel) the service updates the rules and you have a level of mitigation before even patching your system or even being aware of it.

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

#43

Post by hagbard_c »

I just had a look at Airsonic [1] since I'm both a user and a developer and happened upon a related question on Github. Not having access to any fancy-schmancy "SBOM SAAS tool (try it now for free!!1!) I just git-grepped the repo which gave me 2 hits. Looking at those I found they were caused by (Apache) commons-logging.jar containing stubs to interface with Log4j. Problem solved.

[1] https://github.com/airsonic-advanced/airsonic-advanced/issue...

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

#44

Post by richardwhiuk »

gundmc wrote: post #34
d23 wrote: post #32

This is essentially just an ad for their service, no? Why is this being upvoted? I'm surprised "SBOM" is actually an acronym people would recognize enough to upvote without reading the article.

"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".

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

#45

Post by mrweasel »

d23 wrote: post #32

This is essentially just an ad for their service, no? Why is this being upvoted? I'm surprised "SBOM" is actually an acronym people would recognize enough to upvote without reading the article.

If your doing software which will need to pass an FDA audit, having a “SBOM” is required, though most would use “SOUP”, software of unknown providence. In these cases I can see a service like this be very useful.

There’s a ton of stuff on HN which is just ads for SaaS companies, at least this is new and different. It’s might also be something many are interested in, in light of the Log4j exploit. It would have help me a great deal.

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

#46

Post by richardwhiuk »

samwillis wrote: post #42
formerly_proven wrote: post #28

Earlier quoted context omitted.

> 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? Not really, but it's important to keep in mind that these kinds of things are less effective than you might imagine. E.g. using the sys…

> How is this obvious? By using a WAF you are explicitly blocking many standard hacking attempts such as SQLi. At least it seems obvious to me to take the precaution of having one, you can never trust that your code or the library’s you use don’t have security holes. By using a hosted or managed WAF it means when there is a new venerability found (such as Log4Shel) the service updates the rules and you have a level o…

Most WAF attempts to block this failed - there's plenty of twitter posts doing things like ${${j}${n}i: to bypass WAF rules.

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

#47

Post by formerly_proven »

throw0101a wrote: post #35
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…

> 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? Black hole routing is often used in some more regulated industries (finance): * https://en.wikipedia.org/wiki/Black_hole_(networking) There's overhead in setting up proxies and telling all software to use them (browsers can be…

See also - software-defined perimeter. Sounds extremely bullshit, but boils down to "network is not used directly at all, everything runs over 'black channels' (e.g. use WireGuard) on a service-by-service * peer-to-peer basis". Tailscale is fairly close to this.

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

#48

Post by mrweasel »

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…

Many of us do, in fact many use private unrouted networks. Works great on something like EC2 as well.

The issue is that many have come to expect NAT or public IPs as default on their cloud infrastructure and firewalls would result in to many support cases.

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

#49

Post by hxtk »

samwillis wrote: post #27
tinus_hn wrote: post #22

Earlier quoted context omitted.

Because then you have to define what the package is going to do and it’s a lot of work. And now you don’t have to do that work. And of course, in this case it only takes one app using this library that has a legitimate use case for unlimited acces. Unless you find a way to limit libraries separately.

“it’s a lot of work” should never be a reason for not securing an system. It’s also invite to solve a problem so it’s not a lot of work. It should be easy to secure your systems from making outbound connection.

> “it’s a lot of work” should never be a reason for not securing an system.

It is, though. Software bugs are almost entirely optional: we could just formally verify every piece of software with a mathematical proof. Computer software would still be in the 70s or 80s because of how long that takes, but if security is the only goal of a system, that's what we need to be doing.

In practice, projects balance a multitude of concerns and, while important, cybersecurity is only one of them.

> It’s also invite to solve a problem so it’s not a lot of work. It should be easy to secure your systems from making outbound connection.

This, I agree with wholeheartedly. The way to improve security is to address the factors that put humans in situations where skipping important security steps makes sense.

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

#50

Post by mrweasel »

samwillis wrote: post #24
323 wrote: post #18

Earlier quoted context omitted.

> 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.

Exactly, there is a technical limitation (I understand why) of only blocking by IP not hostname, if the IP changes it breaks. Why has this not been solved in the last 50 years? You should be able to block by hostname, it’s how networks are defined. We are an industry of problem solvers but this one seems to have been ignored.

It is solved, Cisco and other firewalls have no issue blocking or allowing based on FQDN.
Post reply on HN