Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

Well for that execution of unsafe Assemblies was already enabled anyway, so there isn't much that the verifier can do.

Which is something that WASM isn't being honest about, corruption of internal data structures is allowed.

If I can control what goes into memory just by calling module public functions with the right data set and access patterns, CFI won't help a thing.

Suddenly the authorization module that would authenticate me as regular user, might give me another set of capabilities and off to the races.



Note for C++ on the CLR that you can use /clr:safe as an MSVC compilation argument. This errors out when trying to access to random pointers at compile time.

/clr:pure uses unsafe and supports those cases though.

And yeah, WebAssembly only doing bounds checking within a single memory block and not actually offering true bounds checking is a big downgrade, and a pretty much unjustified one (+ it's rare among JITted languages...).


If you care about "true" bounds checking, just compile to Wasm from a safe source language. Besides, Wasm does support multiple memory blocks so a potentially-unsafe module need not "taint" anything else.


Security is as strong as the weakest link.


Memory blocks have a page granularity, which makes them useless for pervasive checking. (+ you can do the same thing to a reasonable extent with C even, with guard pages.)




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: