Design: 보안 설명

안녕하세요!

질문이 있습니다. 이 맥락에서 다음에 대해 자세히 설명하는 것이 의미가 있습니까?

"그 외에 소스 언어 수준에서 정의되지 않은 동작을 호출하는 프로그램은 응용 프로그램 힙의 내용 손상, 임의 매개변수로 API 호출, 중단, 트래핑 또는 임의의 양의 리소스(한도 내에서)."
https://github.com/WebAssembly/design/blob/master/CANdC++.md#undefined-and-implementation-defined-behavior

내가 생각하고 있는 것은 예제와 추가 토론을 제공하여 네이티브가 아닌 배경에서 온 웹 개발자에게 (아마도) 사용할 수 있는 컨텍스트/참조를 제공하는 것입니다.

예를 들어, CERT의 MSC14-C. MSC15-CPP. 취약성 에 의존하지 마십시오. C 컴파일러는 일부 랩어라운드 검사를 자동으로 버릴 수 있습니다. 이 "경계 검사의 자동 제거" 에서 이에 대해 더 자세히 설명함).

보다 심층적인 치료:

• 모든 C 프로그래머가 정의되지 않은 동작에 대해 알아야 할 사항 #1/3
• 모든 C 프로그래머가 정의되지 않은 동작에 대해 알아야 할 사항 #2/3
• 모든 C 프로그래머가 정의되지 않은 동작에 대해 알아야 할 사항 #3/3
• C 및 C++의 정의되지 않은 동작 가이드, 1부
• C 및 C++의 정의되지 않은 동작 가이드, 2부
• C 및 C++의 정의되지 않은 동작 가이드, 3부

기타 잠재적으로 관련된 조언:

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

wasm 파일을 제어하기 위한 고유한 CSP 헤더가 도움이 될까요? 사이트 소유자가 하위 리소스가 wasm을 로드하는 것을 방지하려는 것 같습니다.

흥미로운 질문입니다. eval 및 Function 를 허용하지 않는 것과 동일한 경우에 사이트에서 WebAssembly의 동적 로드 및 평가를 허용하지 않아야 합니다(이는 Loader 에 대한 ES6 모듈 통합 및 CSP 검사에서 제외됩니다.

동적 연결과 관련된 몇 가지 보안 문제에 대한 논의는 #53을 참조할 가치가 있습니다.

@jfbastien yup CORS 및 SRI는 가능한 경우 개발자가 사용할 수 있어야 합니다.

@lukewagner 나는 wasm이 활성화할 리소스에 대한 낮은 수준의 액세스에 달려 있다고 생각합니다. 당신이 상자에서 말했듯이 그것은 단지 JS입니다. 그러나 wasm의 가장 중요한 목표는 기계 금속에 가장 가까운 것 같습니다. 전역 제어에 대한 CSP 지시문은 있으면 좋을 것입니다.
시간이 지남에 따라 다른 기능에 대한 보다 세분화된 접근 방식도 더 좋을 것입니다.

다른 즉각적인 가능성은 다른 저수준 액세스에 권한 API를 활용하는 것입니다.

음, 성능 면에서 금속에 가깝습니다. 보안, 권한 및 샌드박싱 관점에서 WebAssembly가 JS에서 분기되는 것에 대한 논의는 없습니다.

MVP 이후와 Brendan Eichs 발표에서 얻은 느낌은 아니었지만 괜찮습니다. +1:

나는 당신이 언급하는 것은 우리가했다고 생각 에 동의 후 MVP, WebAssembly 의미가 효율적으로 JS에서 polyfilled 할 수있는 것을 갈라지는에 허용 될 것이라고. 이 차이는 보안/권한과는 아무 관련이 없는 계산 기능에 관한 것입니다. 즉, 폴리필을 _효율적으로_ 할 수는 없지만 JS( Emterpreter 스타일 )로 작성된 WebAssembly 인터프리터로 새로운 기능을 _시뮬레이트할 수 있음을 의미합니다. 이 효과에 메모를 추가하여 "JS에서 분기"가 의미하는 바를 묶는 것이 좋을 것입니다.

네, 확실히 문서에 좋은 개선 사항이 될 것입니다. 문서를 너무 빨리 읽었을 수도 있지만 명확하지 않은 것 같습니다.

나는 그것이 내가 wass가 새로운 기능을 얻을 것이라고 생각하게 만든 더 많은 스레딩 및 메모리 기능을 추가하는 것에 대한 Eichs의 이야기 중 하나라고 생각합니다. 나는 이것들이 JavaScript에도 추가될 가능성이 있고 새로운 기능에 대한 일반적인 조사의 대상이 될 것이라고 생각합니다.

"JS보다 보안 POV와 다르지 않음"이 이제 Web.md 에 있습니다.

그 차이를 더 잘 설명하고 싶습니다. JS를 언급하는 것은 자체적인 관점에서 그리 좋지 않으며, 저는 실제로 JS가 가지고 있는 보안 노출 영역(예: cross-origin 스크립트 등)을 줄이고 싶다고 생각합니다.

CppCon에서 그것에 대해 이야기를 나눴으니 이제 이것에 대해 알아보겠습니다 :-)

WebAssembly를 암호화 구현의 대상으로 사용하는 데 관심이 있는 사람들에게는 고정 시간 구현 지원 측면에서 JS/asm.js JIT와 WebAssembly JIT의 차이점에 대해 자세히 설명하는 것이 유용할 것입니다. 비트 시프트, JIT 도입 후 분기, 조건부 점프 또는 조회 또는 JIT가 타이밍 누수를 유발할 수 있는 기타 변경 사항과 같은 작업에 대해 구체적으로 생각하고 있습니다.

개발자가 WebAssembly가 이미 asm.js에 대해 가지고 있는 것보다 더 나은 고정 시간 구현을 지원하기를 기대하지 않아야 하는 경우 애플리케이션 설계에 대한 WebAssembly의 보안 의미에 대해 자세히 설명하는 데 도움이 될 것이라고 언급하는 것이 좋습니다. WebAssembly가 현재 존재하는 것과 비교하여 더 나은 강화 응용 프로그램의 수단을 제공한다면(현재 또는 MVP 이후, 사양을 자세히 읽지 않았습니다), 그것도 자세히 설명하는 것이 좋습니다. https://github.com/jedisct1/libsodium.js/issues/24#issuecomment -128002942에는 클라이언트 측 JavaScript 암호화와 관련된 기존 문제에 대한 추가 정보가 있습니다.

그건 그렇고, 이것은 모두 매우 흥미 진진합니다. :NS

@dconnolly가 제안한 대로 명확한 진술이 있어야 한다는 데 동의했습니다. 지금까지 논의한 내용은 MVP의 경우 JIT가 할 수 있는 것과 할 수 없는 것에 대한 보장이 없으며, 일정 시간 알고리즘이 적어도 MVP에서는 wasm을 올바르게 사용하지 않는다는 것이었습니다. 이는 향후 변경될 수 있습니다.

현재로서는 적절한 고정 시간 코드를 작성하기 위해 어셈블리와 마이크로 아키텍처에 대한 충분한 이해가 필요하기 때문에 외부 API(웹 플랫폼과 같은 임베더에서 제공하는)가 그러한 보증을 제공하는 데 더 나은 위치에 있다는 것입니다. 동적 바이너리 변환을 수행하는 CPU의 극단적인 예를 생각해 보십시오. WebAssembly는 CPU가 할 수 있는 것과 할 수 없는 것을 보장할 수 없습니다. 내 견해는 WebAssembly가 진정한 상수 시간 코드를 표현하기에는 너무 높은 추상화 수준에 있다는 것입니다.

쿨, 설명 감사합니다. 웹 플랫폼 API를 특히 프리미티브, 이런 종류의 물건을위한 최적의 장소임을 합의 ( WebCrypto이 있다 /를 통해 새로운 타원 곡선과 같은 향후 추가를위한 공간, 필수 지원됩니다 노트 ). 보안에 대한 추가 언어를 기대하면 WebAssembly의 의미를 잘못 해석할 수 있는 다른 사람들에게 도움이 될 것입니다. :+1:

@jfbastien , wasm 타이밍 보장에 대해 말한 모든 것이 오늘날에도 여전히 적용됩니까?

현재 문서에서 문서화된 에지 케이스의 작은 목록을 제외하고 결정론적 실행이 목표임을 알 수 있습니다. 이는 상수 시간 알고리즘에 대해 잠재적으로 긍정적으로 들립니다. 그러나 webassembly.org/docs/security 는 타이밍 공격이 가능하다는 것을 인정하고 몇 가지 잠재적인 미래 완화를 나열하지만 의미가 "버그가 있는 C 코드가 마법처럼 수정되지 않을 것입니다... 아직" 또는 "일반적인 C 컴파일러에서는 발생하지 않는 사이드 채널 취약점이 도입될 수 있습니다."

확실한 보장은 제쳐두고, "일정 시간 알고리즘은 확실히 100% 엉망이 될 것"과 "항상 clang의 기본 바이너리 출력에 필적하는 타이밍 특성을 기대하지 않을 분명한 이유가 없습니다" 사이에 우리가 서 있는 위치를 이해하는 데 도움이 될 것입니다. @dconnolly 의 요점에 따르면 이것을 asm.js와 구체적으로 비교하는 일부 언어도 정말 유용할 것입니다. 특히 'use asm' 문을 완전히 존중하는 Firefox와 같은 구현과 좀 더 느슨하게 재생하는 Chrome과 같은 구현을 모두 고려하면 .

@buu700 모든 opcode에 대한 결정적 결과는 모든 opcode에 대해 타이밍이 보장된다는 것을 의미하지 않습니다. Clang은 일정 시간 실행을 보장하지 않으며 정보 누출에 민감한 코드를 작성하는 경우 일정 시간만 필요한 것은 아닙니다.

현재 WebAssembly는 정보 누출과 관련하여 어떤 것도 보장하지 않습니다.

알겠습니다. @jfbastien의 결정론에 대한 섹션을 명확히 해 주셔서 감사합니다.

타이밍/사이드 채널(및 보장 또는 부족 무시)에 관해서는 현재 사양에 관련성이 없고 실제 구현이 clang과 어떻게 비교되는지에 대한 유용한 데이터가 아직 없는 것처럼 들립니다. 이전 의견을 읽은 후 내가 실제로 파악한 것은 wasm 구현이 이 영역에서 반드시 gcc/clang보다 _나쁜_ 고유한 이유가 있는지 여부입니다. 추상화 수준을 우려 사항으로 언급했지만 "충분히 좋은"일정한 타이밍(네이티브 C, 어셈블리, 하드웨어 등)에 대한 기준 비교로 무엇을 사용하고 있는지 명확하지 않았습니다.

다시 말해, clang에서 정보 누출에 민감한 코드를 실행하는 것과 오늘날 WebAssembly 사양에 대한 가상의 최고/가장 성숙한/가장 정보 누출 강화 구현 중에서 선택하는 것이 주어진다면 전자가 여전히 분명히 선호됩니까?

이 시점에서 나는 정보 유출에 민감한 코드에 대해 clang이나 WebAssembly에 의존하지 않을 것입니다. 내가 원하는 보장을 실제로 얻을 수 있는 유일한 방법은 내가 대상으로 하는 특정 CPU에 대한 설명서를 읽고 커널과 긴밀한 협력을 통해 어셈블리를 작성하는 것입니다. "x86" 또는 "ARM 64"를 아는 것만으로는 타이밍에 독립적이고 싶다면 충분하지 않습니다.

일부 컴파일러/언어로 일부 보장을 받을 수 있지만 하나의 정보 누출이 코드를 무력화하는 데 필요한 전부인 경우 "일부"로는 충분하지 않습니다.

완벽합니다. 감사합니다. 제 질문에 대한 답변이라고 생각합니다. 일반적인 정보 유출 위협 모델링에 대한 모든 사항에 동의합니다. 나는 그냥 wasm이 다른 어떤 (asm-free) C 컴파일 타겟보다 더 새는 것으로 간주되어야 하는지에 대한 아이디어를 얻고 싶었습니다.

나는 "더 많은 누출"이 유용한 측정이라고 생각하지 않습니다. 메트릭은 "전혀 새는가?"입니다. WebAssembly, clang, C++ 및 C에 대한 대답은 "예"입니다.

음, 구체적으로 말하자면 @dconnolly로 연결된 libsodium/NaCl의 예와 같이 순수한 C 구현으로 특정 부채널 저항 속성을 달성하도록 설계된 알고리즘이었습니다. 어떤 것이 가능한 모든 공격 시나리오에서 살아남는다면 확실히 이상적이지만 두 가지 사이의 델타를 아는 것도 유용합니다. 표적은 libsodium의 의도된 위협 모델을 깨뜨릴 가능성이 있습니다.

libsodium 문제 스레드에 대한 링크된 주석은 라이브러리가 asm.js와 상호 작용하는 방식에 대해 매우 유익하지만 비전문가로서 해당 특정 분석이 WebAssembly에 대해 다시 작성된 것처럼 들릴지 분명하지 않습니다(i64 지원 및 브라우저 제외 asm.js보다 wasm을 더 일관되게 처리함).

하지만 어쨌든, 나는 1년 전 당신의 원래 요점이 무엇인지 이해하고, 내가 정말로 걱정한 것은 당신이 실제보다 더 강력한 진술을 하고 있는지 여부였습니다. 표준 C/clang에는 없지만 일반적으로 해당 목적에 적합하지 않음), 명확히 해 주셔서 감사합니다.

>

나는 "더 많은 누출"이 유용한 측정이라고 생각하지 않습니다.

@jfbastien , 양적 보안은
저것. 일반적인 메트릭은 정보의 비트 수입니다.
성공적인 공격 -- 예를 들어 1비트와 32비트는 큰 차이를 만듭니다.
연습 거의 모든 시스템은 측면을 통해 잠재적인 누출 가능성이 적습니다.
채널). 그러나 종종 그러한 정량화는 다소 어렵습니다.

>

나는 "더 많은 누출"이 유용한 측정이라고 생각하지 않습니다.

@jfbastien , 양적 보안은
저것. 일반적인 메트릭은 정보의 비트 수입니다.
성공적인 공격 -- 예를 들어 1비트와 32비트는 큰 차이를 만듭니다.
연습 거의 모든 시스템은 측면을 통해 잠재적인 누출 가능성이 적습니다.
채널). 그러나 종종 그러한 정량화는 다소 어렵습니다.

나는 이것을 알고 있고, 누출은 누출이기 때문에 철저히 무관심합니다. 개발자에게 중요하다면 결국 우리(WebAssembly 구현자)를 물게 될 것입니다. 나는 WebAssembly가 우리의 다른 우선순위를 감안할 때 이 문제를 곧 해결하려고 해서는 안 된다고 생각하고 WebCrypto가 이미 노력으로 존재한다고 생각합니다. ). 물론 여가 시간에 이것을 탐색할 수 있습니다.

@jfbastien , 이 주제가 현재 우선순위가 없다는 데 동의했습니다.
Wasm은 C보다 더 새지 않으며 우리가 대처할 좋은 방법을 모릅니다.
그것. 그러나 "누출은 누출이다"와 같은 지나치게 단순화하는 것은 도움이 되지 않습니다.
문제 -- 모든 시스템이 어느 정도 누출되므로 수량은 사실 전부입니다.
중요합니다. 그리고 "그것이 우리를 물릴 때까지 기다리는 것은" 전략이 아닙니다.
실제 잠재적 희생자들 사이에 많은 신뢰를 불러일으키는 것, 즉
브라우저 사용자.

동의했습니다 ... Wasm은 C보다 더 새지 않습니다

좋습니다. 명시적으로 확인해 주셔서 감사합니다! 그것이 내가 여기에 온 전부입니다. 내가 그것을 비교해야 하는 일반적인 의미가 아니라 "누수되지 않을 것"이라는 보장이 아닙니다.

@rossberg-chromium 나는 wasm이 C보다 더 새지 않는다는 생각에 동의하지 않을 것이라고 생각합니다. 결국 각 엔진이 모든 것을 구현하는 방법에 달려 있습니다. 예를 들어 JavaScriptCore는 코드를 계층화하고 실행 가능한 메모리가 부족할 때 코드 계층화를 중지합니다. 이것은 C 코드에는 존재하지 않는 누수입니다. wasm 엔진이 더 발전함에 따라 wasm이 JVM과 같은 누수가 될 것으로 예상합니다. 궁극적으로, 나는 사양이나 구현자가 특히 성능을 희생하지 않고 정보 누출 방지를 수용하기 위해 노력할 것 같지 않습니다.