Design: Explique a segurança

Oi!

Eu tenho uma pergunta: faria sentido elaborar o seguinte neste contexto:

"Além disso, os programas que invocam um comportamento indefinido no nível do idioma de origem podem ser compilados em programas WebAssembly que fazem qualquer outra coisa, incluindo corromper o conteúdo do heap do aplicativo, chamar APIs com parâmetros arbitrários, travar, capturar ou consumir quantidades arbitrárias de recursos (dentro dos limites). "
https://github.com/WebAssembly/design/blob/master/CAndC++.md#undefined-and-implementation-defined-behavior

O que estou pensando é em fornecer contexto / referências que podem ser (talvez) úteis para os desenvolvedores da web vindos de origens não nativas - fornecendo exemplos e discussões adicionais.

Por exemplo, CERT's MSC14-C. MSC15-CPP. comportamento indefinido para vulnerabilidade Os compiladores C podem descartar silenciosamente algumas verificações de contorno , o que pode ser particularmente notável neste contexto (Robert Seacord discute isso com mais detalhes em "Eliminação silenciosa de verificações de limites" ).

Tratamentos mais aprofundados:

• O que todo programador C deve saber sobre comportamento indefinido nº 1/3
• O que todo programador C deve saber sobre o comportamento indefinido nº 2/3
• O que todo programador C deve saber sobre comportamento indefinido # 3/3
• Um guia para comportamento indefinido em C e C ++, parte 1
• Um guia para comportamento indefinido em C e C ++, parte 2
• Um guia para comportamento indefinido em C e C ++, parte 3

Outro conselho potencialmente relevante:

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

Ter um cabeçalho CSP exclusivo para controlar arquivos wasm ajudaria? Acho que os proprietários de sites podem querer evitar que os sub-recursos carreguem o wasm.

Essa é uma pergunta interessante. Definitivamente, devemos permitir que os sites desautorizem o carregamento dinâmico e a avaliação do WebAssembly nos mesmos casos em que desabilitam eval e Function (isso simplesmente sairia da integração do módulo ES6 e das verificações de CSP no Loader path). Além disso, porém, como o WebAssembly será equivalente em capacidade ao JS, não acho que seria necessário distinguir os dois.

Vale a pena apontar o nº 53 para uma discussão sobre algumas das questões de segurança com links dinâmicos.

@jfbastien yup CORS e SRI devem estar disponíveis para desenvolvedores sempre que possível.

@lukewagner Acho que depende do acesso de baixo nível ao recurso que o wasm permitirá. Como você disse fora da caixa, é apenas JS. No entanto, parece que o objetivo geral do wasm é o mais próximo possível do metal das máquinas; uma diretiva CSP para controle global seria bom ter.
Com o tempo, uma abordagem mais granular para os outros recursos também seria melhor.

As outras possibilidades imediatas são utilizar a API de permissões para outros acessos de baixo nível.

Bem, perto do metal em um sentido de performance. De uma perspectiva de segurança, permissões e sandbox, não há discussão sobre ter WebAssembly divergindo de JS.

Não foi esse o sentimento que tive com os anúncios pós-MVP e Brendan Eichs, mas ok: +1:

Acho que você está se referindo a que concordamos que, pós-MVP, a semântica do WebAssembly poderia divergir do que poderia ser polipilado com eficiência em JS. Essa divergência seria em torno de recursos computacionais, nada a ver com segurança / permissões. Isso significa que, embora eles não pudessem ser polyfilled _eficientemente_, novos recursos _podem_ ser simulados por um interpretador WebAssembly escrito em JS ( estilo Emterpreter ). Provavelmente seria bom adicionar uma observação a esse efeito para limitar o que queremos dizer com "divergir de JS".

Sim, isso seria um bom aprimoramento para o documento, certamente, posso ter lido o documento muito rápido, mas não pareceu deixar isso claro.

Acho que foi uma das conversas de Eich sobre adicionar mais recursos de threading e memória que me fez pensar que o wasm teria novos recursos. Suspeito que eles provavelmente também serão adicionados ao JavaScript e estarão sujeitos ao exame usual de novos recursos.

"Não é diferente do POV de segurança do que JS" agora está em Web.md.

Prefiro explicar a distinção melhor. Referir-se a JS não é muito bom de uma perspectiva independente e acho que realmente queremos reduzir a área de superfície de segurança que o JS tem (digamos, scripts de origem cruzada e outros).

Vou falar sobre isso, agora que dei uma palestra sobre isso na CppCon :-)

Para aqueles que podem estar interessados ​​em usar WebAssembly como um alvo para implementações criptográficas, discorrer sobre as diferenças entre JS / asm.js JIT e WebAssembly JIT em termos de suporte para implementações de tempo fixo seria útil. Estou pensando especificamente em operações como bitshifts, branches introduzidos pós-JIT, saltos ou pesquisas condicionais ou outras alterações que o JIT pode fazer que podem introduzir vazamentos de tempo.

Se os desenvolvedores não devem ter expectativas de que o WebAssembly suporte melhor as implementações de tempo fixo do que já temos com asm.js, declarar isso seria útil como parte da elaboração das implicações de segurança do WebAssembly para o design do aplicativo. Se o WebAssembly fornecerá alguns meios de melhorar a proteção de aplicativos em comparação com o que existe atualmente (agora ou depois do MVP, não li as especificações em profundidade), seria ótimo entrar em detalhes também. https://github.com/jedisct1/libsodium.js/issues/24#issuecomment -128002942 tem mais algumas informações sobre os problemas existentes em torno da criptografia JavaScript do lado do cliente.

Isso tudo é muito emocionante, aliás. : D

Concordou que deveríamos ter uma declaração de esclarecimento, conforme sugerido por @dconnolly. A partir de agora, as discussões que tivemos foram de que para o MVP não haveria garantias sobre o que o JIT pode / não pode fazer e que algoritmos de tempo constante não são o uso correto de wasm, pelo menos para o MVP. Isso pode mudar no futuro.

Minha opinião atual é que APIs externas (como oferecidas pelo incorporador, como a plataforma da web) estão melhor posicionadas para oferecer tais garantias porque você geralmente precisa de montagem e bom entendimento da microarquitetura para escrever código de tempo constante adequado. Considere o exemplo extremo de uma CPU fazendo tradução binária dinâmica: WebAssembly não pode garantir o que uma CPU pode / não pode fazer. Minha opinião é que WebAssembly está em um nível muito alto de abstração para expressar o código de tempo constante verdadeiro.

Legal, obrigado pelo esclarecimento. Concordou que APIs de plataforma web são o melhor lugar para esse tipo de coisa, especialmente primitivas ( WebCrypto é / estará apoiando o essencial, com espaço para adições futuras como novas curvas elípticas por meio de notas ). Ansioso por essa linguagem extra sobre segurança, ela ajudará qualquer pessoa que possa interpretar mal as implicações do WebAssembly. : +1:

@jfbastien , tudo o que você disse sobre as garantias do wasm timing ainda se aplica hoje?

Vejo nos documentos atuais que a execução determinística é uma meta, exceto em uma pequena lista de casos extremos documentados, o que parece potencialmente positivo para algoritmos de tempo constante. No entanto, webassembly.org/docs/security reconhece que os ataques temporizados são possíveis e lista algumas possíveis atenuações futuras, mas não está claro se a implicação é que "seu código C com erros não será corrigido magicamente ... ainda assim, vulnerabilidades "ou" de canal lateral podem ser introduzidas, o que não aconteceria com um compilador C típico ".

Garantias rígidas à parte, seria útil pelo menos ter uma noção de onde estamos entre "algoritmos de tempo constante serão 100% definitivamente errados" e "não há razão óbvia para não esperar sempre características de tempo comparáveis ​​à saída binária nativa do clang". Para o ponto de @dconnolly , alguma linguagem especificamente comparando isso com asm.js também seria muito útil - particularmente levando em consideração as implementações como o Firefox, que respeitam totalmente as instruções 'use asm' , e aquelas como o Chrome, que são um pouco mais flexíveis .

O resultado determinístico

No momento, o WebAssembly não faz nenhuma tentativa de garantir nada com relação a vazamentos de informações.

Entendi, obrigado por esclarecer a seção sobre determinismo @jfbastien.

No que diz respeito aos canais de tempo / laterais (e ignorando as garantias ou a falta delas), parece que não há nada relevante nas especificações sobre isso neste momento e nenhum dado útil ainda sobre como as implementações reais se comparam ao clang? O que eu realmente queria chegar, depois de ler seu comentário anterior, é se há uma razão inerente para que as implementações de wasm sejam necessariamente _piores_ do que gcc / clang nesta área. Você mencionou o nível de abstração como uma preocupação, mas não estava claro o que você estava usando como uma comparação de linha de base para um tempo constante "bom o suficiente" (C nativo, montagem, hardware, etc.).

Em outras palavras, dada a escolha entre executar código sensível ao infoleak no clang e uma implementação hipotética melhor / mais madura / mais reforçada com infoleak das especificações do WebAssembly de hoje, o primeiro ainda seria obviamente preferido com base no seu entendimento?

Neste momento, eu não confiaria nem no clang nem no WebAssembly para o código que é sensível a vazamentos de informações. A única maneira que conheço atualmente de realmente obter as garantias que desejo é escrevendo assembly que lê o manual para a CPU específica que estou almejando e com a colaboração próxima do kernel. Saber "x86" ou "ARM 64" nem mesmo é suficiente se você realmente deseja ser independente do tempo.

Você pode obter algumas garantias com alguns compiladores / linguagens, mas se um infoleak é tudo o que você precisa para anular o seu código, então "algum" não é uma garantia suficiente.

Perfeito, obrigado, acho que isso responde à minha pergunta. Concordou em todos os pontos sobre modelagem de ameaças de vazamento de informações gerais; Eu só queria ter uma ideia se o wasm deve ser considerado mais furado do que qualquer outro destino de compilação C (sem asm), o que parece que você está dizendo que não é necessariamente o caso?

Não acho que "mais vazamento" seja uma medida útil. A métrica é "vaza alguma coisa?" A resposta para WebAssembly, clang, C ++ e C são "sim".

Bem, especificamente, o que eu tinha em mente eram algoritmos projetados para atingir certas propriedades de resistência do canal lateral com implementações C puro, como o exemplo de libsodium / NaCl vinculado por @dconnolly. Certamente é ideal se algo sobreviverá a todos os cenários de ataque possíveis, mas também é útil saber o delta entre duas coisas (mesmo se ambas forem ruins, por alguma medida de sucção) e, neste caso, se usar WebAssembly em vez de uma ABI do Linux como um alvo provavelmente quebrará o modelo de ameaça pretendido do libsodium.

O comentário vinculado ao tópico de problema da libsodium é muito informativo sobre como a biblioteca interage com asm.js, mas, como um não especialista, não é óbvio para mim o que essa análise específica soaria como reescrita para WebAssembly (além do suporte i64 e navegadores sendo mais consistente no tratamento de wasm do que asm.js).

Mas de qualquer forma, eu entendo qual era o seu ponto original de um ano atrás, e tudo o que realmente me preocupava era se você estava fazendo uma declaração mais forte do que realmente era (isso era uma especificação conhecida por introduzir novos pontos fracos específicos do canal lateral não encontrado no C / clang padrão, ao contrário de que nenhum deles é geralmente adequado para esse propósito), então, obrigado por esclarecer isso.

>

Não acho que "mais vazamento" seja uma medida útil.

@jfbastien , a segurança quantitativa é um campo que se preocupa em medir apenas
naquela. A métrica comum é quantos bits de informação são revelados por um
ataque bem-sucedido - 1 bit vs 32 bits, digamos, faz uma grande diferença (e em
prática quase todo sistema tem pequenos vazamentos potenciais através do lado
canais). Muitas vezes, essa quantificação é bastante difícil.

>

Não acho que "mais vazamento" seja uma medida útil.

@jfbastien , a segurança quantitativa é um campo que se preocupa em medir apenas
naquela. A métrica comum é quantos bits de informação são revelados por um
ataque bem-sucedido - 1 bit vs 32 bits, digamos, faz uma grande diferença (e em
prática quase todo sistema tem pequenos vazamentos potenciais através do lado
canais). Muitas vezes, essa quantificação é bastante difícil.

Estou ciente disso e totalmente desinteressado porque um vazamento é um vazamento. Se for importante para os desenvolvedores, isso acabará nos afetando (os implementadores do WebAssembly). Não acho que o WebAssembly deva tentar resolver esse problema tão cedo, dadas nossas outras prioridades, e que o WebCrypto já existe como um esforço (apesar da deficiência que possa ter, enfrentar esse problema é melhor do que onde o WebAssembly está no momento ) É claro que você pode explorar isso em seu lazer.

@jfbastien , concordou que este tópico não tem prioridade no momento, que
Wasm não tem mais vazamentos do que C e não conhecemos boas maneiras de lidar com
isto. Mas simplificações exageradas como "um vazamento é um vazamento" não são úteis nisso
matéria - todo sistema vaza em algum grau, então a quantidade é de fato tudo
aquilo importa. E apenas esperar até que "isso nos morda" não é uma estratégia que é
vai inspirar muita confiança entre as verdadeiras vítimas potenciais, nomeadamente
usuários do navegador.

concordou que ... Wasm não tem mais vazamentos do que C

Legal, obrigado por confirmar isso explicitamente! É tudo o que vim aqui: uma noção geral de com o que devo compará-lo, não uma garantia de que "não vazará".

@rossberg-chromium Acho que não concordaria com a ideia de que wasm não tem mais vazamentos do que C. No final das contas, isso depende de como cada motor implementa tudo. Por exemplo, JavaScriptCore organiza o código em camadas e interrompe a hierarquização do código quando fica sem memória executável. Este é um vazamento que não existe no código C. Eu esperaria que, à medida que os motores wasm se tornam mais avançados, o wasm provavelmente estará tão furado quanto algo como o JVM. Em última análise, não tenho as especificações ou os implementadores tendem a se esforçar para acomodar a prevenção de vazamentos de informações, especialmente sem prejudicar o desempenho.