caracteres de escape en / etc / network / interfaces

Quiero estar seguro de que cualquier cadena que se me pase en la línea wpa-ssid "abc"en la /etc/network/interfacesque no se utilizará para salir de la configuración.

Todo lo que puedo encontrar en el manual es que \se puede usar al final de una línea para continuar en la siguiente.

Pero ¿qué pasa \"en el medio de una línea?

Mi preocupación es un SSID algo así como

A"
up rm -rf /\

¿Existe alguna codificación general que pueda usarse para caracteres arbitrarios en el campo SSID?

En Debian /etc/network/interfaces(o cualquier otra distribución que use la utilidad ifupdown de Debian), se elimina una secuencia de barra invertida-nueva línea, y la barra invertida no es especial en ningún otro lugar. Un carácter de comillas dobles tampoco es especial. El carácter #comienza un comentario si es el primer carácter que no es un espacio en blanco en una línea (sin continuación). Los bytes nulos se tratan como caracteres de nueva línea (creo que el analizador utiliza cadenas C y no tiene un manejo especial para los bytes nulos, por lo que podrían causar daños adicionales).

Las líneas de configuración toman la forma de un nombre de opción seguido de un valor, separado por espacios en blanco. Los espacios en blanco iniciales y finales se ignoran. Algunas opciones integradas analizan aún más la línea en palabras; El valor de las opciones ifacesiempre se ejecuta hasta el final de la línea.

Por ejemplo, la linea

wpa-ssid  "a  b"  "cd"  

establece la opción wpa-ssiden la cadena de 12 caracteres "a  b"  "cd"(se conserva el espacio en blanco interno).

El script ifupdown de WPA Supplicant elimina las comillas dobles al principio y al final de la wpa-ssidcadena de configuración, la línea de arriba es equivalente a wpa-ssid a  b"  "cd. De esta manera, puede tener espacios en blanco iniciales y finales en el SSID.

No puedo encontrar un problema de cotización en los scripts ifupdown de WPA Supplicant, por lo que parece que todo lo que producirá ifupdown es seguro.

Por lo tanto, puede permitir que se inyecte cualquier cadena como SSID /etc/network/interfaces, siempre que no contenga ninguna línea nueva o byte nulo. Agregue comillas dobles alrededor de la cadena (si no lo hace, los SSID con espacios en blanco iniciales o finales, o que terminan con \, o que comienzan o terminan con ", serán destrozados).

Este SO Q&A titulado: ¿Existe un estándar que defina qué es un SSID y una contraseña válidos? responde algunas de tus preguntas.

extracto

La Sección 7.3.2.1 de la especificación 802.11-2007 ( http://standards.ieee.org/getieee802/download/802.11-2007.pdf ) define los SSID.

Un SSID válido es de 0 a 32 octetos con contenido arbitrario. Un SSID de longitud 0 indica el SSID comodín (en marcos de solicitud de sonda, por ejemplo).

No hay ningún conjunto de caracteres asociado con el SSID: una cadena de 32 bytes de bytes NUL es un SSID válido.

Esto implica:

• nunca debe usar funciones de cadena normales al manipular SSID genéricos (strcpy () y amigos).
• no debe suponer que el SSID es imprimible cuando, por ejemplo, lo registra en el disco

También hay este comentario sobre la respuesta a la pregunta SO:

Hay una versión actualizada del estándar ( http://standards.ieee.org/getieee802/download/802.11-2012.pdf ), que define el SSIDEncodingcampo. Puede ser UNSPECIFIED(para datos arbitrarios) o UTF8.

Por lo tanto, buscaría el último estándar de orientación y me aseguraría de que pueda lidiar con lo que es legal en base a eso.

¿Qué más?

Además, podría estar inclinado a protegerme a mí mismo al normalizar la entrada de un usuario utilizando alguna forma de función de codificación de URL (algo que obviamente funcionaría con SSID) o simplemente eliminar los caracteres ilegales y simplemente no permitirlos antes de escribir estas cadenas en este archivo .

Personajes raros?

Los únicos problemas que pude encontrar con caracteres extraños / especiales relacionados con el interfacesarchivo fueron estos tipos de errores que se presentaron contra el instalador de Debian.

• debian-installer no puede escapar o citar caracteres especiales en la clave WPA / etc / network / interfaces

debian-installer solicitó mi información de red inalámbrica y la usó con éxito para conectarse de forma inalámbrica a la red. También escribió mi información de red inalámbrica en / etc / network / interfaces. Sin embargo, la clave WPA que ingresé contenía al menos un carácter especial, y debian-installer no escapó ni citó los caracteres especiales en / etc / network / interfaces. El resultado fue que, al reiniciar, el sistema se bloqueó durante mucho tiempo durante el proceso de inicio, ya que intentó (sin éxito) volver a conectarse a la red inalámbrica. Solucioné el problema simplemente citando la clave WPA que figura en / etc / network / interfaces. Esto debería suceder automáticamente si la clave contiene caracteres especiales.

También hubo estos errores, uno relacionado con espacios dentro del SSID, los otros relacionados con la frase de contraseña:

• Los SSID con espacios en blanco se escapan
• La frase de contraseña WPA con espacio escapó cuando no debería
• [Beta 1.1] La configuración de Wifi en xbmc no funciona con espacios en SSID

En cualquier caso, parecería que envolver las cadenas con comillas dobles es suficiente para proteger los valores de ambos.

Ejemplos adicionales

Documentos oficiales

Examinando la documentación oficial encontré este bit aquí:

• WifiDocs / Adhoc - Documentos oficiales de Ubuntu

Los documentos oficiales muestran este ejemplo:

ap_scan=2
network={
        ssid="test adhoc"
        mode=1
        frequency=2412
        proto=WPA
        key_mgmt=WPA-NONE
        pairwise=NONE
        group=TKIP
        psk="passphrase"
}

Por lo tanto, parece que los espacios están permitidos, siempre y cuando se citan correctamente. También hay un ejemplo que explica cómo proporcionar un SSID con espacios para la iwconfigherramienta:

Agregue el nombre (ssid) para la red que desea crear / unirse. Use comillas simples si hay un espacio en el nombre.

   $ sudo iwconfig eth1 essid 'name'

Webconverger

Encontré este ejemplo que parece ser Debian bajo el capó, por lo que el ejemplo puede ser apropiado para su situación, pero es difícil saberlo con certeza. Lo menciono solo porque muestra un ejemplo de cómo hubiera esperado que un método de codificación URI estuviera expuesto para proteger contra caracteres ilegales.

• Wiki de webconverger

extracto

Ejemplo 4 "Espacios en el ESSID", transmitiendo essid 'Hopstock Gjestenett', con clave WPA uiopzxcv

Evite espacios en los ESSID. En este caso, solucionamos un encodeURI ('Hopstock Gjestenett') para obtener la siguiente receta de arranque:

   wpa-ssid=Hopstock%20Gjestenett wpa-psk=uiopzxcv

Por lo tanto, es posible que pueda codificar los espacios que aparecen en SSID mediante %20.

SSID

Profundizando aún más, encontré este comentario en la página de Wikipedia sobre el conjunto de servicios (red 802.11) .

Cada BSS o ESS se identifica mediante un identificador de conjunto de servicios (SSID): una cadena de 1 a 32 bytes. Esto normalmente es una cadena legible por humanos y, por lo tanto, comúnmente se llama "nombre de red". 6 En un IBSS, el dispositivo cliente elige el SSID que inicia la red, y todos los dispositivos que son miembros de la red realizan la transmisión del SSID en un orden pseudoaleatorio.

Este comentario está respaldado por esta presentación de Blackhat EU 2013, titulada: Explotación práctica utilizando un identificador de conjunto de servicios maliciosos (SSID) .

extracto

• No hay restricciones definidas en cuanto a qué caracteres se pueden usar dentro de un SSID (IEEE Std 802.11 ™ -2012)
• Alguna limitación basada en productos
  • Algunas limitaciones de caracteres (solo ascii)
  • Unicode

Por lo tanto, técnicamente se permite cualquier carácter en un SSID, diferentes implementaciones como Windows XP, Windows 7, frente a varias versiones de Linux permiten / deshabilitan subconjuntos de caracteres dentro de los SSID.

Referencias

• ¿Cómo conectarse a una red inalámbrica que tiene un nombre de dos palabras con un espacio? - AskUbuntu