Skip to content
GitLab
Next
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    Projects Groups Topics Snippets
  • Register
  • Sign in
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 54.9k
    • Issues 54.9k
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1.5k
    • Merge requests 1.5k
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Terraform modules
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #36855
Closed
Open
Issue created Nov 20, 2019 by Joern Schneeweisz@joernchenDeveloper

AES-GCM issues in lib/gitlab/crypto_helper.rb

The Gitlab::CryptoHelper module is being used to encrypt sensitive token values within the database. The token values are encrypted utilizing AES-GCM. AES-GCM is an authenticated cipher, thus ensuring integrity of the stored ciphertexts. Within the Gitlab::CryptoHelper implementation however this cannot be guaranteed. The cipher is set up with a static key and a static nonce as follows:

    AES256_GCM_OPTIONS = {
      algorithm: 'aes-256-gcm',
      key: Settings.attr_encrypted_db_key_base_32,
      iv: Settings.attr_encrypted_db_key_base_12
    }.freeze

Both Settings.attr_encrypted_db_key_base_32 and Settings.attr_encrypted_db_key_base_12 are static values, namely the first 32 or the first 12 bytes of Gitlab::Application.secrets.db_key_base.

There are several issues with those settings:

  • Key and IV (nonce) are related to each other (IV is a substring of the key)
    • This is not advisable, even tough this is not directly exploitable the IV and key should not relate to each other
  • Gitlab::Application.secrets.db_key_base is a hexadecimal string e.g. "7ce6778d9ef49559..." this results in both IV and key are effectively half as long as intended
  • The nonce reuse allows recovery of the authentication key used within AES-GCM.
    • Just by observing two different ciphertexts and their respective authentication tags we can forge authentication tags for arbitrary ciphertexts.
  • When knowing a plain/ciphertext pair (e.g. from a project's runners token) we can deduce the keystream and thus encrypt arbitrary values up to the length of our known pair

I'd suggest to store a random IV along with the encrypted value. Additionally the key should be derived from Gitlab::Application.secrets.db_key_base with e.g. PBKDF2.

Assignee
Assign to
Time tracking