Rust: new query rust/hardcoded-crytographic-value

[geoffw0]

Adds a "Hard-coded cryptographic value" (rust/hardcoded-crytographic-value) query for Rust, detecting use of hardcoded keys, passwords, salts and initialization vectors. In other languages these have sometimes been implemented as separate queries (e.g. swift/constant-password, swift/hardcoded-key, swift/constant-salt, swift/static-initialization-vector) but I see no benefit to them being separate.

Note that a few sinks have been defined for the query in this pull request but they're a bit sparse. Improving that will be follow-up work.

TODO:

• review DCA
• code review
• docs review

[Copilot]

PR Overview

This pull request adds a new query to detect hardcoded cryptographic values in Rust code along with corresponding test cases and configuration updates for dependencies and library models.

• Introduces query tests for detecting hardcoded keys, salts, and initialization vectors in various cipher configurations.
• Provides both "bad" (hardcoded) and "good" (randomly generated) examples for cryptographic key usage.
• Updates dependency options and model files to support the new query.

Reviewed Changes

File	Description
rust/ql/test/query-tests/security/CWE-798/test_cipher.rs	Adds various test cases for hardcoded cryptographic values in cipher operations.
rust/ql/test/query-tests/security/CWE-798/options.yml	Specifies dependencies and cargo check options required for the tests.
rust/ql/src/queries/security/CWE-798/HardcodedCryptographicValueBad.rs	Introduces an example of bad usage with hardcoded keys.
rust/ql/src/queries/security/CWE-798/HardcodedCryptographicValueGood.rs	Provides an example of good usage using randomly generated keys.
rust/ql/lib/codeql/rust/frameworks/genericarray.model.yml	Updates model to include generic-array methods relevant to the query.
rust/ql/lib/codeql/rust/frameworks/rustcrypto/rustcrypto.model.yml	Enhances rustcrypto model with new mappings for cryptographic key and IV usage.
rust/ql/lib/codeql/rust/frameworks/stdlib/lang-core.model.yml	Adds conversions and constant source taint tracking relevant to key initialization.

Copilot reviewed 14 out of 14 changed files in this pull request and generated 4 comments.

Tip: Copilot only keeps its highest confidence comments to reduce noise and keep you focused. Learn more

[github-actions]

QHelp previews:

rust/ql/src/queries/security/CWE-798/HardcodedCryptographicValue.qhelp

Hard-coded cryptographic value

Hardcoded passwords, keys, initialization vectors and salts should not be used for cryptographic operations.

• Attackers can easily recover hardcoded values if they have access to the source code or compiled executable.
• Some hardcoded values are easily guessable.
• Use of hardcoded values may leave cryptographic operations vulnerable to dictionary attacks, rainbow tables, and other forms of cryptanalysis.

Recommendation

Use randomly generated key material, initialization vectors and salts. Use strong passwords that are not hardcoded.

Example

The following example shows instantiating a cipher with hardcoded key material, making the encrypted data vulnerable to recovery.

let key: [u8;32] = [0;32]; // BAD: Using hardcoded keys for encryption
let cipher = Aes256Gcm::new(&key.into());

In the fixed code below, the key material is randomly generated and not hardcoded, which protects the encrypted data against recovery. A real application would also need a strategy for secure key management after the key has been generated.

let key = Aes256Gcm::generate_key(aes_gcm::aead::OsRng); // GOOD: Using randomly generated keys for encryption
let cipher = Aes256Gcm::new(&key);

References

• OWASP: Use of hard-coded password.
• OWASP: Key Management Cheat Sheet.
• O'Reilly: Using Salts, Nonces, and Initialization Vectors.
• Common Weakness Enumeration: CWE-259.
• Common Weakness Enumeration: CWE-321.
• Common Weakness Enumeration: CWE-798.
• Common Weakness Enumeration: CWE-1204.

[geoffw0]

Some of these models are bothering me. They're all based on data from getResolvedPath + getResolvedCrateOrigin and they demonstrably work but:

• it would be cleaner and easier to implement the models if they could be expressed in more general terms, e.g. in terms of traits rather than implementations.
• it's also likely (well, certain) we're missing some implementations with these models as a result (AES is not he only block cipher in existence).
• I also observed some weird platform dependence, where everything worked on my local Mac but for CI I had to add a few additional variants of models to get the same results as I was already getting locally - that's what this commit is. I don't know if there was a known quirk affecting me here or something potentially serious and undiagnosed.

@hvitved I would really appreciate your opinion on these issues. I think we will need to address them to model sources and sinks effectively.

[geoffw0]

Update on the third bullet points: the MaD IDs still don't match what I generate locally. That's surely a clue to what's going on. Hopefully I just need to update something I haven't updated on my machine??? 🤞