3 ms·

> If it is 'use rust' wasm actively downgrades the memory safety that rust gives you because many of the security issues that wasm has is a function of both the

> If it is 'use rust' wasm actively downgrades the memory safety that rust gives you because many of the security issues that wasm has is a function of both the compiler and the operating system working together. Can you say more about this? I’m using rust through wasm and I hadn’t heard of any security disadvantages of doing so. What kind of security problems are mitigated in a native binary that are problems in wasm?

eyberg 3y ago
Again, it's not really 'native binary' vs wasm. The binary can only really tell the os what it expects it to do. It is more of 'operating system' vs wasm. By no means an authoritative list and I've not brought up the sandbox at all - that's completely out of scope for this argument but: * wasm has no aslr - making it incredibly easy to figure out where something lives - you can run the same wasm payload again and again again and get the same result, for instance on linux: me@box:~/w/zz/aslr$ ./aslr Library functions: 00007faebfc9f3f0, Heap: 0000562a103c12a0, Stack: 00007ffeea5d8fec, Binary: 0000562a0f1cf179 me@box:~/w/zz/aslr$ ./aslr Library functions: 00007ff2eda9f3f0, Heap: 000056509ae012a0, Stack: 00007fff849209bc, Binary: 000056509a92d179 ~/w/wasi-sdk-20.0+threads/bin/clang --sysroot ~/w/wasi-sdk-20.0+threads/share/wasi-sysroot/ aslr.c -o aslr.wasm and on wasm... Nothing changes: me@box:~/w/zz/aslr$ wasmer aslr.wasm Library functions: 0000000000000002, Heap: 0000000000011500, Stack: 00000000000114b4, Binary: 0000000000000001 me@box:~/w/zz/aslr$ wasmer aslr.wasm Library functions: 0000000000000002, Heap: 0000000000011500, Stack: 00000000000114b4, Binary: 0000000000000001 (btw - all of this works on all wasm runtimes) * wasm can write directly to 0x0 - meaning I can just initialize variables to all sorts of random bad values (eg: overriding functions that might return an expected value or perhaps I have a user_id from a database or worse an 'admin' flag or something, these are just a few examples - it gets way worse in other languages that depend on this) * wasm can easily overflow buffers (despite claims to the contrary) - that claim really should be taken down from the website - it is totally false * doesn't have the concept of read-only memory These are all issues that linux hasn't really had to deal with for 20? years now.
- junon 3y ago
  > wasm has no aslr Many systems don't employ ASLR. There's a long history of very smart people questioning if ASLR is even a good deterrent. This dissent even extends to KASLR. ASLR is also not unbreakable, don't fool yourself about this. Also, ASLR only works if your code is compiled as position-independent, which isn't always the case. There's also (sometimes) a performance hit with it. Finally, I don't see how the ASLR argument here is anything but moving the goalposts away from your original argument. > wasm can write directly to 0x0 Again, this is not a guarantee, either. Nothing is stopping an OS from mapping in something at virtual page 0 either. It's just a specification from C (perhaps before) that's been adopted by a lot of other languages, so much so that OS developers tend not to map anything there as a rule. On many Microcontrollers for example, 0x0 is usually a perfectly valid memory address, and not allowing something there means you lose at least <required alignment> bytes of usable memory. > wasm can easily overflow buffers Not sure what you mean by this. > that claim really should be taken down from the website Can you quote the claim? Bonus points for linking to it so we have some context. > doesn't have the concept of read-only memory So? Again, as many others have pointed out, neither do OSes unless you can somehow guarantee they're mapping memory in with an MMU or MPU with flags lacking X/W. You're still trusting the OS to do it right, the linker to do it right, and the language to place symbols in the right sections. > These are all issues that linux hasn't really had to deal with for 20? years now. Of course it has, what are you talking about?
  - eyberg 3y ago
    > So? Again, as many others have pointed out, neither do OSes unless you can somehow guarantee they're mapping memory in with an MMU or MPU with flags lacking X/W. You're still trusting the OS to do it right, the linker to do it right, and the language to place symbols in the right sections. If you don't care/understand about the concept of read-only memory I'm not going to be able to convince you of anything. I'll just state that there's a few tens of thousands of people descending on Vegas next week and the longer the wasm community doesn't deal with these issues the louder those people are going to get.
    - 3y ago

eyberg 3y ago

Again, it's not really 'native binary' vs wasm. The binary can only really tell the os what it expects it to do. It is more of 'operating system' vs wasm. By no means an authoritative list and I've not brought up the sandbox at all - that's completely out of scope for this argument but: * wasm has no aslr - making it incredibly easy to figure out where something lives - you can run the same wasm payload again and again again and get the same result, for instance on linux: me@box:~/w/zz/aslr$ ./aslr Library functions: 00007faebfc9f3f0, Heap: 0000562a103c12a0, Stack: 00007ffeea5d8fec, Binary: 0000562a0f1cf179 me@box:~/w/zz/aslr$ ./aslr Library functions: 00007ff2eda9f3f0, Heap: 000056509ae012a0, Stack: 00007fff849209bc, Binary: 000056509a92d179 ~/w/wasi-sdk-20.0+threads/bin/clang --sysroot ~/w/wasi-sdk-20.0+threads/share/wasi-sysroot/ aslr.c -o aslr.wasm and on wasm... Nothing changes: me@box:~/w/zz/aslr$ wasmer aslr.wasm Library functions: 0000000000000002, Heap: 0000000000011500, Stack: 00000000000114b4, Binary: 0000000000000001 me@box:~/w/zz/aslr$ wasmer aslr.wasm Library functions: 0000000000000002, Heap: 0000000000011500, Stack: 00000000000114b4, Binary: 0000000000000001 (btw - all of this works on all wasm runtimes) * wasm can write directly to 0x0 - meaning I can just initialize variables to all sorts of random bad values (eg: overriding functions that might return an expected value or perhaps I have a user_id from a database or worse an 'admin' flag or something, these are just a few examples - it gets way worse in other languages that depend on this) * wasm can easily overflow buffers (despite claims to the contrary) - that claim really should be taken down from the website - it is totally false * doesn't have the concept of read-only memory These are all issues that linux hasn't really had to deal with for 20? years now.

junon 3y ago
> wasm has no aslr Many systems don't employ ASLR. There's a long history of very smart people questioning if ASLR is even a good deterrent. This dissent even extends to KASLR. ASLR is also not unbreakable, don't fool yourself about this. Also, ASLR only works if your code is compiled as position-independent, which isn't always the case. There's also (sometimes) a performance hit with it. Finally, I don't see how the ASLR argument here is anything but moving the goalposts away from your original argument. > wasm can write directly to 0x0 Again, this is not a guarantee, either. Nothing is stopping an OS from mapping in something at virtual page 0 either. It's just a specification from C (perhaps before) that's been adopted by a lot of other languages, so much so that OS developers tend not to map anything there as a rule. On many Microcontrollers for example, 0x0 is usually a perfectly valid memory address, and not allowing something there means you lose at least <required alignment> bytes of usable memory. > wasm can easily overflow buffers Not sure what you mean by this. > that claim really should be taken down from the website Can you quote the claim? Bonus points for linking to it so we have some context. > doesn't have the concept of read-only memory So? Again, as many others have pointed out, neither do OSes unless you can somehow guarantee they're mapping memory in with an MMU or MPU with flags lacking X/W. You're still trusting the OS to do it right, the linker to do it right, and the language to place symbols in the right sections. > These are all issues that linux hasn't really had to deal with for 20? years now. Of course it has, what are you talking about?
- eyberg 3y ago
  > So? Again, as many others have pointed out, neither do OSes unless you can somehow guarantee they're mapping memory in with an MMU or MPU with flags lacking X/W. You're still trusting the OS to do it right, the linker to do it right, and the language to place symbols in the right sections. If you don't care/understand about the concept of read-only memory I'm not going to be able to convince you of anything. I'll just state that there's a few tens of thousands of people descending on Vegas next week and the longer the wasm community doesn't deal with these issues the louder those people are going to get.
  - 3y ago