Hacker News Reader

Comment by yjftsjthsd-h | Hacker News Reader

Why /s? That does massively reduce the exposure

As much as an OS process, on a modern OS that is.

The bounds checking story is only on the external limits of linear memory segments.

If memory gets corrupted inside a linear memory segment, it can equally well be exploited to change execution behaviour, which for many scenarios is already good enough for the attacker.

Yet these kind of attack vectors usually are dropped from blog posts selling WebAssembly as a revolutionary bytecode.

It is only yet another one since various others that came and went since UNCOL became an idea.

How could any general execution environment guarantee memory like that? That doesn't seem like a realistic expectation. You can write safe Rust code if you want memory guarantees in WASM but would you really want it to block the ability to run unsafe Rust code too?

Easy, see other bytecodes with bounds checking opcodes, and where use of unsafe bytecodes taint the executable on the verifier, which then requires explicit execution permission.

Taint it how? What kind of permissions? Your fix is a pop up warning on unsafe code?

See, this is where knowing the history of bytecode formats since UNCOL, would be relevant.

Burroungs (1961),

https://en.wikipedia.org/wiki/Burroughs_Large_Systems

"In fact, all unsafe constructs are rejected by the NEWP compiler unless a block is specifically marked to allow those instructions. Such marking of blocks provide a multi-level protection mechanism."

"NEWP programs that contain unsafe constructs are initially non-executable. The security administrator of a system is able to "bless" such programs and make them executable, but normal users are not able to do this. (Even "privileged users", who normally have essentially root privilege, may be unable to do this depending on the configuration chosen by the site.) While NEWP can be used to write general programs and has a number of features designed for large software projects, it does not support everything ALGOL does."

CLR (2001)

https://learn.microsoft.com/en-us/dotnet/framework/tools/pev...

"Normally, code that is not verifiably type safe cannot run, although you can set security policy to allow the execution of trusted but unverifiable code."

IBM i (nee AS/400)

https://medium.com/@dhemanthc/ibm-i-architecture-how-timi-an...

"SLIC enforces IBM i’s unique object-based model. Rather than managing raw memory locations or file descriptors, all resources (programs, files, queues, data areas, libraries) are managed as named objects with properties, ownership, and permissions. This object model permeates everything in IBM i, from file systems to program calls."

Aka capabilities, and what CHERI project is pushing for as means to fix C and C++ code at hardware level.

Isn't that like rejecting non-safe Rust code? Unsafe code plays an important role in the hot-loops of our ever-slowing computers.

It does, and like in real life, should be handle with glasses and protective gloves.

Now selling yet another bytecode format as some security wonder.

It gets the pass on the browser, as it replaced the existing plugins model, that's it.

Reply on news.ycombinator.com