# Referencia del laboratorio / Lab reference

Referencia escrita para la guía. Las respuestas originales del modelo están en
`model-outputs/`; este archivo no es una respuesta generada.

## Red team — inyección SQL

`cases/code_review.py.txt` contiene dos funciones. La primera inserta `name`
dentro de la cadena SQL. La segunda usa un marcador `?` y una tupla de un valor.

Ejecuta `python3 sql_lab.py`. La entrada `' OR 1=1 -- ` cierra la cadena, añade una
condición siempre verdadera y comenta la comilla final. En la función vulnerable
devuelve los dos clientes de la tabla. En la parametrizada devuelve cero filas.

El programa también verifica que la versión parametrizada encuentra `O'Connor`
y devuelve una lista vacía para un nombre inexistente. La base SQLite es local,
en memoria, con clientes ficticios. No hay aplicación web ni servidor SQL externo.

La prueba demuestra el cambio de significado de esa consulta. No establece la
exposición de una aplicación real, sus permisos, autenticación o autorización.

## Blue team — accesos SSH

- Entre 08:00:01Z y 08:00:31Z hay cuatro fallos de contraseña desde `203.0.113.42`.
  Las cuentas son `admin`, `root` y `backup`; dos fallos corresponden a `backup`.
- A las 08:00:42Z se acepta una contraseña de `backup` desde la misma IP. Un segundo
  después se abre la sesión. El archivo no permite saber si era un acceso legítimo
  o si alguien había adivinado la contraseña.
- A las 08:05:10Z hay un acceso con clave pública a `deploy` desde `192.0.2.10`.
  El archivo no relaciona las dos IP ni demuestra que ese acceso fuera malicioso.
- Para continuar harían falta el registro completo de autenticación, la actividad
  de la sesión y la confirmación de si el acceso de `backup` estaba previsto.
- No hay evidencia de malware, robo de datos, CVE, país o grupo atacante. Las IP
  pertenecen a rangos de documentación.

## Lo que devolvió el modelo

`model-outputs/redteam.md` contiene un programa Python propuesto por el modelo.
Usa una base SQLite en memoria y muestra la diferencia entre la consulta vulnerable
y la parametrizada. La respuesta salió en inglés aunque se pidió español.
La prueba ejecutada para la guía es `sql_lab.py`, un programa separado y revisado.

`model-outputs/logs.md` contiene la cronología y las comprobaciones propuestas para
SSH. Las comprobaciones sugeridas no se realizaron por aparecer en esa respuesta.

También se conserva una revisión adicional en `model-outputs/code.md`, obtenida
en el chat con el prompt del caso `code`. Identifica la interpolación SQL, pero su test inserta una sola
fila, espera una fila después de usar OR y captura cualquier excepción. Ese test
puede pasar tanto con la función vulnerable como con la corregida. No debe usarse
como prueba de la corrección. El laboratorio de dos filas evita ese problema.

## English reference

Run `python3 sql_lab.py`. The supplied injection returns both fictional customers
from the vulnerable lookup (2 rows) and none from the parameterized lookup (0).
The assertions also cover an exact lookup for O'Connor and a missing customer.
The model's red-team answer proposes a demonstration; the separate reviewed lab
provides the executed proof.

For SSH, four failed passwords from 203.0.113.42 precede a successful backup login
and session opening from the same address. This warrants investigation but does
not prove compromise. The deploy public-key login comes from another documentation
address; no link between the two sources is established. The file contains no
post-login activity. Establish whether backup's access was expected and obtain
the full authentication and session records before drawing further conclusions.

The optional code-review output contains an inadequate regression test. It inserts
one row, expects one row after an OR proof and catches all exceptions, so it can
pass against both vulnerable and fixed code. Use the two-row lab for verification.

The live requests used QDivZero's chat. The downloadable Python client was tested
offline against the HTTP contract. These examples do not constitute a model benchmark.


## PHP — revisión y propuesta de parche

El origen son líneas seleccionadas del archivo oficial PHP 8.2.34, con SHA-256
5351330c54de240f54f7527c26ef292e239749e6fe11db0330acb5317e02bb39.
`cases/php82_source.json` enumera los rangos. Las directivas #line conservan las
ubicaciones originales. No se envió el parche independiente ni el artículo al
modelo. El caso `php-counter` añade únicamente el síntoma ya reproducido.

- `Z_TRY_ADDREF(progress->data)` en session.c:2988 conserva una referencia al
  publicar el array. Los fragmentos no demuestran por sí mismos que se libere
  todo el árbol ni la cadena RCE del artículo.
- En session.c:3163, SEPARATE_ARRAY puede duplicar el array raíz. El puntero
  post_bytes_processed sigue en el anterior. La escritura en 3165 no cambia el
  contador de la copia que se publicará después.
- Con cleanup=0, freq=1 y min_freq=0, una petición multipart de 262642 bytes con
  dos archivos y otro campo grande guarda 136576 bytes en el runtime original.
  Los contadores individuales de archivos son 131072 y 31.
- La primera respuesta (`php-first-review.md`) especula sobre fugas de memoria,
  cambia repetidamente de diagnóstico y ofrece un test que no discrimina la
  corrección. Fue rechazada; no se aplicó su propuesta.
- La segunda (`php-counter-review.md`) encuentra el puntero desactualizado. Sus
  afirmaciones sobre un supuesto evento END que no cuenta el campo final no
  están demostradas. La prueba confirma la desincronización tras la copia.
- El diff original de esa segunda respuesta usa posiciones del extracto, tiene
  un recuento de contexto incorrecto y sangría desplazada. El parche descargable
  normaliza formato y ubicaciones, manteniendo las tres líneas de C añadidas.
- La propuesta normalizada se aplicó sin fuzz a la fuente original y se compiló
  únicamente session.so usando el SDK de la misma versión/ABI. Se cargó en el
  runtime original. Dio 262642 con php, php_binary y php_serialize, conservando las
  pruebas de subidas normales, cleanup y cancelación.
- El parche independiente de php-liferaft se verificó en un build separado y dio
  el mismo resultado final. Su diseño elimina los punteros a buckets persistentes;
  la propuesta del modelo refresca solo el contador raíz al final. No equivalen en
  alcance ni establecen cobertura de todos los fallos de vida útil.

`model-outputs/php-regression.json` contiene versiones, parámetros, hashes y los
resultados separados. `php-observations.json` registra las dos peticiones reales.
El informe externo atribuye dos identificadores, pendientes de corroboración al
realizar la prueba. El anuncio oficial programaba la publicación para el 21 de
octubre de 2026 a las 14:00 UTC. No se ha demostrado ejecución remota ni se presenta
la propuesta como parche oficial o solución completa de esas vulnerabilidades.

### English assessment

The first neutral source review was rejected for unsupported memory-leak claims.
The second request received the same original source plus observed counter data,
but no reference patch. It identified the stale root counter after copy-on-write.
Its parser speculation is not established by this test. The normalized diff only
repairs formatting and source locations; its three added C lines are intact.
The session-only module compiled against the matching SDK and passed the final
counter, normal upload, cleanup and cancellation checks in the original runtime.
The separate independent patch removes cached counter pointers more broadly.
These results establish the tested functional correction, not the reported RCE
chain, official identifier attribution or complete vulnerability coverage.