False positive GHSA-jr9c-h74f-2v28/CVE-2022-0905 reported for Non-vulnerable Gitea version

[ramanNarasimhan77]

What happened:

I am using gitea/gitea:1.16.7 image in my application. Version from the binary within the Image is 1.16.7 as shown below

❯ docker run -it --entrypoint bash gitea/gitea:1.16.7
bash-5.1# gitea -h
NAME:
   Gitea - A painless self-hosted Git service

USAGE:
   gitea [global options] command [command options] [arguments...]

VERSION:
   1.16.7 built with GNU Make 4.3, go1.18.1 : bindata, timetzdata, sqlite, sqlite_unlock_notify

DESCRIPTION:
   By default, gitea will start serving using the webserver with no
arguments - which can alternatively be run by running the subcommand web.

COMMANDS:
   web              Start Gitea web server
   serv             This command should only be called by SSH shell
   hook             Delegate commands to corresponding Git hooks
   dump             Dump Gitea files and database
   cert             Generate self-signed certificate
   admin            Command line interface to perform common administrative operations
   generate         Command line interface for running generators
   migrate          Migrate the database
   keys             This command queries the Gitea database to get the authorized command for a given ssh key fingerprint
   convert          Convert the database
   doctor           Diagnose problems
   manager          Manage the running gitea process
   embedded         Extract embedded resources
   migrate-storage  Migrate the storage
   docs             Output CLI documentation
   dump-repo        Dump the repository from git/github/gitea/gitlab
   restore-repo     Restore the repository from disk
   help, h          Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --port value, -p value         Temporary port number to prevent conflict (default: "3000")
   --install-port value           Temporary port number to run the install page on to prevent conflict (default: "3000")
   --pid value, -P value          Custom pid file path (default: "/run/gitea.pid")
   --quiet, -q                    Only display Fatal logging errors until logging is set-up
   --verbose                      Set initial logging to TRACE level until logging is properly set-up
   --custom-path value, -C value  Custom path file path (default: "/data/gitea")
   --config value, -c value       Custom configuration file path (default: "/data/gitea/conf/app.ini")
   --version, -v                  print the version
   --work-path value, -w value    Set the gitea working path (default: "/app/gitea")
   --help, -h                     show help

DEFAULT CONFIGURATION:
     CustomPath:  /data/gitea (GITEA_CUSTOM)
     CustomConf:  /data/gitea/conf/app.ini
     AppPath:     /usr/local/bin/gitea
     AppWorkPath: /app/gitea

Grype is however detecting the version as "(devel)" and hence marking it as vulnerable to a CVE applicable to versions older than 1.16.4.

❯ grype gitea/gitea:1.16.7 | grep -e GHSA-jr9c-h74f-2v28 -e CVE-2022-0905 -e NAME
 ✔ Vulnerability DB                [no update available]
 ✔ Loaded image                                                                                                                         gitea/gitea:1.16.7
 ✔ Parsed image                                                                    sha256:0fd1f4369fd71c7b09dbf96b182581e0cfbc267f6755d799a5a7f7417afe88e7
 ✔ Cataloged packages              [259 packages]
 ✔ Scanned for vulnerabilities     [100 vulnerabilities]
   ├── 16 critical, 48 high, 30 medium, 6 low, 0 negligible
   └── 51 fixed
[0003]  WARN some package(s) are missing CPEs. This may result in missing vulnerabilities. You may autogenerate these using: --add-cpes-if-none
NAME                             INSTALLED                           FIXED-IN                           TYPE       VULNERABILITY        SEVERITY
code.gitea.io/gitea              (devel)                             1.16.4                             go-module  GHSA-jr9c-h74f-2v28  High

What you expected to happen:

Grype should detect the correct Go binary app version.

How to reproduce it (as minimally and precisely as possible):

Demonstrated above

Anything else we need to know?:

Environment:

• Output of grype version:

❯ grype version
Application:          grype
Version:              0.65.0
Syft Version:         v0.86.1
BuildDate:            2023-07-31T18:09:33Z
GitCommit:            c97048baa1595a481a26f7add8b18d59ec65838a
GitDescription:       v0.65.0
Platform:             linux/amd64
GoVersion:            go1.19.11
Compiler:             gc
Supported DB Schema:  5

• OS (e.g: cat /etc/os-release or similar):

bash-4.4# cat /etc/os-release
NAME="SLES"
VERSION="15-SP4"
VERSION_ID="15.4"
PRETTY_NAME="SUSE Linux Enterprise Server 15 SP4"
ID="sles"
ID_LIKE="suse"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:15:sp4"
DOCUMENTATION_URL="https://documentation.suse.com/"

[westonsteimel]

Thanks @ramanNarasimhan77 , so unfortunately there still isn't a standardized way of embedding the version when building a go binary; however, syft does make an attempt at retrieving the version from common known patterns in the ldflags. We can take a look to see if there are adjustments we can make that would figure it out for gitea as well

[chidambaranathan-r]

@westonsteimel

We found some more CVEs reported incorrectly in gitea by grype due to version issue. Consolidated the whole list.

CVE-2018-15192/GHSA-fg3x-rwq9-74cw - https://nvd.nist.gov/vuln/detail/CVE-2018-15192 CVE-2018-18926/GHSA-hf6f-jq25-8gq9 - https://nvd.nist.gov/vuln/detail/CVE-2018-18926 CVE-2021-45330/GHSA-pg38-r834-g45j - https://nvd.nist.gov/vuln/detail/CVE-2021-45330 CVE-2021-45331/GHSA-hfmf-q69j-6m5p - https://nvd.nist.gov/vuln/detail/CVE-2021-45331 CVE-2022-30781/GHSA-p5f9-c9j9-g8qx - https://nvd.nist.gov/vuln/detail/CVE-2022-30781 CVE-2022-0905/GHSA-jr9c-h74f-2v28 - https://nvd.nist.gov/vuln/detail/CVE-2022-0905 CVE-2022-27313/GHSA-g7p7-x6w7-w6qg - https://nvd.nist.gov/vuln/detail/CVE-2022-27313

[willmurphyscode]

Syft is finding two different go executables that it considers copies of code.gitea.io/gitea, and assigning different versions to them.

• /app/gitea/gitea is found and reported as version v1.16.7
• /usr/local/bin/environment-to-ini is found and reported as version (devel).

The file at /usr/local/bin/environment-to-ini is indeed a Go executable, and mentions gitea in its help text.

I copied that file into its own dir and ran syft -q dir:. to see what packages syft finds:

NAME                                VERSION                             TYPE
code.gitea.io/gitea                 (devel)                             go-module
command-line-arguments              (devel)                             go-module
github.com/cpuguy83/go-md2man/v2    v2.0.1                              go-module
github.com/gobwas/glob              v0.2.3                              go-module
github.com/golang-jwt/jwt/v4        v4.3.0                              go-module
github.com/json-iterator/go         v1.1.12                             go-module
github.com/kballard/go-shellquote   v0.0.0-20180428030007-95032a82bc51  go-module
github.com/modern-go/concurrent     v0.0.0-20180306012644-bacd9c7ef1dd  go-module
github.com/modern-go/reflect2       v1.0.2                              go-module
github.com/russross/blackfriday/v2  v2.1.0                              go-module
github.com/unknwon/com              v1.0.1                              go-module
github.com/urfave/cli               v1.22.5                             go-module
golang.org/x/crypto                 v0.0.0-20220411220226-7b82a4e95df4  go-module
golang.org/x/text                   v0.3.7                              go-module
gopkg.in/ini.v1                     v1.66.2                             go-module
strk.kbt.io/projects/go/libravatar  v0.0.0-20191008002943-06d1c002b251  go-module

[willmurphyscode]

Hi @ramanNarasimhan77,

Since this was reported, there's been some effort to better identify Go main module versions. I believe the original issue is fixed:

$ grype -q gitea/gitea:1.16.7 | grep -e GHSA-jr9c-h74f-2v28 -e CVE-2022-0905 -e NAME
NAME                             INSTALLED                           FIXED-IN                           TYPE       VULNERABILITY        SEVERITY

Is there anything else we should be checking for, or can this be closed? Thanks!

[ramanNarasimhan77]

Hi @willmurphyscode

Thanks for letting me know that the original issue has been fixed. I believe this ticket can be closed.

Thanks Raman