Fresh gitlab install shows serious security warnings

mmmueller1 · March 8, 2024, 1:44pm

I hope this is the right place to ask or should this maybe be escalated to security professionals?

I have a fresh gitlab install on Debian according to this manual: Download and install GitLab | GitLab

I am required to scan all machines with trivy for vulnerabilities, and now when I scan gitlab with:

trivy fs --scanners vuln --severity HIGH,CRITICAL  /opt/gitlab/

It shows a lot of critical or high severity errors — we track them with Dependency Track and it looks a bit frightening:

Do you have any idea how I can fix those security holes?

The command line report looks like so:

embedded/service/gitlab-rails/vendor/gems/omniauth-gitlab/Gemfile.lock (bundler)

Total: 4 (HIGH: 4, CRITICAL: 0)

┌─────────┬────────────────┬──────────┬────────┬───────────────────┬──────────────────────────────────────────────────────────┬───────────────────────────────────────────────────────────┐
│ Library │ Vulnerability  │ Severity │ Status │ Installed Version │                      Fixed Version                       │                           Title                           │
├─────────┼────────────────┼──────────┼────────┼───────────────────┼──────────────────────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ rack    │ CVE-2022-44570 │ HIGH     │ fixed  │ 2.2.4             │ ~> 2.0.9, >= 2.0.9.2, ~> 2.1.4, >= 2.1.4.2, ~> 2.2.6, >= │ rubygem-rack: denial of service in Content-Disposition    │
│         │                │          │        │                   │ 2.2.6.2, >= 3.0.4.1                                      │ parsing                                                   │
│         │                │          │        │                   │                                                          │ https://avd.aquasec.com/nvd/cve-2022-44570                │
│         ├────────────────┤          │        │                   ├──────────────────────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│         │ CVE-2022-44571 │          │        │                   │ ~> 2.0.9, >= 2.0.9.2, ~> 2.1.4, >= 2.1.4.2, ~> 2.2.6, >= │ rubygem-rack: denial of service in Content-Disposition    │
│         │                │          │        │                   │ 2.2.6.1, >= 3.0.4.1                                      │ parsing                                                   │
│         │                │          │        │                   │                                                          │ https://avd.aquasec.com/nvd/cve-2022-44571                │
│         ├────────────────┤          │        │                   │                                                          ├───────────────────────────────────────────────────────────┤
│         │ CVE-2022-44572 │          │        │                   │                                                          │ rubygem-rack: denial of service in Content-Disposition    │
│         │                │          │        │                   │                                                          │ parsing                                                   │
│         │                │          │        │                   │                                                          │ https://avd.aquasec.com/nvd/cve-2022-44572                │
│         ├────────────────┤          │        │                   ├──────────────────────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│         │ CVE-2023-27530 │          │        │                   │ ~> 2.0.9, >= 2.0.9.3, ~> 2.1.4, >= 2.1.4.3, ~> 2.2.6, >= │ rubygem-rack: Denial of service in Multipart MIME parsing │
│         │                │          │        │                   │ 2.2.6.3, >= 3.0.4.2                                      │ https://avd.aquasec.com/nvd/cve-2023-27530                │
└─────────┴────────────────┴──────────┴────────┴───────────────────┴──────────────────────────────────────────────────────────┴───────────────────────────────────────────────────────────┘

mmmueller1 · March 8, 2024, 2:15pm

Sorry for adding to my post: this also applies to scanning the docker Image —

trivy --scanners vuln  image gitlab/gitlab-ce:latest

iwalker · March 8, 2024, 3:27pm

Since the Gitlab package contains all of these components, it isn’t using anything at the operating system level in this instance. Which means, you cannot solve this yourself. It would require Gitlab to update and release a new Gitlab version - which they do regularly anyway for functionality as well as CVE fixes.

mmmueller1 · March 8, 2024, 3:39pm

I See, but some of these packages have years old vulnerabilities — seems like it must be an error or something? How would such an old version of rack make it into a production release? And why so many different versions of rack? I am a little confused

iwalker · March 8, 2024, 5:47pm

Are you 100$ sure that trivy isn’t reporting false positives? I’m pretty sure I’ve scanned my Gitlab instance before with Nessus, and never had it report so many problems.

I’ve seen countless times when a security scanner has been ran, and makes assumptions based on a package version, when it’s not necessarily taken into account that perhaps fixes have been backported to the version it found but failed to verify for sure.