Josh Goebel

In order to exploit this [as written] *from the outside* you'd need code like this: ```js Meta.eval(potentially_unsafe_user_input, potentially_unsafe_user_input) ``` **The second argument here is just sloppy coding, no?** _The module...

```js const char* module; if (wrenGetSlotType(vm, 2) != WREN_TYPE_NULL) { module = wrenGetSlotString(vm, 2); if (wrenHasModule(vm,module)) { wrenSetSlotString(vm, 0, "Security: Cannot compile into an existing named module."); wrenAbortFiber(vm, 0); }...

> By "existing named module", you mean a module loaded using import "foo" for ... ? Or one previously created with Meta.compile... basically kind of making them read-only once created....

Oh never mind, that works ever without the import "os"... I guess that system (CLI) defined classes exist no matter what as far as "hasModule" is concerned.

Ok, you could wholly replace modules resolved dynamically from `wren_modules` (since they don't exist until imported). Replacing the Farm class/module with our own malicious version: ``` import "meta" for Meta...

I feel like I need a more concrete example though. *eval is a dangerous thing period* If you're running untrusted code naively you already have plenty of problems... perhaps in...

> it is also a scary tool that could potentially be exploited a lot. So I prefer loose a little time thinking about security and be safer than really sorry....

> The programmer can execute code directly, no need to inject before. Right, overall I agree, but injecting could make an attack more dangerous... instead of trying to delete random...

Why would V8 do this? Do you know?

Where did you get this information about V8 masking the top bit - just from our own line 361? I can't seem to confirm... - Deno: https://denolib.github.io/v8-docs/functional_8cc_source.html - Chromium: https://source.chromium.org/chromium/chromium/src/+/master:v8/src/base/functional.cc;drc=e51dd5c377fd47393a171f6bdcd7c1a6a9a609c5;l=97...