Type confusion bug in WriteFloatGeneric

[deian]

The buffer writeFloatLE family functions are prone to code [remote] execution attacks via type confusion. The binding layer WriteFloatGeneric function just casts the first argument:

Local<Uint8Array> ts_obj = args[0].As<Uint8Array>();

node/src/node_buffer.cc

Line 826 in 0e6c336

Local<Uint8Array> ts_obj = args[0].As<Uint8Array>();

Few methods are called on the ts_obj after which if you choose a good argument means executing code with some choice.

For example, the following doesn't crash until the memcpy on my machine:

Buffer.prototype.writeFloatLE.call(0xdeadbeef, 0, 0, true);

[addaleax]

See #12119 for a PR that just proposes dropping the noAssert flag.

Also, tbh it seems like a bit of a stretch to call this a security issue. If you have access to the buffer.write* methods and the ability to call them with chosen arguments, you can already perform writes to arbitrary memory anyway.

[deian]

That was actually brought up by my email to [email protected] on 3/27, but I didn't want to create a redundant issue. The snippet for that the OOB write I had was:

const buf = Buffer.from('w00t');
buf.writeFloatLE(0, 4, true);

But this is a different kind of bug: it's a type confusion bug. It just so happens to be in the same code. I think dropping the noAssert flag is great. Thanks for all the great you're doing @addaleax.

[TimothyGu]

The crash itself was fixed in #11927 (4fb9b12), with the original issue being #8724.

[deian]

Saw that you're on top of these! Thanks @TimothyGu! That fixed the oob issues (didn't check, but I trust). The type confusion remains, I think.

On 2d039ff, this will segfault:

function FB() {this.x=33; this.y=44;}
require('util').inherits(FB, Buffer);
Buffer.prototype.writeFloatLE.call(new FB(), 0, 0, true);

[TimothyGu]

You are right. I'm not sure how performance-heavy it would be to check for validity in all the write*() functions, though it does look necessary.

[DemiMarie]

@TimothyGu I think the real solution is to work with the V8 team to make these V8 compiler intrinsics. Then the JIT could eliminate the overhead.

If only V8 had a LuaJIT-style integrated FFI...

[Trott]

Dropping noAssert support entirely (that is, always treating noAssert as if it is false) would fix this, right?

[TimothyGu]

Accidentally closed it... reopening