Design: Explica la seguridad

¡Hola!

Tengo una pregunta: ¿Tendría sentido desarrollar lo siguiente en este contexto?

"Aparte de eso, los programas que invocan un comportamiento indefinido en el nivel del idioma de origen pueden compilarse en programas WebAssembly que hacen cualquier otra cosa, como corromper el contenido del montón de aplicaciones, llamar a las API con parámetros arbitrarios, colgar, interceptar o consumir cantidades arbitrarias de recursos (dentro de los límites) ".
https://github.com/WebAssembly/design/blob/master/CAndC++.md#undefined-and-implementation-defined-behavior

En lo que estoy pensando es en proporcionar contexto / referencias que pueden ser (quizás) útiles para los desarrolladores web que provienen de entornos no nativos, proporcionando ejemplos y más discusiones.

Por ejemplo, MSC14-C de CERT No introduzca dependencias de plataforma innecesarias enumera cuatro tipos diferentes de comportamiento no portátil (comportamiento no especificado, comportamiento no definido, comportamiento específico de la configuración regional, comportamiento definido por la implementación) con ejemplos. MSC15-CPP. comportamiento indefinidos a vulnerabilidades Los compiladores de C pueden descartar silenciosamente algunas comprobaciones envolventes , que pueden ser particularmente notables en este contexto (Robert Seacord analiza esto con más detalle en "Eliminación silenciosa de comprobaciones de límites" ).

Tratamientos más profundos:

• Lo que todo programador de C debe saber sobre el comportamiento indefinido # 1/3
• Lo que todo programador de C debe saber sobre el comportamiento indefinido # 2/3
• Lo que todo programador de C debe saber sobre el comportamiento indefinido # 3/3
• Una guía para el comportamiento indefinido en C y C ++, Parte 1
• Una guía para el comportamiento indefinido en C y C ++, Parte 2
• Una guía para el comportamiento indefinido en C y C ++, Parte 3

Otros consejos potencialmente relevantes:

• INT02-CPP.
• INT08-CPP.
• INT10-CPP.
• INT18-C.
• INT32-C.

¿Sería útil tener un encabezado CSP único para controlar los archivos wasm? Siento que los propietarios del sitio pueden querer evitar que los sub-recursos carguen wasm.

Esa es una pregunta interesante. Definitivamente, deberíamos permitir que los sitios no permitan la carga dinámica y la evaluación de WebAssembly en los mismos casos en que no permiten eval y Function (esto simplemente saldría de la integración del módulo ES6 y las verificaciones de CSP en el Loader ruta). Más allá de eso, sin embargo, dado que WebAssembly será equivalente en capacidad a JS, no creo que sea necesario distinguir los dos.

Vale la pena señalar el n. ° 53 para analizar algunas de las preocupaciones de seguridad con los enlaces dinámicos.

@jfbastien yup CORS y SRI deberían estar disponibles para los desarrolladores siempre que sea posible.

@lukewagner Supongo que depende del acceso de bajo nivel al recurso que permitirá wasm. Como dices desde el primer momento, es solo JS. Sin embargo, parece que el objetivo general del wasm es lo más parecido posible a las máquinas de metal; Sería bueno tener una directiva de CSP para controlar globalmente.
Con el tiempo, también sería mejor un enfoque más detallado de las otras funciones.

Las otras posibilidades inmediatas son utilizar la API de permisos para otros accesos de bajo nivel.

Bueno, cerca del metal en el sentido de la interpretación. Desde la perspectiva de la seguridad, los permisos y la zona de pruebas, no se discute que WebAssembly difiera de JS.

Ese no fue el sentimiento que tuve de los anuncios posteriores al MVP y de Brendan Eichs, pero está bien: +1:

Creo que a lo que te refieres es que hemos acordado que, después de MVP, se permitiría que la semántica de WebAssembly difiera de lo que se podría polrelleno eficientemente en JS. Esta divergencia estaría en torno a características computacionales, no nada que ver con seguridad / permisos. Eso significa que, si bien no se pudieron polrellenar _eficientemente_, un intérprete de WebAssembly escrito en JS ( estilo Emterpreter ) podría simular nuevas características

Sí, eso sería una buena mejora del documento, sin duda, podría haber leído el documento demasiado rápido, pero no parecía dejarlo en claro.

Creo que fue una de las charlas de Eich sobre agregar más funciones de subprocesamiento y memoria lo que me hizo pensar que wasm obtendría nuevas funciones. Sospecho que es probable que también se agreguen a JavaScript y que estén sujetos al escrutinio habitual de las nuevas funciones.

"No es diferente del punto de vista de seguridad que JS" ahora está en Web.md.

Prefiero explicar mejor la distinción. Hacer referencia a JS no es muy agradable desde una perspectiva independiente, y creo que en realidad queremos reducir el área de superficie de seguridad que tiene JS (digamos, scripts de origen cruzado y demás).

Llegaré a esto, ahora que he dado una charla al respecto en CppCon :-)

Para aquellos que puedan estar interesados ​​en usar WebAssembly como un objetivo para implementaciones criptográficas, sería útil profundizar en las diferencias entre JS / asm.js JIT y WebAssembly JIT en términos de soporte para implementaciones de tiempo fijo. Estoy pensando específicamente en operaciones como cambios de bits, ramas introducidas post-JIT, saltos condicionales o búsquedas, u otros cambios que el JIT puede hacer que podrían introducir fugas de tiempo.

Si los desarrolladores no deben tener expectativas de WebAssembly para soportar mejor las implementaciones de tiempo fijo que las que ya tenemos con asm.js, entonces afirmar que sería útil como parte de la elaboración de las implicaciones de seguridad de WebAssembly para el diseño de aplicaciones. Si WebAssembly proporcionará algunos medios para fortalecer mejor las aplicaciones en comparación con lo que existe actualmente (ahora o después de MVP, no he leído la especificación en profundidad), también sería genial profundizar en eso. https://github.com/jedisct1/libsodium.js/issues/24#issuecomment -128002942 tiene más información sobre los problemas existentes en torno a la criptografía JavaScript del lado del cliente.

Todo esto es muy emocionante, por cierto. :D

Estuve de acuerdo en que deberíamos tener una declaración aclaratoria como lo sugirió @dconnolly. A partir de ahora, las discusiones que hemos tenido fueron que para MVP no habría garantías sobre lo que el JIT puede / no puede hacer, y que los algoritmos de tiempo constante no son el uso correcto de wasm al menos para MVP. Esto puede cambiar en el futuro.

Mi opinión actual es que las API externas (como las que ofrece el embebedor, como la plataforma web) están mejor posicionadas para ofrecer tales garantías porque a menudo se necesita ensamblaje y una buena comprensión de la microarquitectura para escribir código de tiempo constante adecuado. Considere el ejemplo extremo de una CPU que realiza una traducción binaria dinámica: WebAssembly no puede garantizar lo que una CPU puede / no puede hacer. Mi opinión es que WebAssembly tiene un nivel de abstracción demasiado alto para expresar un verdadero código de tiempo constante.

Genial, gracias por la aclaración. Estuvo de acuerdo en que las API de la plataforma web son el mejor lugar para este tipo de cosas, especialmente las primitivas ( WebCrypto es / apoyará lo esencial, con espacio para futuras adiciones como nuevas curvas elípticas a través de notas ). Esperando ese lenguaje adicional sobre seguridad, ayudará a cualquier otro que pueda malinterpretar las implicaciones de WebAssembly. : +1:

@jfbastien , ¿todo lo que dijo sobre las garantías de tiempo de wasm todavía se aplica hoy?

Veo en los documentos actuales que la ejecución determinista es un objetivo, excepto en una pequeña lista de casos límite documentados, que suena potencialmente positivo para los algoritmos de tiempo constante. Sin embargo, webassembly.org/docs/security reconoce que los ataques de tiempo son posibles y enumera algunas posibles mitigaciones futuras, pero no está claro si la implicación es que "su código C defectuoso no se arreglará mágicamente ... sin embargo, "o" pueden introducirse vulnerabilidades de canal lateral que no ocurrirían con un compilador de C típico ".

Dejando a un lado las garantías, sería útil al menos tener una idea de dónde nos encontramos entre "los algoritmos de tiempo constante definitivamente se arruinarán al 100%" y "no hay ninguna razón obvia para no esperar siempre características de tiempo comparables a la salida binaria nativa de clang". Para el punto de @dconnolly , algún lenguaje que compare específicamente esto con asm.js también sería realmente útil, particularmente teniendo en cuenta tanto implementaciones como la de Firefox que respetan completamente las declaraciones 'use asm' y aquellas como Chrome que lo juegan un poco más suelto .

El resultado determinista de

En este momento, WebAssembly no intenta garantizar nada con respecto a las fugas de información.

Entendido, gracias por aclarar la sección sobre determinismo @jfbastien.

En cuanto a la sincronización / canales laterales (e ignorando las garantías o la falta de ellas), parece que no hay nada relevante en la especificación al respecto en este momento y aún no hay datos útiles sobre cómo se comparan las implementaciones reales con el clang. A lo que realmente me refería, después de leer su comentario anterior, es si hay una razón inherente para que las implementaciones de wasm sean necesariamente peores que gcc / clang en esta área. Habías mencionado el nivel de abstracción como una preocupación, pero no estaba claro qué estabas usando como comparación de referencia para una sincronización constante "suficientemente buena" (C nativo, ensamblaje, hardware, etc.).

En otras palabras, dada la opción entre ejecutar código sensible a infoleak en clang y una implementación hipotética mejor / más madura / más endurecida posible de la especificación de WebAssembly actual, ¿seguiría siendo obviamente preferible la primera en función de su comprensión?

En este momento, no confiaría ni en clang ni en WebAssembly para el código que es sensible a las fugas de información. La única forma que conozco actualmente de obtener las garantías que desearía es escribiendo un ensamblaje que lea el manual de la CPU específica a la que me dirijo, y con una estrecha colaboración del kernel. Saber "x86" o "ARM 64" ni siquiera es suficiente si realmente quiere ser independiente del tiempo.

Puede obtener algunas garantías con algunos compiladores / lenguajes, pero si un infoleak es todo lo que se necesita para vencer su código, entonces "algunos" no es una garantía suficiente.

Perfecto, gracias, creo que responde a mi pregunta. Acordó todos los puntos sobre el modelado general de amenazas de fuga de información; Solo quería tener una idea de si wasm debería considerarse más con fugas que cualquier otro objetivo de compilación de C (sin asm), y parece que estás diciendo que no es necesariamente el caso.

No creo que "más filtraciones" sea una medida útil. La métrica es "¿tiene alguna fuga?" La respuesta para WebAssembly, clang, C ++ y C, es "sí".

Bueno, específicamente, lo que tenía en mente eran algoritmos diseñados para lograr ciertas propiedades de resistencia del canal lateral con implementaciones de C puro, como el ejemplo de libsodium / NaCl vinculado por @dconnolly. Ciertamente es ideal si algo sobrevivirá a cada escenario de ataque posible, pero también es útil conocer el delta entre dos cosas (incluso si ambas apestan, en cierta medida de succión) y, en este caso, si se usa WebAssembly en lugar de una ABI de Linux como es probable que un objetivo rompa el modelo de amenaza previsto de libsodium.

El comentario vinculado sobre el tema libsodium es muy informativo sobre cómo la biblioteca interactúa con asm.js, pero como no experto, no me resulta obvio cómo sonaría ese análisis específico reescrito para WebAssembly (aparte de la compatibilidad con i64 y los navegadores más consistente en el manejo de wasm que asm.js).

Pero de todos modos, entiendo cuál era su punto original de hace un año, y todo lo que realmente me preocupaba era si estaba haciendo una declaración más fuerte de lo que realmente era (se sabía que era una especificación que presentaba nuevas debilidades específicas del canal lateral no se encuentra en el estándar C / clang, a diferencia de que ninguno es generalmente adecuado para ese propósito), así que gracias por aclarar eso.

>

No creo que "más filtraciones" sea una medida útil.

@jfbastien , la seguridad cuantitativa es un campo que se ocupa de medir solo
ese. La métrica común es cuántos bits de información son revelados por un
ataque exitoso: 1 bit frente a 32 bits, por ejemplo, hace una gran diferencia (y en
Práctica casi todos los sistemas tienen pequeñas fugas potenciales a través del costado
canales). Sin embargo, a menudo dicha cuantificación es bastante difícil.

>

No creo que "más filtraciones" sea una medida útil.

@jfbastien , la seguridad cuantitativa es un campo que se ocupa de medir solo
ese. La métrica común es cuántos bits de información son revelados por un
ataque exitoso: 1 bit frente a 32 bits, por ejemplo, hace una gran diferencia (y en
Práctica casi todos los sistemas tienen pequeñas fugas potenciales a través del costado
canales). Sin embargo, a menudo dicha cuantificación es bastante difícil.

Soy consciente de esto y estoy completamente desinteresado porque una fuga es una fuga. Si es importante para los desarrolladores, eventualmente nos morderá (los implementadores de WebAssembly). No creo que WebAssembly deba tratar de abordar este problema en el corto plazo dadas nuestras otras prioridades, y que WebCrypto ya existe como un esfuerzo (a pesar de las deficiencias que podría tener, abordar este problema es mejor que donde está WebAssembly en este momento ). Por supuesto, puede explorar esto en su tiempo libre.

@jfbastien , estuvo de acuerdo en que este tema no tiene prioridad en este momento, que
Wasm no tiene más fugas que C, y no conocemos buenas formas de abordar
eso. Pero simplificaciones excesivas como "una fuga es una fuga" no son útiles en eso
materia: todos los sistemas tienen fugas hasta cierto punto, por lo que la cantidad es, de hecho,
Eso importa. Y esperar hasta que "nos muerda" no es una estrategia que
va a inspirar mucha confianza entre las víctimas potenciales reales, a saber
usuarios del navegador.

Estuvo de acuerdo en que ... Wasm no tiene más fugas que C

Bien, gracias por confirmarlo explícitamente. Eso es todo por lo que vine aquí: una idea general de con qué debería compararlo, no una garantía de si "no se filtrará".

@ rossberg-chromium No creo que esté de acuerdo con la idea de que wasm no tiene más fugas que C. Al final, eso depende de cómo cada motor implemente todo. Por ejemplo, JavaScriptCore agrupa el código y deja de agrupar el código cuando se agota la memoria ejecutable. Esta es una fuga que no existe con el código C. Yo esperaría que, a medida que los motores wasm avancen, es probable que wasm tenga tantas fugas como algo como la JVM. En última instancia, no conozco las especificaciones o los implementadores que probablemente se esfuercen por adaptarse a la prevención de fugas de información, especialmente no a costa del rendimiento.