CWE-195 Variante Rascunho

Signed to Unsigned Conversion Error

This vulnerability occurs when a signed integer (which can hold negative values) is converted to an unsigned integer (which holds only non-negative values). If the original signed value is negative,…

Definição

What is CWE-195?

This vulnerability occurs when a signed integer (which can hold negative values) is converted to an unsigned integer (which holds only non-negative values). If the original signed value is negative, the conversion produces a large, unexpected positive number instead of an error, breaking the program's logic.
Implicit conversions between signed and unsigned numbers are a common source of bugs because they happen silently during assignments or function calls. Developers often assume the value remains semantically the same, but a negative signed number becomes a very large unsigned number. This violates program assumptions and can lead to incorrect calculations, infinite loops, or flawed condition checks. A critical risk emerges when these converted values control memory operations. Many functions return negative numbers to signal errors (like -1). If such a return value is passed directly as a 'size' argument to functions like memcpy() or malloc(), the implicit conversion turns the failure indicator into a massive allocation or copy length. This typically causes a buffer overflow, crashing the program or creating a serious security exploit.
Impacto no mundo real

Real-world CVEs caused by CWE-195

  • Font rendering library does not properly handle assigning a signed short value to an unsigned long (CWE-195), leading to an integer wraparound (CWE-190), causing too small of a buffer (CWE-131), leading to an out-of-bounds write (CWE-787).

  • Chain: integer signedness error (CWE-195) passes signed comparison, leading to heap overflow (CWE-122)

Como os atacantes a exploram

Trajeto do atacante passo a passo

  1. 1

    In this example the variable amount can hold a negative value when it is returned. Because the function is declared to return an unsigned int, amount will be implicitly converted to unsigned.

  2. 2

    If the error condition in the code above is met, then the return value of readdata() will be 4,294,967,295 on a system that uses 32-bit integers.

  3. 3

    In this example, depending on the return value of accecssmainframe(), the variable amount can hold a negative value when it is returned. Because the function is declared to return an unsigned value, amount will be implicitly cast to an unsigned number.

  4. 4

    If the return value of accessmainframe() is -1, then the return value of readdata() will be 4,294,967,295 on a system that uses 32-bit integers.

  5. 5

    The following code is intended to read an incoming packet from a socket and extract one or more headers.

Exemplo de código vulnerável

Vulnerable C

In this example the variable amount can hold a negative value when it is returned. Because the function is declared to return an unsigned int, amount will be implicitly converted to unsigned.

Vulnerável C
unsigned int readdata () {
  	int amount = 0;
  	...
  	if (result == ERROR)
  	amount = -1;
  	...
  	return amount;
  }
Exemplo de código seguro

Secure pseudo

Seguro pseudo
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
  const safe = validateAndEscape(input);
  return executeWithGuards(safe);
}
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-195

  • Architecture Use safe-by-default frameworks and APIs that prevent the unsafe pattern from being expressible.
  • Implementation Validate input at trust boundaries; use allowlists, not denylists.
  • Implementation Apply the principle of least privilege to credentials, file paths, and runtime permissions.
  • Testing Cover this weakness in CI: SAST rules + targeted unit tests for the data flow.
  • Operation Monitor logs for the runtime signals listed in the next section.
Sinais de deteção

How to detect CWE-195

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.)

CWE-195

Don't catalog this weakness. Prove it's reachable.

Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.

Perguntas frequentes

Frequently asked questions

O que é o CWE-195?

This vulnerability occurs when a signed integer (which can hold negative values) is converted to an unsigned integer (which holds only non-negative values). If the original signed value is negative, the conversion produces a large, unexpected positive number instead of an error, breaking the program's logic.

Qual a gravidade do CWE-195?

A MITRE não publicou uma classificação de probabilidade de exploração para esta fraqueza. Trate-a como impacto médio até o seu modelo de ameaças provar o contrário.

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

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

Como posso prevenir o CWE-195?

Use safe-by-default frameworks, validate untrusted input at trust boundaries, and apply the principle of least privilege. Cover the data-flow signature in CI with SAST.

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

O motor SAST do Plexicus correlaciona a assinatura de fluxo de dados do CWE-195 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-195?

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

Pronto para validar o que importa?

Pronto para validar o que importa.

O Plexicus é Proof-Driven AppSec: achados validados, compreensão contextual e remediação revisada — ancorada em evidência, escopada com você.

Qualificação

Verifique se o AI Swarm Pentest se adequa ao seu ambiente.

Partilhe o contexto mínimo. Vamos rever o escopo e indicar o próximo passo comercial.

Antes de enviar — verifique se se encaixa

0 / 280

Sem compromisso. Se não se encaixa, dizemos.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorized target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)
Ronda privada Para investidores