Root shell en la Samsung TV: qué tiene que ver con Bun

Anda circulando una captura de una terminal con # en el prompt, y el aparato del otro lado es una televisión. El post original muestra un root shell en la Samsung TV. Es decir, acceso total al sistema operativo de la TV de la sala. No es la app de Netflix ni el menú de configuración. Es el Linux que está debajo de todo eso, con permiso para tocar cualquier cosa.

Apenas lo vi, pensé dos cosas. La primera fue: "esto es un problema de seguridad gigante". La segunda, como todo dev JavaScript con problemas: "¿correrá Bun?"

Voy a hablar de las dos.

Qué significa tener root shell en la Samsung TV

Las TVs de Samsung usan Tizen, un sistema basado en Linux. Encima va la interfaz que conoces, la tienda de apps y los servicios de la propia Samsung. Debajo hay kernel, procesos, sistema de archivos y red, como en cualquier servidor.

Un shell común ya permite ejecutar comandos. Un shell root permite ejecutar cualquier comando, como el usuario con más poder del sistema. En la práctica, quien tiene ese acceso puede:

• leer y modificar archivos del sistema, incluso los que el fabricante protege;
• ver lo que pasa por la red de la TV;
• instalar y ejecutar binarios que nunca pasaron por la tienda oficial;
• dejar un proceso corriendo en segundo plano para siempre.

No voy a entrar en cómo se obtuvo el acceso. Primero, porque el detalle técnico es del autor y quien quiera debe leerlo en la fuente. Segundo, porque un paso a paso de exploit no es lo que hace este blog. Lo que me interesa es lo que esto muestra a quien escribe software.

Por qué importa si no eres investigador de seguridad

Probablemente no vas a hacer jailbreak a tu TV esta noche. Aun así, esta noticia tiene que ver con tu trabajo.

Una smart TV es una computadora Linux encendida 24 horas al día. Está conectada a tu red doméstica, tiene micrófono en algunos modelos y sus actualizaciones dependen de una empresa que dejará de darle soporte dentro de unos años. Ahora piensa en cuántos de estos hay en la misma red que tu laptop de trabajo.

Todo dispositivo "inteligente" es un servidor Linux que tú no administras.

Esa es la parte que incomoda. En tu servidor controlas la versión del kernel, los puertos abiertos y los paquetes instalados. En la TV no controlas nada. Confías en que el fabricante lo hizo bien y lo seguirá haciendo. Cuando aparece un root shell público, esa confianza recibe un golpe.

Para quien desarrolla, quedan tres lecciones:

1. La red local no es zona segura. Si tu API de desarrollo escucha en 0.0.0.0 sin autenticación "porque es solo mi red", cualquier aparato comprometido en esa red puede llamarla.
2. El firmware viejo es deuda técnica de otra persona que te cae encima. Lo mismo vale para la imagen Docker que no actualizas desde 2023.
3. La actualización automática es una función de seguridad. Odiar el update que reinicia la TV es normal. Desactivarlo es peor.

El primer punto es el más fácil de corregir hoy. En Bun, por ejemplo:

Bun.serve({
  hostname: "127.0.0.1", // solo tu máquina lo ve
  port: 3000,
  fetch: () => new Response("ok"),
});

Una línea cambia quién puede hablar con tu servidor.

Y dónde entra Bun en esta historia

Ahora la parte divertida. Imagina que la TV es tuya, el acceso es tuyo y quieres correr tu propio código en ella. Un dashboard de la casa, un bot que apaga la TV pasada la medianoche, un servidor que expone métricas. Lo que sea.

El camino clásico sería compilar C para la arquitectura de la TV. Funciona, pero da trabajo: toolchain cruzada, librerías, enlazado. Para quien vive de TypeScript, Bun ofrece un atajo muy interesante: bun build --compile.

Este comando toma tu código, lo junta con el runtime de Bun y genera un único ejecutable. Sin node_modules, sin instalar nada en el destino. Y puedes generar ese binario para otra arquitectura directo desde tu laptop:

bun build ./tv.ts --compile --target=bun-linux-arm64 --outfile tv-server

Después solo copias el archivo y lo ejecutas. Nada de npm install en un aparato con poco espacio y sin gestor de paquetes.

El tv.ts puede ser bien simple:

import { cpus, freemem, uptime } from "node:os";

Bun.serve({
  hostname: "127.0.0.1",
  port: 8080,
  fetch() {
    return Response.json({
      cpus: cpus().length,
      freeMB: Math.round(freemem() / 1024 / 1024),
      uptimeH: Math.round(uptime() / 3600),
    });
  },
});

Como Bun implementa buena parte de las APIs de Node, los módulos node:os, node:fs y node:child_process funcionan como esperas. Escribes el mismo TypeScript de siempre y lo corres en un aparato que, hace diez minutos, era solo una pantalla.

Los límites reales (antes de que lo intentes)

Aquí viene la parte honesta, porque la captura bonita esconde los detalles aburridos.

Arquitectura. Bun genera binarios para Linux x64 y arm64, con variantes para glibc y musl. No tiene soporte oficial para ARM de 32 bits. Muchas TVs tienen procesador ARM de 64 bits pero corren el sistema en 32 bits, y ahí el binario simplemente no se ejecuta. Antes de nada, corre esto en el shell de la TV:

uname -m

Si aparece aarch64, hay posibilidades. Si aparece armv7l, olvídate de Bun y ve por C, Go o Rust.

Tamaño. Un ejecutable compilado con Bun pasa fácilmente de 50 MB, porque el runtime entero va dentro. En tu SSD eso no es nada. En una TV con almacenamiento interno justo y particiones de solo lectura, puede ser el fin del camino. Un binario en Go haría el mismo trabajo con una fracción de eso.

Memoria. JavaScriptCore es eficiente, pero no es magia. La TV ya usa buena parte de la RAM para decodificar video. Tu pequeño servidor va a pelear memoria con el reproductor, y el sistema puede matar el proceso cuando apriete.

Persistencia. El root shell no garantiza que tu proceso sobreviva a un reinicio o a una actualización. Muchas veces la siguiente actualización de firmware cierra la falla y borra lo que instalaste. O sea, el acceso dura hasta que Samsung saque un parche.

Mi opinión fuerte aquí: Bun en una TV es un gran experimento y una pésima arquitectura. Para hackear el fin de semana, la velocidad para pasar de "tengo una idea" a "ya está corriendo" es imbatible. Para algo que tiene que mantenerse en pie durante meses en un dispositivo limitado, lo correcto es un lenguaje que genere un binario pequeño y nativo.

Qué hacer si te dio curiosidad

Si la noticia te dio ganas de meter mano, algunas reglas simples:

• Solo en tu aparato. Acceder al dispositivo de otra persona sin autorización es delito, no investigación.
• Espera a que termine la garantía, o acepta perderla. El root suele anular la garantía, y el fabricante no va a tener piedad.
• Nunca expongas a internet lo que corras. Una TV con root y un puerto abierto hacia afuera se vuelve el aparato más fácil de invadir de tu casa.
• Lee la fuente original y sigue si Samsung responde con un parche. Este tipo de hallazgo normalmente sigue un ciclo: divulgación, corrección y después los detalles técnicos completos.

Si no quieres tocar nada, la acción útil es otra: revisa si tu TV tiene activada la actualización automática. Es aburrido, pero es la única defensa que tienes en un aparato que no administras.

Mi lectura

Lo que más me llama la atención de esta historia es cómo desapareció la distancia entre "electrodoméstico" y "servidor". Tu TV, tu refrigerador y tu router usan la misma base de software que los servidores donde haces deploy. Y el mismo TypeScript que escribes para una API puede, con un comando, volverse un ejecutable dentro de uno de ellos.

Eso es poderoso y aterrador en la misma medida. Para quien desarrolla, la lección práctica es tratar la red local con la misma desconfianza que internet. Y recordar que herramientas como Bun hicieron muy fácil llevar código a lugares donde antes solo entraba C. Úsalo para construir cosas geniales en el hardware que es tuyo.

Ya tengo una TV vieja guardada esperando un fin de semana libre. Si se vuelve proyecto, va a aparecer junto con los demás.

Vi un root shell corriendo en una Samsung TV y mi primera reacción fue: ¿correrá Bun?

La segunda fue más seria. Toda smart TV es un servidor Linux encendido 24 horas en tu red, y quien lo administra no eres tú.

Por eso tu API de desarrollo escuchando en 0.0.0.0 "porque es solo la red de casa" es un riesgo real. Una línea con hostname 127.0.0.1 ya lo resuelve.

Y sí, se puede llevar TypeScript hasta ahí con bun build --compile. Funciona bien como experimento de fin de semana, pero como arquitectura es pésimo: binario de 50 MB, RAM peleada con el reproductor de video y nada de ARM de 32 bits.

Escribí sobre los límites reales y lo que esta historia enseña a quien desarrolla. El enlace está en los comentarios.

#Bun #TypeScript #SeguridadInformática #IoT #Linux