syft
syft copied to clipboard
anchore
Hint information for non OS packages
What would you like to be added:
I want Hint information for non OS packages.
namespace in purl, or something.
I have no goog idea.
Maintainer in deb. Vendor Repository, From repo in rpm may be datasouce.
Maybe, hardcoding for each product is required.
Why is this needed:
Following tools will be able to check CVE and EOL without individual own implementation.
If namespace in purl is not OS vendor, scanner can judge this will be non OS package.
For example, scan for nginx upstream packages will be improved. And, nginx docker official image use upstream package.
Additional context:
In this time, let me focus CVE-2021-23017
In upstream ...
-
CVE-2021-23017was fixed at1.20.1and1.21.. https://nginx.org/en/CHANGES-1.20 https://nginx.org/en/CHANGES-1.22 -
Vulnerable: 0.6.18-1.20.0is written in official information nginx security advisories - NVD shows
From (including) 0.6.18 - Up to (excluding) 1.20.1NVD - CVE-2021-23017
In debian package ...
-
CVE-2021-23017was fixed at1.14.2-2+deb10u4,1.14.2-2+deb10u5,1.18.0-6.1+deb11u3,1.22.1-6and1.22.1-7in each release series. CVE-2021-23017
I prepared some images.
- debian 10 (buster) + 1.14.2-2+deb10u3 (OS apackage)
- debian 10 (buster) + 1.14.2-2+deb10u5 (OS ackage)
- debian 10 (buster) + 1.20.0-1 (upstream official package)
- debian 10 (buster) + 1.20.1-1 (upstream official package)
debian 10 (buster) + 1.14.2-2+deb10u3 (OS apackage) no problem
$ syft -q ghcr.io/witchcraze/debian10_nginx1.14.2-2deb10u3_os | grep 'nginx '
nginx 1.14.2-2+deb10u3 deb
$ grype -q ghcr.io/witchcraze/debian10_nginx1.14.2-2deb10u3_os | grep 'nginx ' | grep 'CVE-2021-23017'
nginx 1.14.2-2+deb10u3 1.14.2-2+deb10u4 deb CVE-2021-23017 High
debian 10 (buster) + 1.14.2-2+deb10u5 (OS ackage) no problem
$ syft -q ghcr.io/witchcraze/debian10_nginx1.14.2-2deb10u5_os | grep 'nginx '
nginx 1.14.2-2+deb10u5 deb
$ grype -q ghcr.io/witchcraze/debian10_nginx1.14.2-2deb10u5_os | grep 'nginx ' | grep 'CVE-2021-23017'
$
debian 10 (buster) + 1.20.0-1 (upstream official package)
CVE-2021-23017 should be detected ...
If grype can judge this is non OS package, and use NVD data, CVE-2021-23017 will be detected.
$ syft -q ghcr.io/witchcraze/debian10_nginx1.20.0-1_upstream | grep 'nginx '
nginx 1.20.0-1~buster deb
$ grype -q ghcr.io/witchcraze/debian10_nginx1.20.0-1_upstream | grep 'nginx ' | grep 'CVE-2021-23017'
$
Check package information
debian10 + OS package
# apt info nginx
Package: nginx
Version: 1.14.2-2+deb10u5
Priority: optional
Section: httpd
Maintainer: Debian Nginx Maintainers <[email protected]>
Installed-Size: 100 kB
Depends: nginx-full (<< 1.14.2-2+deb10u5.1~) | nginx-light (<< 1.14.2-2+deb10u5.1~) | nginx-extras (<< 1.14.2-2+deb10u5.1~), nginx-full (>= 1.14.2-2+deb10u5) | nginx-light (>= 1.14.2-2+deb10u5) | nginx-extras (>= 1.14.2-2+deb10u5)
Homepage: https://nginx.net
Download-Size: 88.9 kB
APT-Sources: http://deb.debian.org/debian-security buster/updates/main amd64 Packages
Description: small, powerful, scalable web/proxy server
debian11 + OS package
# apt info nginx
Package: nginx
Version: 1.18.0-6.1+deb11u3
Priority: optional
Section: httpd
Maintainer: Debian Nginx Maintainers <[email protected]>
Installed-Size: 104 kB
Depends: nginx-core (<< 1.18.0-6.1+deb11u3.1~) | nginx-full (<< 1.18.0-6.1+deb11u3.1~) | nginx-light (<< 1.18.0-6.1+deb11u3.1~) | nginx-extras (<< 1.18.0-6.1+deb11u3.1~), nginx-core (>= 1.18.0-6.1+deb11u3) | nginx-full (>= 1.18.0-6.1+deb11u3) | nginx-light (>= 1.18.0-6.1+deb11u3) | nginx-extras (>= 1.18.0-6.1+deb11u3)
Homepage: https://nginx.net
Tag: implemented-in::c, interface::daemon, network::server, network::service,
protocol::http, role::program, use::proxying
Download-Size: 92.9 kB
APT-Sources: http://deb.debian.org/debian bullseye/main amd64 Packages
Description: small, powerful, scalable web/proxy server
Debian 10 + upstream package
# apt info nginx
Package: nginx
Version: 1.22.0-1~buster
Priority: optional
Section: httpd
Maintainer: NGINX Packaging <[email protected]>
Installed-Size: 3112 kB
Provides: httpd, nginx, nginx-r1.22.0
Depends: libc6 (>= 2.28), libpcre2-8-0 (>= 10.32), libssl1.1 (>= 1.1.1), zlib1g (>= 1:1.1.4), lsb-base (>= 3.0-6), adduser
Conflicts: nginx-common, nginx-core
Replaces: nginx-common, nginx-core
Homepage: https://nginx.org
Download-Size: 889 kB
APT-Sources: http://nginx.org/packages/debian buster/nginx amd64 Packages
Description: high performance web server
nginx [engine x] is an HTTP and reverse proxy server, as well as
a mail proxy server.
Rocky9 + OS Package
# yum info nginx
Last metadata expiration check: 0:03:35 ago on Thu Feb 23 09:02:02 2023.
Installed Packages
Name : nginx
Epoch : 1
Version : 1.20.1
Release : 13.el9
Architecture : x86_64
Size : 147 k
Source : nginx-1.20.1-13.el9.src.rpm
Repository : @System
From repo : appstream
Summary : A high performance web server and reverse proxy server
URL : https://nginx.org
License : BSD
Description : Nginx is a web server and a reverse proxy server for HTTP, SMTP, POP3 and
: IMAP protocols, with a strong focus on high concurrency, performance and low
: memory usage.
# rpm -qi nginx
Name : nginx
Epoch : 1
Version : 1.20.1
Release : 13.el9
Architecture: x86_64
Install Date: Thu Feb 23 09:03:54 2023
Group : Unspecified
Size : 150733
License : BSD
Signature : RSA/SHA256, Mon Oct 31 15:41:42 2022, Key ID 702d426d350d275d
Source RPM : nginx-1.20.1-13.el9.src.rpm
Build Date : Mon Oct 31 15:37:14 2022
Build Host : pb-f577e986-58a5-477f-8f44-92b933793d0b-b-x86-64
Packager : Rocky Linux Build System (Peridot) <[email protected]>
Vendor : Rocky Enterprise Software Foundation
URL : https://nginx.org
Summary : A high performance web server and reverse proxy server
Description :
Nginx is a web server and a reverse proxy server for HTTP, SMTP, POP3 and
IMAP protocols, with a strong focus on high concurrency, performance and low
memory usage.
Trying to see if I got it correctly: given a package database for OS packages you'd like Syft to determine or infer the provenance of each package.
This in turn can help direct the vulnerability query to e.g., DSA or straight to NVD or upstream security feeds.
I'm weighing in on the general problem, not with Syft-specific ideas. Hardcoding should certainly be avoided but not totally out of the realm of possibility especially if it goes hand in hand with binary classifiers and knowing there are packages where this pattern is more prevalent (thinking of runtimes such as Node.js or dotnet) Another space to keep in mind is the use of PPAs in container builds. Fortunately it should be a researchable problem by looking at manual repository installations in Dockerfiles on GitHub for example.
My first consideration would be to use version strings. If the version string is known in a given distro release, or it fits a particular pattern, you can assume it's part of the distro. If not, it's part of upstream. This reduces the problem to a fallback case in the vulnerability lookup phase. You search for 1.20.0-1~buster in DSA. Not there? Assume it's upstream so search in NVD. This effectively duplicates queries for packages with no active vulnerabilities so I can see the downsides.
Unfortunately in APT-based systems I don't see an easy way to use Maintainer or APT-Sources. Through static analysis of originating Dockerfiles it might be possible to get a better approximation.
For RPM-based systems the situation might be better. Possibly package signatures could help.
Thank you for your confirmation.
Trying to see if I got it correctly: given a package database for OS packages you'd like Syft to determine or infer the provenance of each package.
Yes. It's the very thing i am expecting.
Honestly, current my approach in our work is gatherng data from package repogitries, and matcihng. // Our targets limited distribusions and products,
Hi @witchcraze, thanks for the suggestions and detail here. This is definitely something we want to solve, and we've chatted briefly about some of the possible solutions. One possible solution would be to include an hand-written SBOM with location information that would not overlap the Debian package location. (Packages with files that match a distro package like a .deb lose precedence and are filtered out by Grype.)
We'll keep this issue open and continue to think about this idea. Feel free to keep commenting here if you have more ideas.
Thank you for your comment.
I do not know detail, but that sounds good idea.
I agree filtered out first, and It has possibility to providing proper scan for major third party packacges in future, I feel.
For example, Remi's RPM repository provides backport patch even if it's EOL version. https://rpms.remirepo.net/enterprise/7/php56/x86_64/repoview/php.html I think using NVD data will be better now, but If grype (or other scnaner) supports update history of these products, scnan result will be improved more.
Some epel packages will be siimlar situation. For example, epel nginx 1.20.1-10 backported CVE-2022-41741 and CVE-2022-41742 which are fixed 1.23.2, 1.22.1 by upstream. https://rpmfind.net/linux/RPM/epel/7/x86_64/Packages/n/nginx-1.20.1-10.el7.x86_64.html http://nginx.org/en/security_advisories.html
Ubuntu ppa will be ... Sorry I do not know detail of ppa world. But from this comment, it seems impossible. https://github.com/future-architect/vuls/issues/1620
And recentry I noticed postgres deb packages in Docker official image are provided from debian team, but those are not OS standard. Most package meta data is siilar than OS package. In my understanding, using NVD data will be proper, and EOL will follow upstream EOL like non os package.
If we understand this problem properly, it looks like this particular issue is due to nginx having a different source:
APT-Sources: http://nginx.org/packages/debian buster/nginx amd64 Packages
We aren't capturing this information today and weren't sure that it was possible, but it looks like if apt info can provide this and we are able to capture it in Syft, we can then also update Grype to look to see if we have a known debian source and if so continue using the debian vuln data, but if not fall back to NVD or some other matching source.
Does this sound like it would help to solve the issue reported here?
Thank you for your understanding for first topic. Yes. I think so too.
If APT-Sources is not debian, refference vulnerability dataset will not be debian's oval, but NVD.
And I think similar situation happens in alpine's image.
I checks maintainer field from syft SBOM to judge if its from OS vendor or nginx upstream now.
// Sorry, I did not investigate deeply each cases
Looking at the APK spec, it appears there is an s: record that can point to a repository, but I tried adding a different repo an it didn't seem to get populated when I installed a package from the alternate repo.
I'm also having a hard time figuring out where the APT-Sources record is coming from in the apt case. It doesn't appear in the apt record, from what I can tell. But there seem to be a couple related files in the /var/lib/apt/lists:
nginx.org_packages_debian_dists_buster_InRelease
nginx.org_packages_debian_dists_buster_nginx_binary-amd64_Packages.lz4
... extracting the .lz4 appears to be more-or-less matching package records, but I don't see a definitive way to tie this back to the original apt sources list. Also, these files could be removed, I think, in a container.
Definitely happy for any insight how to surface this information for any packaging system!
@kzantow I believe the APT-Sources field refers to where the package is available and not where the installed package was obtained from. That would come (maybe) from APT logs. But assuming a pristine sources.list, it could be an OK approximation.
FYI
Recently, I try to gather OS packages in major software. By matching with our data, I think I can judge installed packages are OS package or not. // I'll add one more package information about Ubuntu later to match all package vesion.
https://github.com/witchcraze/pkg_check