Replace `NativeBufferFactory` with a more secure implementation

[kewde]

Description

Skia.NativeBuffer is badly designed.

The MakeFromImage function sadly returns pointers as BigInts.

react-native-skia/packages/skia/cpp/api/JsiNativeBuffer.h

Lines 20 to 25 in 15edae0

	JSI_HOST_FUNCTION(MakeFromImage) {
	auto image = JsiSkImage::fromValue(runtime, arguments[0]);
	image->makeNonTextureImage();
	uint64_t pointer = getContext()->makeNativeBuffer(image);
	return jsi::BigInt::fromUint64(runtime, pointer);
	}

The Release function accepts a BigInt argument, which is expected to be the pointer for which the memory should be freed. It should've encapsulated the pointers and restricted this with a check to ensure the value can't be tampered with from JavaScript side.

react-native-skia/packages/skia/cpp/api/JsiNativeBuffer.h

Lines 27 to 34 in 15edae0

	JSI_HOST_FUNCTION(Release) {
	jsi::BigInt pointer = arguments[0].asBigInt(runtime);
	const uintptr_t nativeBufferPointer = pointer.asUint64(runtime);
	getContext()->releaseNativeBuffer(nativeBufferPointer);
	return jsi::Value::undefined();
	}

Ideally, the JavaScript side does not get an arbitrary way to free any hardware pointers beyond the ones it's explicitly been granted.

[kewde]

The recent blogpost by Google Project Zero [1] is a good example of how a simple CFRelease can be useful exploit primitive.

The gist of the attack is to rely on destructors of other Core Foundation classes to gain code execution, in the blogpost above the describe a way to create a fake malicious CFReadStream, if CFRelease is called onto these fake objects, their destructors get called and suddenly the attacker owns the control flow of the application.

In essence, this API can be abused to allocate a native buffer and we get its pointer to this memory. We fill that memory with our own fake CFReadStream, then call to release it and from there on out we control what gets executed. The memory we allocate likely isn't executable so, and there are a lot of hoops to jump through but I have a hunch that it is a viable exploitation path.

[1] https://googleprojectzero.blogspot.com/2025/03/blasting-past-webp.html

[wcandillon]

yes I can see how this is problematic, I need to think about it a little bit more.

…

On Mon, Apr 7, 2025 at 1:52 PM kewde ***@***.***> wrote: The recent blogpost by Google Project Zero [1] is a good example of how a simple CFRelease can be useful exploit primitive. The gist of the attack is to rely on destructors of other Core Foundation classes to gain code execution, in the blogpost above the describe a way to create a fake malicious CFReadStream, if CFRelease is called onto these fake objects, their destructors get called and suddenly the attacker owns the control flow of the application. In essence, this API can be abused to allocate a native buffer and we get its pointer to this memory. We fill that memory with our own fake `CFReadStream, then call to release it and from there on out we control what gets executed. The memory we allocate likely isn't executable so, and there are a lot of hoops to jump through but I have a hunch that it is a viable exploitation path. [1] https://googleprojectzero.blogspot.com/2025/03/blasting-past-webp.html — Reply to this email directly, view it on GitHub or unsubscribe. You are receiving this email because you are subscribed to this thread. Triage notifications on the go with GitHub Mobile for iOS or Android.