Main Content

CWE Rule 522

Insufficiently Protected Credentials

Since R2023a

expand all in page

Description

Rule Description

The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.

Polyspace Implementation

The rule checker checks for these issues:

  • Constant cipher key

  • Nonsecure hash algorithm

  • Nonsecure parameters for key generation

  • Nonsecure RSA public exponent

  • Nonsecure SSL/TLS protocol

  • Unsafe standard encryption function

Examples

expand all

Issue

This issue occurs when you use a constant for the encryption or decryption key.

Risk

If you use a constant for the encryption or decryption key, an attacker can retrieve your key easily.

You use a key to encrypt and later decrypt your data. If a key is easily retrieved, data encrypted using that key is not secure.

Fix

Produce a random key by using a strong random number generator.

For a list of random number generators that are cryptographically weak, see Vulnerable pseudo-random number generator.

Example — Constants Used for Key

#include <openssl/evp.h>
#include <stdlib.h>
#define SIZE16 16

int func(EVP_CIPHER_CTX *ctx, unsigned char *iv){
    unsigned char key[SIZE16] = {'1', '2', '3', '4','5','6','b','8','9',
                                 '1','2','3','4','5','6','7'};
    return EVP_CipherInit_ex(ctx, EVP_aes_128_cbc(), NULL, key, iv, 1);  //Noncompliant
}

In this example, the cipher key, key, has constants only. An attacker can easily retrieve a constant key.

Correction — Use Random Key

Use a strong random number generator to produce the cipher key. The corrected code here uses the function RAND_bytes declared in openssl/rand.h.


#include <openssl/evp.h>
#include <openssl/rand.h>
#include <stdlib.h>
#define SIZE16 16

int func(EVP_CIPHER_CTX *ctx, unsigned char *iv){
    unsigned char key[SIZE16];
    RAND_bytes(key, 16);
    return EVP_CipherInit_ex(ctx, EVP_aes_128_cbc(), NULL, key, iv, 1); 
}
Issue

This issue occurs when you use a cryptographic hash function that is proven to be weak against certain forms of attack.

The hash functions flagged by this checker include SHA-0, SHA-1, MD4, MD5, and RIPEMD-160. The checker detects the use of these hash functions in:

  • Functions from the EVP API such as EVP_DigestUpdate or EVP_SignUpdate.

  • Functions from the low level API such as SHA1_Update or MD5_Update.

Risk

You use a hash function to create a message digest from input data and thereby ensure integrity of your data. The hash functions flagged by this checker use algorithms with known weaknesses that an attacker can exploit. The attacks can comprise the integrity of your data.

Fix

Use a more secure hash function. For instance, use the later SHA functions such as SHA-224, SHA-256, SHA-384, and SHA-512.

Example — Use of MD5 Algorithm
#include <openssl/evp.h>

#define fatal_error() exit(-1)

int ret;
unsigned char *out_buf;
unsigned int out_len;

void func(unsigned char *src, size_t len, EVP_PKEY* pkey){
  EVP_MD_CTX* ctx = EVP_MD_CTX_create();

  ret = EVP_SignInit_ex(ctx, EVP_md5(), NULL);
  if (ret != 1) fatal_error();

  ret = EVP_DigestUpdate(ctx,src,len);  //Noncompliant

  if (ret != 1) fatal_error();

  ret = EVP_SignFinal(ctx, out_buf, &out_len, pkey);
  if (ret != 1) fatal_error();
}

In this example, during initialization with EVP_SignInit_ex, the context object is associated with the weak hash function MD5. The checker flags the usage of this context in the update step with EVP_DigestUpdate.

Correction — Use SHA-2 Family Function

One possible correction is to use a hash function from the SHA-2 family, such as SHA-256.

#include <openssl/evp.h>

#define fatal_error() exit(-1)

int ret;
unsigned char *out_buf;
unsigned int out_len;

void func(unsigned char *src, size_t len, EVP_PKEY* pkey){
  EVP_MD_CTX* ctx = EVP_MD_CTX_create();

  ret = EVP_SignInit_ex(ctx, EVP_sha256(), NULL); 
  if (ret != 1) fatal_error();

  ret = EVP_SignUpdate(ctx, src, len); 
  if (ret != 1) fatal_error();

  ret = EVP_SignFinal(ctx, out_buf, &out_len, pkey);
  if (ret != 1) fatal_error();
}
Issue

This issue occurs when you attempt key generation by using an EVP_PKEY_CTX context object that is associated with weak parameters. What constitutes a weak parameter depends on the public key algorithm used. In the DSA algorithm, a weak parameter can be the result of setting an insufficient parameter length.

For instance, you set the number of bits used for DSA parameter generation to 512 bits, and then use the parameters for key generation:

EVP_PKEY_CTX *pctx,*kctx;
EVP_PKEY *params, *pkey;

/* Initializations for parameter generation */
pctx = EVP_PKEY_CTX_new_id(EVP_PKEY_DSA, NULL);
params = EVP_PKEY_new();

/* Parameter generation */
ret = EVP_PKEY_paramgen_init(pctx);
ret = EVP_PKEY_CTX_set_dsa_paramgen_bits(pctx, KEYLEN_512BITS);
ret = EVP_PKEY_paramgen(pctx, &params);

/* Initializations for key generation */
kctx = EVP_PKEY_CTX_new(params, NULL);
pkey = EVP_PKEY_new();

/* Key generation */
ret = EVP_PKEY_keygen_init(kctx);
ret = EVP_PKEY_keygen(kctx, &pkey);

Risk

Weak parameters lead to keys that are not sufficiently strong for encryption and expose sensitive information to known ways of attack.

Fix

Depending on the algorithm, use these parameters:

  • Diffie-Hellman (DH): Set the length of the DH prime parameter to 2048 bits.

    ret = EVP_PKEY_CTX_set_dh_paramgen_prime_len(pctx, 2048);
    Set the DH generator to 2 or 5.
    ret = EVP_PKEY_CTX_set_dh_paramgen_generator(pctx, 2);

  • Digital Signature Algorithm (DSA): Set the number of bits used for DSA parameter generation to 2048 bits.

    ret = EVP_PKEY_CTX_set_dsa_paramgen_bits(pctx, 2048);

  • RSA: Set the RSA key length to 2048 bits.

    ret = EVP_PKEY_CTX_set_rsa_keygen_bits(kctx, 2048);

  • Elliptic curve (EC): Avoid using curves that are known to be broken, for instance, X9_62_prime256v1. Use, for instance, sect239k1.

    ret = EVP_PKEY_CTX_set_ec_paramgen_curve_nid(pctx, NID_sect239k1);

Example — Insufficient Bits for RSA Key Generation
#include <stddef.h>
#include <openssl/rsa.h>
#include <openssl/evp.h>

#define fatal_error() exit(-1)

int ret;
int func(EVP_PKEY *pkey){
  EVP_PKEY_CTX * ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL); 
  if (ctx == NULL) fatal_error();

  ret = EVP_PKEY_keygen_init(ctx);
  if (ret <= 0) fatal_error();
  ret = EVP_PKEY_CTX_set_rsa_keygen_bits(ctx, 512); 
  if (ret <= 0) fatal_error();
  return EVP_PKEY_keygen(ctx, &pkey);  //Noncompliant
}

In this example, the RSA key generation uses 512 bits, which makes the generated key vulnerable to attacks.

Correction — Use 2048 bits

Use 2048 bits for RSA key generation.

#include <stddef.h>
#include <openssl/rsa.h>
#include <openssl/evp.h>

#define fatal_error() exit(-1)

int ret;
int func(EVP_PKEY *pkey){
  EVP_PKEY_CTX * ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL); 
  if (ctx == NULL) fatal_error();

  ret = EVP_PKEY_keygen_init(ctx);
  if (ret <= 0) fatal_error();
  ret = EVP_PKEY_CTX_set_rsa_keygen_bits(ctx, 2048); 
  if (ret <= 0) fatal_error();
  return EVP_PKEY_keygen(ctx, &pkey); 
}
Issue

This issue occurs when you attempt RSA key generation by using a context object that is associated with a low public exponent.

For instance, you set a public exponent of 3 in the context object, and then use it for key generation.

/* Set public exponent */
ret = BN_dec2bn(&pubexp, "3");

/* Initialize context */
ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL); 
pkey = EVP_PKEY_new();
ret = EVP_PKEY_keygen_init(kctx);

/* Set public exponent in context */
ret = EVP_PKEY_CTX_set_rsa_keygen_pubexp(ctx, pubexp);

/* Generate key */
ret = EVP_PKEY_keygen(kctx, &pkey);

Risk

A low RSA public exponent makes certain kinds of attacks more damaging, especially when a weak padding scheme is used or padding is not used at all.

Fix

It is recommended to use a public exponent of 65537. Using a higher public exponent can make the operations slower.

Example — Using RSA Public Exponent of 3
#include <stddef.h>
#include <openssl/rsa.h>
#include <openssl/evp.h>

#define fatal_error() exit(-1)

int ret;
int func(EVP_PKEY *pkey){
  BIGNUM* pubexp;
  EVP_PKEY_CTX* ctx;

  pubexp = BN_new();
  if (pubexp == NULL) fatal_error();
  ret = BN_set_word(pubexp, 3);
  if (ret <= 0) fatal_error();

  ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL);
  if (ctx == NULL) fatal_error();

  ret = EVP_PKEY_keygen_init(ctx);
  if (ret <= 0) fatal_error();
  ret = EVP_PKEY_CTX_set_rsa_keygen_bits(ctx, 2048);
  if (ret <= 0) fatal_error();
  ret = EVP_PKEY_CTX_set_rsa_keygen_pubexp(ctx, pubexp);
  if (ret <= 0) fatal_error();
  return EVP_PKEY_keygen(ctx, &pkey);  //Noncompliant
}

In this example, an RSA public exponent of 3 is associated with the context object ctx. The low exponent makes operations that use the generated key vulnerable to certain attacks.

Correction — Use Public Exponent of 65537

One possible correction is to use the recommended public exponent 65537.

#include <stddef.h>
#include <openssl/rsa.h>
#include <openssl/evp.h>

#define fatal_error() exit(-1)

int ret;
int func(EVP_PKEY *pkey){
  BIGNUM* pubexp;
  EVP_PKEY_CTX* ctx;

  pubexp = BN_new();
  if (pubexp == NULL) fatal_error();
  ret = BN_set_word(pubexp, 65537);
  if (ret <= 0) fatal_error();

  ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL);
  if (ctx == NULL) fatal_error();

  ret = EVP_PKEY_keygen_init(ctx);
  if (ret <= 0) fatal_error();
  ret = EVP_PKEY_CTX_set_rsa_keygen_bits(ctx, 2048);
  if (ret <= 0) fatal_error();
  ret = EVP_PKEY_CTX_set_rsa_keygen_pubexp(ctx, pubexp);
  if (ret <= 0) fatal_error();
  return EVP_PKEY_keygen(ctx, &pkey);
}
Issue

This issue occurs when you do not disable nonsecure protocols in an SSL_CTX or SSL context object before using the object for handling SSL/TLS connections.

For instance, you disable the protocols SSL2.0 and TLS1.0 but forget to disable the protocol SSL3.0, which is also considered weak.

/* Create and configure context */
ctx = SSL_CTX_new(SSLv23_method());
SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_TLSv1);

/* Use context to handle connection */
ssl = SSL_new(ctx);
SSL_set_fd(ssl, NULL);
ret = SSL_connect(ssl);

Risk

The protocols SSL2.0, SSL3.0, and TLS1.0 are considered weak in the cryptographic community. Using one of these protocols can expose your connections to cross-protocol attacks. The attacker can decrypt an RSA ciphertext without knowing the RSA private key.

Fix

Disable the nonsecure protocols in the context object before using the object to handle connections.

/* Create and configure context */
ctx = SSL_CTX_new(SSLv23_method());
SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3|SSL_OP_NO_TLSv1);
Example — Nonsecure Protocols Not Disabled
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <openssl/ssl.h>
#include <openssl/err.h>


#define fatal_error() exit(-1)

int ret;
int func(){
  SSL_CTX *ctx;
  SSL *ssl;

  SSL_library_init();

  /* context configuration */
  ctx = SSL_CTX_new(SSLv23_client_method()); 
  if (ctx==NULL) fatal_error();

  ret = SSL_CTX_use_certificate_file(ctx, "cert.pem", SSL_FILETYPE_PEM); 
  if (ret <= 0) fatal_error();

  ret = SSL_CTX_load_verify_locations(ctx, NULL, "ca/path"); 
  if (ret <= 0) fatal_error();

  /* Handle connection */
  ssl = SSL_new(ctx);
  if (ssl==NULL) fatal_error();
  SSL_set_fd(ssl, NULL);

  return SSL_connect(ssl);  //Noncompliant
}

In this example, the protocols SSL2.0, SSL3.0, and TLS1.0 are not disabled in the context object before the object is used for a new connection.

Correction — Disable Nonsecure Protocols

Disable nonsecure protocols before using the objects for a new connection. Use the function SSL_CTX_set_options to disable the protocols SSL2.0, SSL3.0, and TLS1.0.

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <openssl/ssl.h>
#include <openssl/err.h>


#define fatal_error() exit(-1)

int ret;
int func(){
  SSL_CTX *ctx;
  SSL *ssl;

  SSL_library_init();

  /* context configuration */
  ctx = SSL_CTX_new(SSLv23_client_method()); 
  if (ctx==NULL) fatal_error();

  SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3|SSL_OP_NO_TLSv1);

  ret = SSL_CTX_use_certificate_file(ctx, "cert.pem", SSL_FILETYPE_PEM); 
  if (ret <= 0) fatal_error();

  ret = SSL_CTX_load_verify_locations(ctx, NULL, "ca/path"); 
  if (ret <= 0) fatal_error();

  /* Handle connection */
  ssl = SSL_new(ctx);
  if (ssl==NULL) fatal_error();
  SSL_set_fd(ssl, NULL);

  return SSL_connect(ssl); 
}
Issue

This issue occurs when a standard encryption function uses a broken or weak cryptographic algorithm. For example, crypt is not reentrant and is based on the risky Data Encryption Standard (DES).

Risk

The use of a broken, weak, or nonstandard algorithm can expose sensitive information to an attacker. A determined hacker can access the protected data using various techniques.

If the weak function is nonreentrant, when you use the function in concurrent programs, there is an additional race condition risk.

Fix

Avoid functions that use these encryption algorithms. Instead, use a reentrant function that uses a stronger encryption algorithm.

Note

Some implementations of crypt support additional, possibly more secure, encryption algorithms.

Example — Decrypting Password Using crypt
#define _GNU_SOURCE
#include <pwd.h>
#include <string.h>
#include <crypt.h>

volatile int rd = 1;

const char *salt = NULL;
struct crypt_data input, output;

int verif_pwd(const char *pwd, const char *cipher_pwd, int safe)
{
    int r = 0;
    char *decrypted_pwd = NULL;
    
    switch(safe)
    {
      case 1: 
        decrypted_pwd = crypt_r(pwd, cipher_pwd, &output);
        break;
        
      case 2: 
        decrypted_pwd = crypt_r(pwd, cipher_pwd, &output);
        break;
        
      default:
        decrypted_pwd = crypt(pwd, cipher_pwd);  //Noncompliant
        break;
    }
    
    r = (strcmp(cipher_pwd, decrypted_pwd) == 0); 
    
    return r;
}

In this example, crypt_r and crypt decrypt a password. However, crypt is nonreentrant and uses the unsafe Data Encryption Standard algorithm.

Correction — Use crypt_r

One possible correction is to replace crypt with crypt_r.

#define _GNU_SOURCE
#include <pwd.h>
#include <string.h>
#include <crypt.h>

volatile int rd = 1;

const char *salt = NULL;
struct crypt_data input, output;

int verif_pwd(const char *pwd, const char *cipher_pwd, int safe)
{
    int r = 0;
    char *decrypted_pwd = NULL;
    
    switch(safe)
    {
      case 1: 
        decrypted_pwd = crypt_r(pwd, cipher_pwd, &output);
        break;
        
      case 2: 
        decrypted_pwd = crypt_r(pwd, cipher_pwd, &output);
        break;
        
      default:
        decrypted_pwd = crypt_r(pwd, cipher_pwd, &output);  
        break;
    }
    
    r = (strcmp(cipher_pwd, decrypted_pwd) == 0);
    
    return r;
}

Check Information

Category: Others

Version History

Introduced in R2023a

See Also

Topics

External Websites