Weak Encryption: User-Controlled Key Size

Encryption functions that take a key size parameter should not be passed a tainted key size value.

Allowing a user-controlled value to determine the key size may enable the attacker to specify an empty key, allowing for relatively easy decryption of any data that has been encrypted with the empty key. Even if a non-zero value is required, an attacker could still specify the lowest possible value, decreasing the security of the encryption.

Weak Encryption: User-Controlled Key Size issues occur when:

1. Data enters a program through an untrusted source

2. User-controlled data is included within the key size parameter, or used entirely as the key size parameter within an encryption function.

As with many software security vulnerabilities, Weak Encryption: User-Controlled Key Size is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the key size value while performing encryption.

The problem with having a user-controlled key size is that it can enable various attacks:

1. The attacker may use this vulnerability to specify a key size of zero for the encryption operations involving any data accessible by them. From this, it would be trivial to attempt to decrypt their own data using a number of different algorithms along with empty keys in order to leak information about the encryption implementation used within the application. This could make decrypting other users' encrypted data easier by allowing the attacker to focus only on particular algorithms during their cracking efforts.
2. The attacker may manipulate other users' encryption key sizes, or trick other users into using an encryption key size of zero (or as low as possible), potentially enabling the attacker to read other users' encrypted data (once the attacker has knowledge of the encryption algorithm used).

Example 1: The following code performs RSA encryption with a user-controlled key size parameter:

    ...
    RSACryptoServiceProvider rsa1 = new RSACryptoServiceProvider(Convert.ToInt32(tx.Text));
    ...
    

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the key size parameter to the encryption algorithm by modifying the textbox value tx.Text. After the program ships, it can be nontrivial to undo an issue regarding user-controlled key sizes, as it is extremely difficult to know if a malicious user determined the key size of a given encryption operation.

Encryption functions that take a key size can receive a tainted key size value.

By allowing a user-controlled value to determine the key size,an attacker can specify an empty key, which allows for relatively easy decryption of any data that has been encrypted with the empty key. Even if a non-zero value is required, an attacker could still specify the lowest possible value, decreasing the security of the encryption.

Weak Encryption: User-Controlled Key Size issues occur when:

1. Data enters a program through an untrusted source

2. User-controlled data is included within the key size parameter, or used entirely as the key size parameter within an encryption function.

As with many software security vulnerabilities, Weak Encryption: User-Controlled Key Size is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the key size value to perform encryption.

The problem with having a user-controlled key size is that it can enable various attacks:

1. The attacker can use this vulnerability to specify a key size of zero for the encryption operations involving any data accessible by them. It would then be trivial to attempt to decrypt their own data using a number of different algorithms along with empty keys to leak encryption implementation information used within the application. This could make decrypting other users' encrypted data easier by allowing the attacker to focus only on particular algorithms during their cracking efforts.
2. The attacker can manipulate other users' encryption key sizes, or trick other users into using an encryption key size of zero (or another low number), potentially enabling the attacker to read other users' encrypted data (after the attacker has knowledge of the encryption algorithm used).

Example 1: The following code generates an RSA key with a user-controlled derived key length:

...
rsa.GenerateKey(random, user_input)
...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the key size parameter to the encryption algorithm since the variable user_input can be controlled by the user. After a software release, it can be nontrivial to undo an issue regarding user-controlled key sizes. It is extremely difficult to know if a malicious user-controlled the key size of a given encryption operation.

Encryption functions that take a key size parameter should not be passed a tainted key size value.

Allowing a user-controlled value to determine the key size may enable the attacker to specify an empty key, allowing for relatively easy decryption of any data that has been encrypted with the empty key. Even if a non-zero value is required, an attacker could still specify the lowest possible value, decreasing the security of the encryption.

Weak Encryption: User-Controlled Key Size issues occur when:

1. Data enters a program through an untrusted source

2. User-controlled data is included within the key size parameter, or used entirely as the key size parameter within an encryption function.

As with many software security vulnerabilities, Weak Encryption: User-Controlled Key Size is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the key size value while performing encryption.

The problem with having a user-controlled key size is that it can enable various attacks:

1. The attacker may use this vulnerability to specify a key size of zero for the encryption operations involving any data accessible by them. From this, it would be trivial to attempt to decrypt their own data using a number of different algorithms along with empty keys in order to leak information about the encryption implementation used within the application. This could make decrypting other users' encrypted data easier by allowing the attacker to focus only on particular algorithms during their cracking efforts.
2. The attacker may manipulate other users' encryption key sizes, or trick other users into using an encryption key size of zero (or as low as possible), potentially enabling the attacker to read other users' encrypted data (once the attacker has knowledge of the encryption algorithm used).

Example 1: The following code performs AES encryption with a user-controlled key size parameter:

...
@property (strong, nonatomic) IBOutlet UITextField *inputTextField;
...
CCCrypt(kCCEncrypt,
        kCCAlgorithmAES,
        kCCOptionPKCS7Padding,
        key,
        sizeof(_inputTextField.text),
        iv,
        plaintext,
        sizeof(plaintext),
        ciphertext,
        sizeof(ciphertext),
        &numBytesEncrypted);
...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the key size parameter to the encryption algorithm by modifying the text in the UITextField inputTextField. After the program ships, it can be nontrivial to undo an issue regarding user-controlled key sizes, as it is extremely difficult to know if a malicious user determined the key size of a given encryption operation.

Encryption functions that take a key size parameter should not be passed a tainted key size value.

Allowing a user-controlled value to determine the key size may enable the attacker to specify an empty key, allowing for relatively easy decryption of any data that has been encrypted with the empty key. Even if a non-zero value is required, an attacker could still specify the lowest possible value, decreasing the security of the encryption.

Weak Encryption: User-Controlled Key Size issues occur when:

1. Data enters a program through an untrusted source

2. User-controlled data is included within the key size parameter, or used entirely as the key size parameter within an encryption function.

As with many software security vulnerabilities, Weak Encryption: User-Controlled Key Size is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the key size value while performing encryption.

The problem with having a user-controlled key size is that it can enable various attacks:

1. The attacker may use this vulnerability to specify a key size of zero for the encryption operations involving any data accessible by them. From this, it would be trivial to attempt to decrypt their own data using a number of different algorithms along with empty keys in order to leak information about the encryption implementation used within the application. This could make decrypting other users' encrypted data easier by allowing the attacker to focus only on particular algorithms during their cracking efforts.
2. The attacker may manipulate other users' encryption key sizes, or trick other users into using an encryption key size of zero (or as low as possible), potentially enabling the attacker to read other users' encrypted data (once the attacker has knowledge of the encryption algorithm used).

Example 1: The following code derives a key from a password, but uses a user-controlled derived key length:

...
$hash = hash_pbkdf2('sha256', $password, $random_salt, 100000, strlen($password));
...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the key size parameter to the encryption algorithm since the variable user_input can be controlled by the user. After the program ships, it can be nontrivial to undo an issue regarding user-controlled key sizes, as it is extremely difficult to know if a malicious user determined the key size of a given encryption operation.

Encryption functions that take a key size parameter should not be passed a tainted key size value.

Allowing a user-controlled value to determine the key size may enable the attacker to specify an empty key, allowing for relatively easy decryption of any data that has been encrypted with the empty key. Even if a non-zero value is required, an attacker could still specify the lowest possible value, decreasing the security of the encryption.

Weak Encryption: User-Controlled Key Size issues occur when:

1. Data enters a program through an untrusted source

2. User-controlled data is included within the key size parameter, or used entirely as the key size parameter within an encryption function.

As with many software security vulnerabilities, Weak Encryption: User-Controlled Key Size is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the key size value while performing encryption.

The problem with having a user-controlled key size is that it can enable various attacks:

1. The attacker may use this vulnerability to specify a key size of zero for the encryption operations involving any data accessible by them. From this, it would be trivial to attempt to decrypt their own data using a number of different algorithms along with empty keys in order to leak information about the encryption implementation used within the application. This could make decrypting other users' encrypted data easier by allowing the attacker to focus only on particular algorithms during their cracking efforts.
2. The attacker may manipulate other users' encryption key sizes, or trick other users into using an encryption key size of zero (or as low as possible), potentially enabling the attacker to read other users' encrypted data (once the attacker has knowledge of the encryption algorithm used).

Example 1: The following code derives a key from a password, but uses a user-controlled derived key length:

...
dk = hashlib.pbkdf2_hmac('sha256', password, random_salt, 100000, dklen=user_input)
...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the key size parameter to the encryption algorithm since the variable user_input can be controlled by the user. After the program ships, it can be nontrivial to undo an issue regarding user-controlled key sizes, as it is extremely difficult to know if a malicious user determined the key size of a given encryption operation.

Encryption functions that take a key size parameter should not be passed a tainted key size value.

Allowing a user-controlled value to determine the key size may enable the attacker to specify an empty key, allowing for relatively easy decryption of any data that has been encrypted with the empty key. Even if a non-zero value is required, an attacker could still specify the lowest possible value, decreasing the security of the encryption.

Weak Encryption: User-Controlled Key Size issues occur when:

1. Data enters a program through an untrusted source

2. User-controlled data is included within the key size parameter, or used entirely as the key size parameter within an encryption function.

As with many software security vulnerabilities, Weak Encryption: User-Controlled Key Size is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the key size value while performing encryption.

The problem with having a user-controlled key size is that it can enable various attacks:

1. The attacker may use this vulnerability to specify a key size of zero for the encryption operations involving any data accessible by them. From this, it would be trivial to attempt to decrypt their own data using a number of different algorithms along with empty keys in order to leak information about the encryption implementation used within the application. This could make decrypting other users' encrypted data easier by allowing the attacker to focus only on particular algorithms during their cracking efforts.
2. The attacker may manipulate other users' encryption key sizes, or trick other users into using an encryption key size of zero (or as low as possible), potentially enabling the attacker to read other users' encrypted data (once the attacker has knowledge of the encryption algorithm used).

Example 1: The following code derives a key from a password, but uses a user-controlled derived key length:

...
dk = OpenSSL::PKCS5.pbkdf2_hmac(password, random_salt, 100000, user_input, digest)
...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the key size parameter to the encryption algorithm since the variable user_input can be controlled by the user. After the program ships, it can be nontrivial to undo an issue regarding user-controlled key sizes, as it is extremely difficult to know if a malicious user determined the key size of a given encryption operation.

Encryption functions that take a key size parameter should not be passed a tainted key size value.

Allowing a user-controlled value to determine the key size may enable the attacker to specify an empty key, allowing for relatively easy decryption of any data that has been encrypted with the empty key. Even if a non-zero value is required, an attacker could still specify the lowest possible value, decreasing the security of the encryption.

Weak Encryption: User-Controlled Key Size issues occur when:

1. Data enters a program through an untrusted source

2. User-controlled data is included within the key size parameter, or used entirely as the key size parameter within an encryption function.

As with many software security vulnerabilities, Weak Encryption: User-Controlled Key Size is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the key size value while performing encryption.

The problem with having a user-controlled key size is that it can enable various attacks:

1. The attacker may use this vulnerability to specify a key size of zero for the encryption operations involving any data accessible by them. From this, it would be trivial to attempt to decrypt their own data using a number of different algorithms along with empty keys in order to leak information about the encryption implementation used within the application. This could make decrypting other users' encrypted data easier by allowing the attacker to focus only on particular algorithms during their cracking efforts.
2. The attacker may manipulate other users' encryption key sizes, or trick other users into using an encryption key size of zero (or as low as possible), potentially enabling the attacker to read other users' encrypted data (once the attacker has knowledge of the encryption algorithm used).

Example 1: The following code performs AES encryption with a user-controlled key size parameter:

...
@IBOutlet weak var inputTextField : UITextField!
...
let key = (inputTextField.text as NSString).dataUsingEncoding(NSUTF8StringEncoding)
let keyPointer = UnsafePointer<UInt8>(key.bytes)
let keyLength = size_t(key.length)
...
let operation : CCOperation = UInt32(kCCEncrypt)
let algoritm : CCAlgorithm = UInt32(kCCAlgorithmAES128)
let options : CCOptions = UInt32(kCCOptionPKCS7Padding)
var numBytesEncrypted :size_t = 0
CCCrypt(operation,
        algorithm,
        options,
        keyPointer,
        keyLength,
        iv,
        plaintextPointer,
        plaintextLength,
        ciphertextPointer,
        ciphertextLength,
        &numBytesEncrypted)
...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the key size parameter to the encryption algorithm by modifying the text in the UITextField inputTextField. After the program ships, it can be nontrivial to undo an issue regarding user-controlled key sizes, as it is extremely difficult to know if a malicious user determined the key size of a given encryption operation.