CWE-457 Variante Rascunho High likelihood

Use of Uninitialized Variable

This vulnerability occurs when a program accesses a variable before it has been assigned a value, leading to unpredictable behavior and potential security risks.

Definição

What is CWE-457?

This vulnerability occurs when a program accesses a variable before it has been assigned a value, leading to unpredictable behavior and potential security risks.
In languages like C and C++, local variables declared on the stack are not automatically set to a known value. They contain whatever data was previously in that memory location ('junk data'), which an attacker might be able to influence or read. This can lead to information leaks, crashes, or logic flaws depending on how the program uses this unpredictable value. Using an uninitialized variable often points to a coding mistake, such as a typo or missing initialization logic. Even in languages that provide default values (like zero or null), relying on implicit initialization can introduce security weaknesses if the program's logic isn't explicitly handling the variable's starting state, making outcomes hard to predict and secure.
Impacto no mundo real

Real-world CVEs caused by CWE-457

  • Chain: sscanf() call is used to check if a username and group exists, but the return value of sscanf() call is not checked (CWE-252), causing an uninitialized variable to be checked (CWE-457), returning success to allow authorization bypass for executing a privileged (CWE-863).

  • Chain: A denial of service may be caused by an uninitialized variable (CWE-457) allowing an infinite loop (CWE-835) resulting from a connection to an unresponsive server.

  • Uninitialized variable leads to code execution in popular desktop application.

  • Crafted input triggers dereference of an uninitialized object pointer.

  • Crafted audio file triggers crash when an uninitialized variable is used.

  • Uninitialized random seed variable used.

Como os atacantes a exploram

Trajeto do atacante passo a passo

  1. 1

    This code prints a greeting using information stored in a POST request:

  2. 2

    This code checks if the POST array 'names' is set before assigning it to the $nameArray variable. However, if the array is not in the POST request, $nameArray will remain uninitialized. This will cause an error when the array is accessed to print the greeting message, which could lead to further exploit.

  3. 3

    The following switch statement is intended to set the values of the variables aN and bN before they are used:

  4. 4

    In the default case of the switch statement, the programmer has accidentally set the value of aN twice. As a result, bN will have an undefined value. Most uninitialized variable issues result in general software reliability problems, but if attackers can intentionally trigger the use of an uninitialized variable, they might be able to launch a denial of service attack by crashing the program. Under the right circumstances, an attacker may be able to control the value of an uninitialized variable by affecting the values on the stack prior to the invocation of the function.

  5. 5

    This example will leave test_string in an unknown condition when i is the same value as err_val, because test_string is not initialized (CWE-456). Depending on where this code segment appears (e.g. within a function body), test_string might be random if it is stored on the heap or stack. If the variable is declared in static memory, it might be zero or NULL. Compiler optimization might contribute to the unpredictability of this address.

Exemplo de código vulnerável

Vulnerable PHP

This code prints a greeting using information stored in a POST request:

Vulnerável PHP
if (isset($_POST['names'])) {
  	$nameArray = $_POST['names'];
  }
  echo "Hello " . $nameArray['first'];
Exemplo de código seguro

Secure C

When the printf() is reached, test_string might be an unexpected address, so the printf might print junk strings (CWE-457). To fix this code, there are a couple approaches to making sure that test_string has been properly set once it reaches the printf(). One solution would be to set test_string to an acceptable default before the conditional:

Seguro C
char *test_string = "Done at the beginning";
 if (i != err_val)
 {

```
  test_string = "Hello World!";
 }
 printf("%s", test_string);
What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Lista de verificação de prevenção

How to prevent CWE-457

  • Implementation Ensure that critical variables are initialized before first use [REF-1485].
  • Build and Compilation Most compilers will complain about the use of uninitialized variables if warnings are turned on.
  • Implementation / Operation When using a language that does not require explicit declaration of variables, run or compile the software in a mode that reports undeclared or unknown variables. This may indicate the presence of a typographic error in the variable's name.
  • Requirements Choose a language that is not susceptible to these issues.
  • Architecture and Design Mitigating technologies such as safe string libraries and container abstractions could be introduced.
Sinais de deteção

How to detect CWE-457

Fuzzing High

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Automated Static Analysis High

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Correção automática do Plexicus

O Plexicus deteta automaticamente o CWE-457 e abre um PR de correção em menos de 60 segundos.

O Codex Remedium analisa cada commit, identifica esta fraqueza exata e entrega um pull request pronto para revisão com o patch. Sem tickets. Sem transferências.

Perguntas frequentes

Frequently asked questions

O que é o CWE-457?

This vulnerability occurs when a program accesses a variable before it has been assigned a value, leading to unpredictable behavior and potential security risks.

Qual a gravidade do CWE-457?

A MITRE classifica a probabilidade de exploração como Alta — esta fraqueza é ativamente explorada em campo e deve ser priorizada para remediação.

Que linguagens ou plataformas são afetadas pelo CWE-457?

MITRE lists the following affected platforms: C, C++, Perl, PHP.

Como posso prevenir o CWE-457?

Ensure that critical variables are initialized before first use [REF-1485]. Most compilers will complain about the use of uninitialized variables if warnings are turned on.

Como é que o Plexicus deteta e corrige o CWE-457?

O motor SAST do Plexicus correlaciona a assinatura de fluxo de dados do CWE-457 em cada commit. Quando é encontrada uma correspondência, o nosso agente Codex Remedium abre um PR de correção com o código corrigido, testes e um resumo de uma linha para o revisor.

Onde posso saber mais sobre o CWE-457?

A MITRE publica a definição canónica em https://cwe.mitre.org/data/definitions/457.html. Pode também consultar a documentação da OWASP e do NIST para orientações adjacentes.

Pronto quando você estiver

Pare de pagar por desenvolvedor.
Comece a fechar o ciclo.

O Plexicus é o ASPM nativo de IA que verifica, filtra, corrige, pentesta e explica — de forma autónoma. Programadores ilimitados, repos ilimitados, ações de IA de utilização justa. Nível gratuito real, €269/mo anual quando estiver pronto.