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.