Hardening Request Optional bounds-validation for Slice kernel when processing untrusted models

Abierto
  • ¿Algo no está bien?
#3,984 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
Medio día
Aptitud para principiantes
15/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
cpp
Área
machine-learning, security

Línea de trabajo

The check belongs in the Slice kernel, reference_ops::Slice, where begin and size are read from the model and multiplied against the input dimensions. The proposed TFLM_STRICT_MODEL_VALIDATION macro and TF_LITE_ENSURE_MSG checks are only a sketch, and the exploit PoC is withheld, so you cannot reproduce the crash from the issue alone. Done means a maintainer-agreed approach to the bounds check, not a patch from a first-time contributor. Coordinate with #3960, which edits the same SLICE and STRIDED_SLICE kernels.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary

This issue proposes an opt-in bounds-validation macro (TFLM_STRICT_MODEL_VALIDATION) for the Slice kernel to support deployments that process .tflite models from untrusted sources (e.g., OTA updates, third-party marketplaces).

Currently, a lack of bounds checking allows a malformed model to achieve arbitrary code execution. This proposal provides a compile-time enforcement mechanism that secures the runtime without impacting the default footprint for trusted environments.

The Finding

In reference_ops::Slice, the begin and size parameters are read directly from the model without runtime validation. A crafted model setting size=15952 on a 64-byte tensor triggers an Out-of-Bounds (OOB) write into the tensor arena.

Because the arithmetic product of the dimensions is not bounded against the allocated arena size, the subsequent memory write overflows the logical tensor boundary. This OOB write can be leveraged to overwrite the NodeAndRegistration dispatch pointer, resulting in a full control-flow hijack. This has been empirically verified to achieve Remote Code Execution (RCE) on two architectures:

  • x86-64: Full RCE bypassing ASLR (utilizing an OOB read primitive present in the same bug).
  • Xtensa (ESP32): Bare-metal dispatch pointer hijack verified in QEMU.
The Proposal

To address this without violating TFLM's strict memory constraints, the validation check can be wrapped in a preprocessor macro (TFLM_STRICT_MODEL_VALIDATION).

When enabled, it safely catches malformed models and halts execution. When disabled (default), TFLM behavior and binary size remain completely unchanged, preserving the zero-overhead requirement for trusted environments.

Draft Implementation (with Integer Overflow Protection):

#ifdef TFLM_STRICT_MODEL_VALIDATION
  // Validate bounds to prevent OOB write/read from untrusted models
  for (int i = 0; i < begin->dims->data[0]; ++i) {
    int32_t b = (begin->type == kTfLiteInt32) ? begin->data.i32[i] : static_cast<int32_t>(begin->data.i64[i]);
    int32_t s = (size->type == kTfLiteInt32) ? size->data.i32[i] : static_cast<int32_t>(size->data.i64[i]);
    
    if (i < input->dims->size) {
      TF_LITE_ENSURE_MSG(context, b >= 0, "Slice begin must be >= 0");
      TF_LITE_ENSURE_MSG(context, s >= 0, "Slice size must be >= 0");
      
      // Cast to int64_t to prevent signed 32-bit integer overflow bypass
      int64_t end = static_cast<int64_t>(b) + static_cast<int64_t>(s);
      TF_LITE_ENSURE_MSG(context, end <= input->dims->data[i], "Slice begin+size exceeds dimension");
    }
  }
#endif // TFLM_STRICT_MODEL_VALIDATION

Demonstration of Impact (Not Speculative)
To clarify that this is not an automated fuzzer report or a theoretical concern, I built a clean victim application (victim_app.cc, ~50 lines of standard C++). It contains zero exploit logic. It simply loads a .tflite model from disk (simulating an OTA update), allocates the tensors, copies the input frame, and calls Invoke().

When fed a benign model, it runs normally:

[*] Processing frame...
[-] Inference completed safely.

When fed a 596-byte crafted .tflite model (where size=15952), the unchecked begin/size parameters overwrite the NodeAndRegistration dispatch pointer, leading to an arbitrary control-flow hijack. The hijacked pointer executes the standard system("id") command, proving full Remote Code Execution:

[*] Processing frame...
>>> VICTIM SYSTEM COMPROMISED <<<
uid=1000(grats) gid=1000(grats) groups=1000(grats),4(adm),24(cdrom)...
Exit code: 42

When the TFLM_STRICT_MODEL_VALIDATION macro (detailed above) is compiled into the exact same library, the identical malicious model is safely caught before the OOB write can occur:

E (1520) main_task: Node SLICE (number 0) failed to invoke with status 1
E (1520) main_task: Slice begin+size exceeds dimension

(Note: I initially referenced #3960, but I see that issue is specifically focused on functional bugs with dynamic/non-constant tensors in Keras LSTM/GRU. However, since that issue is modifying the exact same SLICE and STRIDED_SLICE kernels to add output tensor checks, I would like to highlight that the lack of value validation is also a critical security boundary issue. If the team is already touching this code for #3960, I would strongly recommend adding the strict runtime TF_LITE_ENSURE bounds checks I proposed above.)

In accordance with responsible disclosure, I am withholding the weaponized .tflite payload and the victim_app.cc source from this public issue tracker. I am happy to provide the full PoC exploit, GDB logs, and the malicious model privately to assist the maintainers with testing.

Lenguaje dominante
C++
Estrellas
3.1k
Forks
1.1k
Merge medio
1 d 48 min
PR fusionados (30 d)
83

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de tensorflow/tflite-micro

Todos los issues de tensorflow/tflite-micro

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.