[HN Gopher] WASI: WebAssembly System Interface
___________________________________________________________________
WASI: WebAssembly System Interface
Author : teleforce
Score : 105 points
Date : 2023-08-05 08:45 UTC (14 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| tempodox wrote:
| There is the WASI SDK if you want to target WASI from C/C++:
|
| https://github.com/WebAssembly/wasi-sdk
|
| It comes with a libc implemented in WASM.
| jedisct1 wrote:
| A common option for that purpose is Zig. WASI is just one of
| the many targets it can compile C code to, out of the box: `zig
| cc -target wasm32-wasi`. No need to install yet another LLVM
| copy.
|
| Zig produces more optimized code, because it optimizes the libc
| like the rest of the application. So you can enable additional
| WebAssembly features according to the target runtime, for
| example `zig cc -target wasm32-wasi
| -mcpu=baseline+bulk_memory+simd128`.
|
| And you get automatic caching for free.
| tempodox wrote:
| That's cool and all, but how do I get it to use a linker that
| understands those options I give to `wasm-ld` (`--allow-
| undefined`, `--export-all`, `--no-entry`)? As it is, I'm
| getting "error: unsupported linker arg: --allow-undefined"
| when I pass that with `-Wl,`.
| jedisct1 wrote:
| -Wl,--import-symbols -Wl,--export-all-symbols -Wl,--entry=
| (or rather -mexec-model=reactor).
| syrusakbary wrote:
| I'm happy to see more excitement on the Wasm area.
|
| For the cases where you may need full POSIX compatibility for
| sockets, threads, signals or even fork or longjmp/setjmp, I'd
| recommend using WASIX [1] (also referenced in other comments
| here) since it has implemented all those system calls missing
| from WASI.
|
| [1]: https://wasix.org
| SnowProblem wrote:
| I've never seen a worse-described project than WASI.
|
| _" Component model interfaces always support link-time
| interposition."_
|
| Like WTF does this mean? The repo tells me nothing and I've still
| yet to see a clear write-up about what WASI is. I click on "docs"
| folder and there's one file.
| https://github.com/WebAssembly/WASI/blob/main/docs/WitInWasi....
| WTF is wit? This should be in a CONTRIBUTORS.md not in the docs
| folder. I click on "legacy" and I see preview0 and preview1,
| which are basically unreadable proto-specs. Wikipedia tells me
| WASI is a POSIX-like interface but with POSIX I know exactly
| where to look up the functions. Where's a single well-written
| WASI spec?
|
| I'll be honest - this whole project feels like candy for
| architecture astronauts and goes against the spirit of
| WebAssembly. Looks at how well-written WebAssembly's goals are:
| https://webassembly.org/docs/high-level-goals/. Their spec is
| easy to find and easy to read. This is what I want from WASM.
| Whatever WASI is doing, I don't like it. And neither does
| AssemblyScript team apparently:
| https://www.assemblyscript.org/standards-objections.html.
| skybrian wrote:
| They mean that an environment can always provide a fake version
| of a function to a webassembly program. They're defining an API
| but there's no requirement to implement it.
|
| It seems like a rather weak specification where nothing is
| required to work? But at least it defines an interface. You
| might compare it to Go or Java interface types.
| jedisct1 wrote:
| You're referring to yet another part of WASI, which is indeed
| about defining domain-specific sets of APIs.
|
| No specific set is required to be implemented. So an
| application can work somewhere, and not load elsewhere.
|
| But the idea is that similar environments will hopefully
| implement similar APIs, and there's a mechanism to encourage
| that ("worlds").
|
| Not only interfaces are defined. As an illustration, the WASI
| Crypto proposal includes a lot of details on how individual
| functions must behave, because in this context, it's critical
| to avoid inconsistencies between implementations.
| skybrian wrote:
| Good to hear. I was basing what I wrote on the previous
| sentence:
|
| > This can be used to adapt or attenuate the functionality
| of a WASI API without changing the code using it.
|
| It sounds like someone (who?) can use middleware to
| override an API to do whatever they like, even though there
| are specifications elsewhere about what they must do.
|
| In the context of virtualization, would this allow things
| like running one virtual machine inside another? Sandboxes
| all the way down?
| jedisct1 wrote:
| It's more like regular shared libraries.
|
| You can replace a library with a different one that loads
| the original library, defines the same symbols, and
| forwards the function calls.
|
| That's how debugging/protocol inspection tools like 6Jack
| work, and it's pretty convenient.
|
| It could be done with static libraries, but that would
| require renaming all the symbols of the upstream library.
| IshKebab wrote:
| It's basically a POSIX interface for WASM.
|
| I also agree with the AssemblyScript people. WASI is driven by
| people saying "I want to be able to compile existing Linux
| software to WASM and run it on a server!" and to do that they
| have pretty much just copied POSIX.
|
| Great for running old software, but it seems very short sighted
| to me to tie WebAssembly to 70s UNIX design.
|
| It'll probably be popular because people apparently love never
| fixing things...
| Philpax wrote:
| > "Component model interfaces always support link-time
| interposition." > > Like WTF does this mean? The repo tells me
| nothing
|
| Directly above the sentence you quoted:
|
| "Interposition in the context of WASI interfaces is the ability
| for a Webassembly instance to implement a given WASI interface,
| and for a consumer WebAssembly instance to be able to use this
| implementation transparently. This can be used to adapt or
| attenuate the functionality of a WASI API without changing the
| code using it."
|
| > and I've still yet to see a clear write-up about what WASI
| is.
|
| In the same document: [0]
|
| > WTF is wit?
|
| The first link in that document ("Starting in Preview2, WASI
| APIs are defined using the Wit IDL.") is [1].
|
| > I click on "legacy" and I see preview0 and preview1, which
| are basically unreadable proto-specs.
|
| The README for the legacy directory [2] clearly explains what
| they are.
|
| > Where's a single well-written WASI spec?
|
| "Development of each API happens in its own repo, which you can
| access from the proposals list." [3]
|
| > Whatever WASI is doing, I don't like it.
|
| Clearly not - you've gone out of your way to ignore all of the
| documentation that answer your questions.
|
| > And neither does AssemblyScript team apparently
|
| The AssemblyScript team have a bone to pick with WASI based on
| their misunderstanding of what WASI is for (it is not intended
| for use on the web) and WASI's disinterest in supporting UTF-16
| strings. You can see for yourself in [4].
|
| [0]: https://github.com/WebAssembly/WASI/tree/main#wasi-high-
| leve...
|
| [1]: https://github.com/WebAssembly/component-
| model/blob/main/des...
|
| [2]:
| https://github.com/WebAssembly/WASI/blob/main/legacy/README....
|
| [3]: https://github.com/WebAssembly/WASI/blob/main/Proposals.md
|
| [4]: https://github.com/WebAssembly/WASI/issues/401
| SnowProblem wrote:
| None of this is excusable. Tell me what your project does in
| clear English.
|
| "WASI is a standard for 50 functions you can call to do
| systems-level things from your WASM code. Here they are."
|
| Done.
|
| I don't care about wit/witx. I don't care the repo being in
| transition. I don't want to read about interposition or
| components or capabilities. I don't want to see your copy-
| pasta goals from WASM (which aren't clear for WASI). You're
| an API. Show me the API.
| jedisct1 wrote:
| https://wasix.org/docs may be what you are looking for.
|
| The WASI section documents WASI as it is implemented today.
|
| But since then, WASI pivoted and has become an umbrella for
| multiple projects. This is not just an API any more, and at
| the moment, the documentation on the WASI site and
| repositories is for WASI developers, not for developers
| using WASI. So if you didn't follow the whole thing, it is
| indeed be very hard to understand. The stack is
| complicated. But the ultimate goal of the project is to
| actually make it easier for developers to use wasm, without
| having to worry about all these details.
|
| It's essentially about adding dynamic linking to wasm. The
| dynamic libraries embed the function prototypes, so that
| calling functions with the wrong type will cause a link
| error. That requires the definitions of every type of
| function, and WIT, WAI and WITX are domain-specific
| languages to do that.
|
| Right now, WebAssembly is limited to static linking. It
| works very well, even across languages, but types aren't
| automatically checked. Actually, they are, but only using
| the primitive types available in WebAssembly. Here, the
| goal is to support something very close to the Rust type
| system.
|
| The proposal also allows restricting every library to their
| own memory region. So, a buggy or malicious library can
| only mess with its own data, not with the rest of the
| application.
| SnowProblem wrote:
| A million times better. Looks like this comes from the
| Wasmer team.
| skybrian wrote:
| Interesting. This seems almost like an object-oriented
| system where the objects can be large libraries written
| in different languages.
|
| Do libraries have a lifecycle? Can you instantiate
| multiple instances of them?
| Philpax wrote:
| > Tell me what your project does in clear English.
|
| Okay.
|
| "Define a set of portable, modular, runtime-independent,
| and WebAssembly-native APIs which can be used by
| WebAssembly code to interact with the outside world. These
| APIs preserve the essential sandboxed nature of WebAssembly
| through a Capability-based API design."
|
| That's the first goal.
|
| > I don't care about wit/witx. I don't care the repo being
| in transition. I don't want to read about interposition or
| components or capabilities.
|
| Everything you've just mentioned is relevant to people
| implementing the spec, given its wide scope and nature. It
| is not reducible complexity.
|
| It is not a drop-in replacement for POSIX (i.e. it is not
| "a standard for 50 functions"); it goes beyond that, and
| aims to provide a secure and modular way to interact with
| the system where capabilities can be delegated or reduced.
| [deleted]
| [deleted]
| pjmlp wrote:
| To put it bluntly, they are redoing SOM, CORBA, COM and .NET
| component model, and calling it a novelty.
| eyberg wrote:
| [flagged]
| Matheus28 wrote:
| You don't understand how WebAssembly works. You severely
| misunderstand how the VM secures itself. Listen to what all the
| other comments are trying to teach you. There are no security
| vulnerabilities in your code.
|
| For simplicity, pretend any pointer dereference is a function
| call with the address as its argument. The VM makes sure it's
| within the range of valid values every time. There is no
| executable code in that range either, only data. Further,
| function pointers are not real pointers, just an index into a
| table which again, is checked on any indirect function call.
|
| In practice the memory is secured by allocating a 4 GiB aligned
| memory range and just masking off the pointer on every access
| so it's within that memory. This way there's very little to no
| overhead, depending on the architecture.
| junon wrote:
| Not really sure what your point is. You're invoking undefined
| behavior here. What is WASI supposed to do differently?
| eyberg wrote:
| When running the same code on linux or anything else you
| segfault. It is a huge security issue and totally not the
| only one.
| skitter wrote:
| Nope, that's just UB, so you cannot know what the code will
| do. Case in point, running it on linux (compiled via clang)
| doesn't trigger a segvault for me: main:
| .cfi_startproc .Lfunc_end0: .size
| main, .Lfunc_end0-main .cfi_endproc
| junon wrote:
| To be fair, that's because it was optimized out. Mark it
| as volatile and try again. It will almost definitely
| segfault. The other points still stand, though - that's
| just because Linux is forced to respond to a page fault
| exception and chooses to signal that to the process.
| epilys wrote:
| What is the security issue here? In any case memory
| references don't work like that in web assembly: they are
| objects the runtime manages. This isn't assembly, despite
| the name. Your pointer UB will be inside the sandbox and
| nowhere else.
| junon wrote:
| The segfault is NOT a guarantee, even on Linux. DO NOT RELY
| ON SEGFAULTS TO PROTECT YOU. I can't believe this has to be
| said in 2023.
| eyberg wrote:
| Ok. What is your solution then?
|
| 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. The compiler
| merely tells the operating system what should be done -
| it can 't really enforce it.
|
| In this case the various wasm runtimes are acting as that
| piece and they aren't enforcing the expected behavior.
|
| If the compiler says - hey stick this in .rodata and the
| wasm interpreter says I don't know what that is then that
| memory safety feature/contract gets broken.
| skitter wrote:
| Rust's (and other languages) memory safety doesn't come
| from hardware features. Implementing memory safety at the
| language level means that you don't care about whether
| the data sits in a paged mapped as read-only, because the
| language already makes sure you're not writing to said
| data.
|
| Besides, that's the safety of the code running inside the
| VM. Wasm is about the safety of the host.
| duped wrote:
| > If the compiler says - hey stick this in .rodata and
| the wasm interpreter says I don't know what that is then
| that memory safety feature/contract gets broken.
|
| In WASM terms this is called "multiple memories" and it's
| up to compilers to generate code that works as you'd
| expect (eg have a "read only data" memory segment and
| compile the code that references it correctly).
| josephg wrote:
| > 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 wrote:
| 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.
| josephg wrote:
| Thanks! These claims are really interesting.
|
| - WASM has no ASLR.
|
| If I understand correctly, the attack vector here is that
| if a buffer overrun lets you modify a function pointer,
| you could replace that function pointer with another
| pointer to have the program execute different code. As
| you say, this is hard in native linux programs because of
| ASLR. You need a pointer to some code thats loaded in
| memory and you need to know where it is.
|
| In wasm, the "pointer" isn't a pointer at all.
| _indirect_call_ takes an index into the jump table. Yes,
| this makes it easier to find other valid function
| pointers. But wasm also has some advantages here. Unlike
| in native code, you can 't "call" arbitrary locations in
| memory. And indirect_call is also runtime typechecked. So
| you can't call functions with an unexpected type
| signature. Also (I think) the jump table itself can't be
| edited by the running wasm module. So there's no way to
| inject code into the module and run it. You only have
| access to call the already-loaded functions that are in
| the jump table. And amongst those, you can only
| substitute one with a matching type signature.
|
| I agree - ASLR could help here. But it still doesn't
| sound super easy to exploit. That said, it might be much
| easier to exploit this with wasi when the function table
| is filled with unix syscalls.
|
| Docs: https://developer.mozilla.org/en-
| US/docs/WebAssembly/Underst...
|
| - WASM allows writing to 0x0.
|
| You're probably right about this. To be clear, it means
| if pointers are set to 0 then dereferenced, the program
| might continue before crashing. And the memory around 0
| may be overwritten by an attacker. How bad this is in
| practice depends on the prevelance of use-after-free bugs
| (common in C / C++) and what ends up near 0 in memory. In
| rust, these sort of software bugs seem incredibly rare.
| And I wouldn't be surprised if wasm compilers for C/C++
| start making a memory deadzone here - if they aren't
| doing that already.
|
| - wasm can easily overflow buffers
|
| Sure, but so can native C code. And unlike native code,
| wasm can't overflow buffers outside of the data section.
| So you can't overwrite methods or modify the memory of
| any other loaded modules. So on net, wasm is still
| marginally safer than native code here. If you're worried
| about buffer overflows, use a safer language.
|
| - wasm doesn't have the concept of read-only memory
|
| Interesting! I can see this definitely being useful for
| system libraries like mmap. This would definitely be nice
| to have, and it looks like the wasm authors agree with
| you.
|
| https://github.com/WebAssembly/multi-memory/issues/15
| junon wrote:
| > 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 wrote:
| > 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.
| junon wrote:
| > The compiler merely tells the operating system what
| should be done - it can't really enforce it.
|
| I really don't know how to parse this statement.
| `.rodata` is not a guarantee, you can almost always
| change the memory protection of pages your program owns,
| on almost all OSes (including Windows).
|
| Rust also doesn't make guarantees about this stuff,
| either. `.rodata` is more borne out of the need to put
| certain data in certain areas of flash memory depending
| on the platform. It's also a feature of ELF, not Rust.
| It's also not even required. The flags specify how the
| memory is used by the application, not how it's meant to
| be mapped (though usually the ELF loader will map it
| exactly how it's specified to be used).
|
| I'm writing an OS. One of the stage 1 bootloader tasks is
| to load the main kernel as a module. It's in ELF format.
| I can choose how the ELF segments are mapped into memory,
| and as long as they're mapped 1) in the right places and
| 2) with _at least_ the access flags they 're specified to
| use, the program will work correctly.
|
| Further, with Rust in particular, unless a safety
| contract has been violated within an `unsafe{}` block, I
| am guaranteed as a contract of the compiler (barring
| compiler bugs) that anything marked as `const` and thus
| most likely put into a RO segment will not be written to
| by the application. That is not a guarantee C can make,
| and thus not anything an OS can rely on, anyway.
|
| Again, I don't really see your point. I think you're
| conflating _why_ operating systems have memory protection
| flags. They 're there to help, not to guarantee. You can
| only guarantee so much, and if you're writing code like
| what you have in your C example, then the guarantees fly
| out the window.
|
| I don't see how it's WASMs job to check memory read/write
| correctness for you. The _whole point_ is to make it as
| fast as possible whilst being as much of a sandbox as
| possible - "sandbox" here meaning your application should
| operate exactly how the _language_ (not WASM) specifies
| it to work, whereas the _environment_ is locked down to
| allow for only certain operations and accesses to
| resources (which has nothing to do about language
| specifications).
|
| Thus, unless I'm completely missing your point, I
| disagree with your suggestion that WASM is doing
| something inherently wrong here.
|
| ---
|
| To answer your question directly, barring using something
| like Rust (which I would recommend people do anyway as
| it's just a good language regardless of its safety
| guarantees, but that's a personal and subjective
| opinion), don't incur undefined behavior in C, and don't
| rely on the underlying system, if any, to protect you
| against UB.
| umvi wrote:
| How is that a security issue? When compiled to wasm does that
| code escape the wasm vm?
| eyberg wrote:
| This isn't about escaping the vm. It is about changing how
| the program works inside. Wasm also does not have the concept
| of read only memory which is another massive security hole.
| krona wrote:
| > It is about changing how the program works inside
|
| You can do the same in JavaScript, and it can be very
| useful. What's your point?
| eyberg wrote:
| No. I think you are conflating the issues here.
|
| In this case we aren't talking about changing some code
| in a .js file through a RFI attack. We are talking about
| changing the behavior of how the node.js interpreter
| would run the .js file because at the end of the day the
| interpreter itself is what is getting ran by the os.
| kaoD wrote:
| I really don't know how to parse this comment but I'll
| try to be charitable.
|
| How do you propose WASM code is able to change the WASM
| interpreter behavior?
|
| Could you be misunderstanding WASM's memory model? Are
| you aware that WASM code can only access explicitly
| instantiated userspace JS linear memories? Are you aware
| these memories are just ArrayBuffers in JS userspace?
| eyberg wrote:
| Well I think it's been pointed out, repeatedly, that wasm
| needs memory protection.
|
| I'm very far from the only person pointing out a lot of
| this btw:
|
| https://www.usenix.org/system/files/sec20_slides_lehmann.
| pdf
|
| https://i.blackhat.com/us-18/Thu-
| August-9/us-18-Lukasiewicz-...
|
| https://00f.net/2018/11/25/webassembly-doesnt-make-
| unsafe-la...
| kaoD wrote:
| Well those are a lot of links unrelated to my question or
| anything you've said in this thread.
|
| You're clearly unable to admit you're wrong. Hard to be
| charitable about that.
| junon wrote:
| Again, apologies for the bluntness, but the people who
| have linked those _very_ links as responses to your
| ranting are pointing out that _you_ are incorrect about a
| lot of things.
| [deleted]
| pravus wrote:
| No, you would be changing how the wasm module operates in
| its own address space. You aren't changing how the VM
| runs. As far as I know wasm never made any promise
| against self-modifying code and I don't even understand
| the threat model you think exists since everything is
| isolated.
|
| If you have specific security concerns, you should be
| showing actual attacks against wasm runtimes or somehow
| show that the security model of wasm as a whole will
| always reduce to an insecure configuration. What you have
| shown is something that is "exploitable" on pretty much
| every architecture I know of.
| eyberg wrote:
| Well no it is not. You can't run that on linux which I'd
| imagine most people who are wanting to do server-side
| wasm are coming from.
|
| This is another issue: #include
| <stdio.h> #include <stdlib.h> int
| main() { char *s = "world";
| s[0] = 'o'; s[1] = 'w'; s[2] = 'n';
| s[3] = 'e'; s[4] = 'd';
| printf("Hello, %s\n", s); }
| junon wrote:
| ...... I really can't tell if you're trolling now or not.
| dns_snek wrote:
| I feel bad for people who spent their time seriously
| responding to a troll.
| dccoolgai wrote:
| "even if" you can change the program (and like some other
| comments indicated, I'm fairly certain that's not how
| linear memory in WASM works), WASM still runs on a
| "capability model": It has access to only certain file
| handles, sockets, etc. that are provided declaratively.
|
| I was once a huge detractor and naysayer of WASM, but now
| I'll readily admit that this is the way security "always
| should have been done".
| krona wrote:
| The code running in the WASM VM doesn't have any access to the
| operating system. That printf, when run in a WASM VM, doesn't
| do what I think you think it does.
| jedisct1 wrote:
| WebAssembly doesn't make unsafe languages safe:
| https://00f.net/2018/11/25/webassembly-doesnt-make-unsafe-la...
| paulgb wrote:
| The Wasm security model is to isolate at the module level. Each
| module gets its own isolated linear memory, and is prevented
| from reading another module's memory. A module is not prevented
| from reading its own memory via a pointer, nor should it be.
| eyberg wrote:
| So it is cool if you allow an attacker to change the program
| inside?
|
| Not cool.
|
| We were doing this back in the 90s.
| duped wrote:
| > So it is cool if you allow an attacker to change the
| program inside?
|
| The abstract machine behind WASM is a Harvard architecture,
| so self-modifying code (even accidentally through attacks)
| is not possible.
|
| Memory safety is still a problem for languages that aren't
| memory safe, but since the program memory is not writeable
| from the program itself you can't take over control through
| memory safety bugs. Now whether the program interprets its
| data in a way that can be made exploitable is a different
| bug, but one that exists outside what WASM (or any virtual
| machine) can fix - it does mitigate the consequences
| however, since every module is isolated and the runtime
| uses capability-based security to prevent the code from
| accessing any system resources that it doesn't need.
| pjmlp wrote:
| It is definitly possible to corrupt data, even if it is
| not possible to corrupt the stack.
| IX-103 wrote:
| WASM uses a Harvard architecture, so the instruction memory
| is separate from data memory. You can't change the program
| from within the program because you can't write to that
| address space.
| josephg wrote:
| I don't think wasm supports polymorphic code. I'm pretty
| sure the code section of a wasm module is not modifiable.
| It might not even be readable by the module itself.
|
| The point of wasm is to allow C code to run unmodified,
| safely, and with as little performance degradation as
| possible. Sandboxing will mitigate a huge percentage of
| security vulnerabilities in wasm modules but C is still C.
| If you want better memory safety, use wasm with a memory
| safe language.
| eyberg wrote:
| The problem as I pointed out in another thread is that it
| doesn't matter if you are using something like rust.
|
| Wasm downgrades rust memory safety "guarantees" because
| those guarantees are only truly enforced by the operating
| system.
| junon wrote:
| Sorry to be blunt but this is a completely nonsense
| comment that severely misunderstands how applications,
| memory, Rust and operating systems work together.
| slimsag wrote:
| It's actually the hardware that enforces such guarantees.
| The OS could have bugs, like the WASM program - even if
| the entire stack is written in Rust from top to bottom.
|
| Really the only solution is memory safe hardware, which
| there is effort going into, e.g. ARM CHERI[0] and ARM MTE
|
| [0] https://msrc.microsoft.com/blog/2022/01/an_armful_of_
| cheris/
| eyberg wrote:
| This is one of the few comments here I actually agree
| with. Totally agree our current architecture is totally
| broken. It sounds like ARM MTE is coming soonish so
| excited to see that.
| [deleted]
___________________________________________________________________
(page generated 2023-08-05 23:01 UTC)