Reino: Time and State

La computación distribuida trata sobre el tiempo y el estado. Es decir, para que más de un componente se comunique, debe compartir el estado, y todo esto requiere tiempo.

La mayoría de programadores antropomorfizan su trabajo. Piensan en un único puesto de control que lleva a cabo todo el programa de igual forma que harían ellos si tuviesen que realizar la tarea ellos mismos. Sin embargo, los equipos modernos cambian entre tareas con gran rapidez y, en una CPU múltiple con varios núcleos, o en los sistemas distribuidos, dos eventos pueden llevarse a cabo a la vez exactamente. Estos defectos hacen que sea urgente que se unan posturas entre el modelo de los programadores sobre cómo un programa se ejecuta y lo que sucede en la realidad. Dichos defectos están relacionados con interacciones inesperadas entre los puestos, los procesos, el tiempo y la información. Estas interacciones se producen a través del estado compartido: semáforos, variables, el sistema de archivos y, básicamente, cualquier cosa que pueda guardar información.

Race Condition: File System Access

Abstract
El periodo entre el momento en que se comprueba una propiedad de archivo y el momento en que se usa puede explotarse para iniciar un ataque de extensión de privilegios.
Explanation
Las condiciones de carrera de acceso a archivos, conocidas como condiciones de carrera de momento de comprobación y momento de uso (TOCTOU, por sus siglas en inglés) se producen cuando:

1. El programa comprueba una propiedad de un archivo, haciendo referencia a este por el nombre.

2. A continuación el programa realiza una operación de sistema del archivo utilizando el mismo nombre de archivo y asume que la propiedad que ya se comprobó anteriormente no ha cambiado.
Ejemplo 1: El siguiente código procede de un programa instalado setuid root. El programa realiza ciertas operaciones de archivo en nombre de usuarios no privilegiados, y usa comprobaciones de acceso para asegurar que este no usa sus privilegios origen para realizar operaciones que no deberían estar disponibles para el usuario actual. El programa utiliza la llamada al sistema access() para comprobar si la persona que está ejecutando el programa tiene permiso para acceder al archivo especificado antes de que abra el archivo y realiza las operaciones necesarias.


if (!access(file,W_OK)) {
f = fopen(file,"w+");
operate(f);
...
}
else {
fprintf(stderr,"Unable to open file %s.\n",file);
}


La llamada a access() presenta el comportamiento previsto y devuelve 0 si el usuario que ejecuta el programa dispone de los permisos necesarios para escribir en el archivo y, de no ser así, devuelve -1. Sin embargo, debido a que tanto access() como fopen() realizan operaciones en los nombres de archivo en lugar de en los identificadores de archivo, no hay ninguna garantía de que la variable file aún haga referencia al mismo archivo en el disco al transferirlo a fopen() que cuando se transfirió a access(). Si un usuario malintencionado sustituye file tras la llamada a access() por un vínculo simbólico a un archivo diferente, el programa utilizará sus privilegios raíz para realizar operaciones en el archivo, aunque se trate de un archivo que, de lo contrario, el usuario no podría modificar. Al engañar al programa para que realice una operación que, de lo contrario, no sería permisible, el usuario malintencionado ha obtenido privilegios elevados.

Este tipo de vulnerabilidad no se limita a programas con privilegios root. Si la aplicación es capaz de realizar cualquier operación que el usuario malintencionado no tendría permiso para realizar, se trata de un posible objetivo.

La ventana de vulnerabilidad para un ataque de esta naturaleza se da en el período de tiempo entre cuando una propiedad de archivo se comprueba y cuando el archivo se usa. Incluso si el uso se produce inmediatamente después de la comprobación, los sistemas de operación modernos no garantizan la cantidad de código que se ejecuta antes de que el proceso abandona la CPU. Los atacantes disponen de una amplia variedad de técnicas para expandir la longitud de la ventana de oportunidad para que sea más fácil de explotar. Sin embargo, incluso con una ventana pequeña, un intento de ataque puede repetirse una y otra vez hasta que tiene éxito.

Ejemplo 2: el siguiente código crea un archivo y, a continuación, cambia el propietario del mismo.


fd = creat(FILE, 0644); /* Create file */
if (fd == -1)
return;
if (chown(FILE, UID, -1) < 0) { /* Change file owner */
...
}


Este código presupone que el archivo utilizado por la llamada a chown() es el mismo que el archivo creado por la llamada a creat(), pero esto no siempre es así. Como chown() funciona en un nombre de archivo y no en un identificador de archivo, un atacante podría ser capaz de reemplazar el archivo con un vínculo a un archivo que no posee el atacante. La llamada a chown() proporcionaría así al atacante la propiedad del archivo vinculado.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 362, CWE ID 367
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [22] CWE ID 362
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [21] CWE ID 362
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000366, CCI-003178
[12] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-5 Access Restrictions for Change (P1), CM-6 Configuration Settings (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-5 Access Restrictions for Change, CM-6 Configuration Settings
[16] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.11.2 Business Logic Architectural Requirements (L2 L3), 1.11.3 Business Logic Architectural Requirements (L3), 11.1.6 Business Logic Security Requirements (L2 L3)
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.3 - Terminal Software Attack Mitigation
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.3 - Terminal Software Attack Mitigation
[26] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 362
[27] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 362
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3630.1 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3630.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3630.1 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3630.1 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3630.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3630.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3630.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001995 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001995 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001995 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001995 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001995 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001995 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001995 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001995 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001995 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001995 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001995 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001995 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001995 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001410 CAT II, APSC-DV-001995 CAT II
desc.controlflow.cpp.file_access_race_condition
Abstract
La ventana de tiempo entre cuando una propiedad de archivo se comprueba y cuando el archivo se usa se puede aprovechar para lanzar un ataque de escalada de privilegios.
Explanation
Las condiciones de carrera de acceso al archivo, conocidas como condiciones de carrera de tiempo de comprobación y tiempo de uso (TOCTOU) se dan cuando:

1. El programa comprueba una propiedad en un archivo, referenciando el archivo por su nombre.

2. A continuación el programa realiza una operación de sistema del archivo utilizando el mismo nombre de archivo y asume que la propiedad que ya se comprobó anteriormente no ha cambiado.
Ejemplo: El siguiente programa llama la rutina de CBL_CHECK_FILE_EXIST para comprobar si el archivo existe antes de crear uno y lleva a cabo las operaciones necesarias.


CALL "CBL_CHECK_FILE_EXIST" USING
filename
file-details
RETURNING status-code
END-CALL

IF status-code NOT = 0
MOVE 3 to access-mode
MOVE 0 to deny-mode
MOVE 0 to device

CALL "CBL_CREATE_FILE" USING
filename
access-mode
deny-mode
device
file-handle
RETURNING status-code
END-CALL
END-IF


La llamada a CBL_CHECK_FILE_EXIST se comporta tal y como se esperaba y devuelve un valor distinto de cero, que indica que el archivo no existe. Sin embargo, dado que tanto CBL_CHECK_FILE_EXIST como CBL_CREATE_FILE operan sobre los nombres de los archivos y no sobre los identificadores, no hay garantía de que la variable filename todavía se refiera al mismo archivo en el disco cuando se pase a CBL_CREATE_FILE que era cuando se pasó a CBL_CHECK_FILE_EXIST. Si un atacante crea un filename después de la llamada a CBL_CHECK_FILE_EXIST, la llamada a CBL_CREATE_FILE fallará, lo que llevará al programa a creer que el archivo está vacío, cuando de hecho este contiene datos controlados por el atacante.

La ventana de vulnerabilidad para un ataque de esta naturaleza se da en el período de tiempo entre cuando una propiedad de archivo se comprueba y cuando el archivo se usa. Incluso si el uso se produce inmediatamente después de la comprobación, los sistemas de operación modernos no garantizan la cantidad de código que se ejecuta antes de que el proceso abandona la CPU. Los atacantes disponen de una amplia variedad de técnicas para expandir la longitud de la ventana de oportunidad para que sea más fácil de explotar. Sin embargo, incluso con una ventana pequeña, un intento de ataque puede repetirse una y otra vez hasta que tiene éxito.

Además, este tipo de vulnerabilidad se puede aplicar a un programa con privilegios de root que realiza ciertas operaciones de archivo en nombre de usuarios no privilegiados, y usa comprobaciones de acceso para asegurar que este no usa sus privilegios origen para realizar operaciones que no deberían estar disponibles para el usuario actual. Engañando al programa para que realice una operación que no sería permisible de otro modo, el atacante puede ganar ciertos privilegios superiores.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 362, CWE ID 367
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [22] CWE ID 362
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [21] CWE ID 362
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000366, CCI-003178
[12] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-5 Access Restrictions for Change (P1), CM-6 Configuration Settings (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-5 Access Restrictions for Change, CM-6 Configuration Settings
[16] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.11.2 Business Logic Architectural Requirements (L2 L3), 1.11.3 Business Logic Architectural Requirements (L3), 11.1.6 Business Logic Security Requirements (L2 L3)
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.3 - Terminal Software Attack Mitigation
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.3 - Terminal Software Attack Mitigation
[26] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 362
[27] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 362
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3630.1 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3630.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3630.1 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3630.1 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3630.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3630.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3630.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001995 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001995 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001995 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001995 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001995 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001995 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001995 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001995 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001995 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001995 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001995 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001995 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001995 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001410 CAT II, APSC-DV-001995 CAT II
desc.controlflow.cobol.file_access_race_condition