Skip to content
KitploitKITPLOIT
HerramientasExploitsBlog
Log in
Enviar
HerramientasExploitsBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

FeedsContactoPrivacidad© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
ats-cripts-rri-uaf — Apache Traffic Server 10.2.0 - Alta - Remoto - Caída - Cripts From/To URL UAF | Kitploit
Herramientas/GitHubGitHub/abraxas/ats-cripts-rri-uaf
Análisis de VulnerabilidadesExplotaciónSeguridad WebLabs y Práctica
GitHubabraxas/ats-cripts-rri-uaf

ats-cripts-rri-uaf

Apache Traffic Server 10.2.0 - Alta - Remoto - Caída - Cripts From/To URL UAF

Ver Repositorio
hace 14 díasAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

Abraxas Labs - ats-cripts-rri-uaf

abraxaslabs.tech  ·  github.com/abraxas  ·  @abraxas_null  ·  [email protected]  ·  ats-cripts-rri-uaf

ats-cripts-rri-uaf

Clase: Fallo Alcance: Remoto

Apache Traffic Server 10.2.0 (b1df7334) - Apache Software Foundation

Las URL Remap::From / To de Cripts siguen releyendo la pila TSRemapRequestInfo después de que TSRemapDoRemap retorne. RemapPlugins asigna rri en la pila. El contexto conserva el puntero. reset() libera los unique_ptrs; posteriormente Get() / Host::GetSV pasa la RRI muerta a TSUrlHostGet. Fatal: sdk_sanity_check_mbuffer y luego SIGABRT.

Client::URL fue parcheado para no hacerlo. Lua limpiaba rri después del remap. Cripts From/To no lo hacía. ENABLE_CRIPTS está desactivado por defecto. No hay cripts en el remap estándar.

IDaún sin CVE
ClaseFallo (UAF de RRI en pila)
AlcanceRemoto (HTTP no autenticado a través de un cript From/To posterior al remap)
CWECWE-416
CVSSAlto: 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
ProductoApache Traffic Server
Afectado10.2.0 (b1df7334b39a878971c376da849e8da4984918b6) URL From/To de Cripts después de DoRemap
Autenticaciónninguna
LicenciaGNU Affero GPL v3.0
Laboratoriosolo 127.0.0.1:18780

Fijé la etiqueta pública 10.2.0 peel b1df7334. El laboratorio es una compilación desde código fuente RelWithDebInfo con Cripts activado. CONTROL Client::URL 200, el proceso siguió en ejecución. POC Host ats-poc SIGABRT salida 134.

Qué puede hacer un atacante

Alcanzar un cript de remap que toque la URL From/To después de do_remap (do_send_response en el laboratorio). Un GET no autenticado es suficiente.

MétodoSumideroPrivilegio
GET no autenticado Host ats-poc a través de un cript do_send_response que llama a Remap::From::URL::Get / To::URL::Getpila TSRemapRequestInfo (RemapPlugins.cc:41-65); desreferencia de rriValid() (Context.hpp:70-73); _initialize (Urls.cc:525-561)Disponibilidad (probado en laboratorio): SIGABRT, salida 134, conexión reiniciada. traffic_server muere.
IgualAborto Fatal del SDKIntegridad: no es control de RIP. La clase sigue siendo Fallo. Laboratorio.

Probado en laboratorio vs inferido: la muerte del proceso está probada en laboratorio (RelWithDebInfo SIGABRT). No se afirma corrupción de memoria hasta RIP.

Requiere: Cripts compilado (ENABLE_CRIPTS=ON) y un cript de remap que toque la URL From/To después de DoRemap. Por defecto: no.

Superficie adyacente que permanece cerrada

SuperficieLaboratorio
CONTROL solo Client::URL200, el proceso siguió en ejecución
Jaula File::Path::Rebasecerrada en esta fijación (CVE-2026-58177 issue 32)
sockaddr de Geo IPEndpointcerrada
Aborto por clave de consultacerrada (hash faltante omitido)
Cripts globalesrri == nullptr; rriValid() falla de forma segura sin desreferencia
OOB de instancia / DoRemap después de Releasecerrada (CVE-2026-58177)
Remap estándar / ENABLE_CRIPTS desactivadoel remanente no aplica

No es CVE-2026-58177 tal como se divulgó. Lua limpiaba rri después del remap; Cripts From/To no lo hacía.

Laboratorio

python3 ats-cripts-rri-uaf-Abraxas-Labs.py

o

cd lab
./run.sh

Loopback 127.0.0.1:18780. Proyecto de Compose ats-cripts-rri-uaf. Imagen RelWithDebInfo. Testigo ATS-CRIPTS-RRI-UAF-WITNESS. Última línea:

SUCCESS ats-cripts-rri-uaf control-http=200 control-alive=yes poc-crash=sigabrt poc-http=None reset=1 ATS-CRIPTS-RRI-UAF-WITNESS

La solución

Anular el rri del Context cuando TSRemapDoRemap retorna, tal como lo hace Lua. O tratar la URL From/To como Client::URL: no reinicializar desde RRI en hooks posteriores. rriValid() no debe desreferenciar una estructura muerta. Copiar mapFromUrl / mapToUrl en MLocs propios durante do_remap si From/To posterior al remapeo es una funcionalidad.

Hasta entonces, no evaluar %{FROM-URL:...} / %{TO-URL:...} (ni tomar prestados esos objetos URL) en do_post_remap / do_send_request / do_read_response / do_send_response / do_cache_lookup.

Referencias

  • github.com/apache/trafficserver etiqueta 10.2.0 (b1df7334b39a878971c376da849e8da4984918b6)
  • src/proxy/http/remap/RemapPlugins.cc
  • include/cripts/Epilogue.hpp
  • src/cripts/Urls.cc Remap::From::URL / To::URL
  • include/cripts/Context.hpp rriValid
  • Hermanos de CVE-2026-58177 (cerrados): OOB de instancia, Rebase ../, Geo sockaddr, aborto de query-key, Client::URL MLoc
  • CWE-416
Descargar herramienta