<https://cfml.slack.com/archives/C06TABBT8/p168935...
# adobe
s
I wonder how these numbers would look if weighted according to the number of sites powered by each tech? It would also be interesting to know how many vulns were actually exploited due to unpatched servers? We seem to hear a lot of people here still running old versions on old JVMs - but is that any worse than the average out there? I liked your analysis of Adobe's very conservative rating of vulns - "everything's a ten!"😁
z
Breakdown of non admin CVEs would also be interesting
t
I've been curious about this since reading these... Since cf runs on top of java and tomcat, does that inherently make every java and tomcat cve also one that affects coldfusion? So while not an issue with cf itself, if you're running python, or php, or .net, (as a more "standalone" platform) does that inherently lower the numbers? ie. .net is 10. Cf is 8 + 10 + 64 = 82...
a
@Tim yeah, pretty much. I just looked at the snyk report for a baseline CF2023 image (using Adobe's official image), and a PHP 8.2 one. CF2023: 27C 51H 28M 19L PHP: 0C 0H 0M 58L (Critical / High / Medium / Low) Obvs these are based on Docker images, so will include OS level issues as well as platform and language ones. However a vuln is still a vuln. One might contend "but Java vuln x is not exposed by CF". One can't think like that. PHP vuln y might not be exposed by my app either! InfoSec bods can't care (I mean: professionally they mustn't) whether or not something is immediately or obviously exploitable: what matters is a vuln has been identified, and we're running software that includes that vuln. Given CF2023 is fresh out of the gate, it's pretty bloody bad that the official Adobe image has so many vulns. ping @Mark Takata (Adobe) on that one.
😲 1
BTW, similar figures for Lucee: 5.4.1.8: 0C 4H 8M 24L 6.0.0.477-SNAPSHOT : 0C 5H 7M 50L This is a huge improvement from 5.4.0 and the previous build of 6, btw (which were about as bad as CF was). Great work from I guess @zackster and @justincarter there. Not sure who else contributes to maintaining the Lucee image
d
Just scanned our acf 2018u17 / acf 2023u1 command box docker images (slight tweaks from the base ortus versions but nothing to alter the CVE’s) with snyk and both came back with 0C 0H 5M 19L So looks like the base image Adobe uses is full of holes šŸ§€
s
I'd be very interested to know the differences in the Ortus vs Adobe images that could cause such a difference in vulnerabilities??
d
@jclausen may have a view on this, ortus have a few variations, alpine, ubuntu (I think) and red hat universal base image - my numbers were from the ā€œnormalā€ version which is the ubuntu one
They also update it fairly regularly which is the main difference I would guess
j
I’ve reported those scan results to Adobe multiple times and have tried to be a squeaky wheel about them. I know @Mark Takata (Adobe) has been trying to light a fire under the dev teams to get them resolved, with mixed results.
The base Ortus CommandBox images only have Low or Medium scan items now ( thanks to Lucee’s dilligence ), but the ones packaged with pre-warmed Adobe servers have all of their current library vulnerabilities, alas.
d
Oh and they - Jon and the gang - pay attention to this kind of stuff which a GREATLY appreciated
ā¤ļø 1
m
I can share that we are working on getting these resolved Jon. There's an update coming that updates a lot of them. I don't have a list yet, because we're trying to get as many out as possible. But your voice has been moving mountains, please keep it up Jon.
ā¤ļø 2
d
Interestingly the scan I did was on pre-warmed images (base command box 3.7.8) and I run warmup myself as part of the build - the snyk scan via the docker extension didn’t seem to notice the adobe cve’s in the image. Neither does AWS ECR, so not sure how deep they are scanning
j
That’s why I prefer
grype
to scan java - because it will recurse in to the jars and look at all of the manifests.
šŸ‘ 1
snyk
looks at the jar names so, if you rename your Jars to not have the version, you can spoof it.
( or at least that was the case 6 months ago )
d
sounds like a quick Adobe win would be to run ā€œyum updateā€ on their images at the very least šŸ™‚
As a slight aside @Mark Takata (Adobe) is there / will there be an ARM official Adobe image?
m
Doug, I have not seen whether that will be the case. Are you looking to run production workloads on a particular set of ARM architecture? I know that @paul got CF running on some of the AWS ARM chips a while back through his particular magic.
d
We run commandbox arm images for for dev (macs) and production AWS fargate using ACF already - just seems like an obvious omission in the official images.