Reino: Code Quality

Una mala calidad del código lleva a un comportamiento no predecible. Desde la perspectiva de un usuario, muchas veces también supone una usabilidad limitada. Pero para un atacante es una oportunidad para atacar al sistema de formas insospechadas.

Memory Leak

Abstract

La memoria se asigna, pero nunca se libera.

Explanation

Las pérdidas de memoria presentan dos causas habituales, que a veces se superponen:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar la memoria.

Por lo general, la mayoría de las pérdidas de memoria provocan problemas de confiabilidad pero si un atacante puede desencadenar de forma intencionada una pérdida de memoria, este puede ser capaz de iniciar un ataque de denegación de servicio (bloqueando el programa) o aprovechar otro comportamiento inesperado del programa derivado de una situación de bajo nivel de memoria [1].

Ejemplo 1: la siguiente función de C pierde un bloque de memoria asignada si la llamada a read() no devuelve el número esperado de bytes:


  char* getBlock(int fd) {
  char* buf = (char*) malloc(BLOCK_SIZE);
  if (!buf) {
    return NULL;
  }
  if (read(fd, buf, BLOCK_SIZE) != BLOCK_SIZE) {
    return NULL;
  }
  return buf;
}

References

[1] J. Whittaker and H. Thompson How to Break Software Security Addison Wesley

[2] Standards Mapping - Common Weakness Enumeration CWE ID 401

[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094

[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data

[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 21.3

[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.3

[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 18-4-1

[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 21.6.1

[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)

[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection

[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2

[12] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6

[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6

[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6

[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

[19] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4

[20] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[21] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection

[22] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection

[23] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II

[24] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II

[25] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II

[26] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II

[27] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II

[28] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II

[29] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II

[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II

[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II

[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II

[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II

[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II

[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II

[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II

[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II

[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II

[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II

[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II

[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II

[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II

[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II

[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002400 CAT II

[45] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002400 CAT II

[46] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)

[47] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service

desc.controlflow.cpp.memory_leak

Abstract

La memoria está asignada, pero nunca se libera.

Explanation

Las pérdidas de memoria tienen dos causas comunes que a menudo se solapan:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar la memoria.

La mayoría de pérdidas de memoria derivan en problemas generales de confiabilidad de software, pero si un atacante puede desencadenar intencionadamente una pérdida de memoria, también puede ser capaz de lanzar un ataque de denegación de servicio (bloqueando el programa) o aprovecharse de otro comportamiento inesperado del programa derivado de una situación de bajo nivel de memoria [1].

Ejemplo 1: El siguiente programa de Micro Focus COBOL genera fugas de un bloque de memoria asignada si se produce un error:


  CALL "CBL_ALLOC_MEM"
      USING mem-pointer
      BY VALUE mem-size
      BY VALUE flags
      RETURNING status-code
  END-CALL

  IF status-code NOT = 0
      DISPLAY "Error!"
      GOBACK
  ELSE
      SET ADDRESS OF mem TO mem-pointer
  END-IF

  PERFORM write-data
  IF ws-status-code NOT = 0
      DISPLAY "Error!"
      GOBACK
  ELSE
      DISPLAY "Success!"
  END-IF

  CALL "CBL_FREE_MEM"
      USING BY VALUE mem-pointer
      RETURNING status-code
  END-CALL

  GOBACK
  .