Extern: Update TinyGLTF to include fix for CVE-2022-3008 #105536

Julian Squires · 2023-03-07T17:55:53+01:00

Julian Squires commented

2023-03-07 17:55:53 +01:00

The use of wordexp(3) permits arbitrary code execution from
manually-crafted glTF files. See
https://github.com/syoyo/tinygltf/issues/368
for more details.

Note that the warning that required the local modification is no
longer present upstream since
0bfcb4f49e

The use of wordexp(3) permits arbitrary code execution from manually-crafted glTF files. See https://github.com/syoyo/tinygltf/issues/368 for more details. Note that the warning that required the local modification is no longer present upstream since https://github.com/syoyo/tinygltf/commit/0bfcb4f49e0b149c41ba67eeb3b64f297c1637f5

Julian Squires force-pushed update-tinygltf from db9668604e to ba4514f8f2

2023-03-07 17:57:12 +01:00

Compare

Julian Squires requested review from Julian Eisel 2023-03-07 18:00:36 +01:00

Brecht Van Lommel commented

2023-03-07 19:23:06 +01:00

If this is a security fix it should target 3.5 (and get backported to LTS after):
https://wiki.blender.org/wiki/Tools/Pull_Requests#Rebasing_a_Pull_Request

However from what I understand we only use tinygltf for data coming the OpenXR driver, so there may be no security issue for Blender in practice as the driver can already execute arbitrary code. If so it's not strictly needed to have it in 3.5 or LTS, though maybe there are other reasons why it helps to upgrade those versions.

If this is a security fix it should target 3.5 (and get backported to LTS after): https://wiki.blender.org/wiki/Tools/Pull_Requests#Rebasing_a_Pull_Request However from what I understand we only use tinygltf for data coming the OpenXR driver, so there may be no security issue for Blender in practice as the driver can already execute arbitrary code. If so it's not strictly needed to have it in 3.5 or LTS, though maybe there are other reasons why it helps to upgrade those versions.

Julian Squires commented

2023-03-08 14:47:11 +01:00

If this is a security fix it should target 3.5 (and get backported to LTS after):
https://wiki.blender.org/wiki/Tools/Pull_Requests#Rebasing_a_Pull_Request

However from what I understand we only use tinygltf for data coming the OpenXR driver, so there may be no security issue for Blender in practice as the driver can already execute arbitrary code. If so it's not strictly needed to have it in 3.5 or LTS, though maybe there are other reasons why it helps to upgrade those versions.

I was hoping someone more familiar with the OpenXR code would assess whether it constitutes a vulnerability worthy of backporting. I apologize that this is a bit of a drive-by; I noticed this only because I was surveying the use of wordexp in applications on my system, and it wasn't clear to me whether it was possible for a user to open glTF files that might have been supplied from an untrusted source or not -- I don't know where the controller models come from. Clearly it's worth fixing anyway, so no one else decides to use the broken version for a broader purpose.

Let me know if you'd like me to target this against a different branch.

> If this is a security fix it should target 3.5 (and get backported to LTS after): > https://wiki.blender.org/wiki/Tools/Pull_Requests#Rebasing_a_Pull_Request > > However from what I understand we only use tinygltf for data coming the OpenXR driver, so there may be no security issue for Blender in practice as the driver can already execute arbitrary code. If so it's not strictly needed to have it in 3.5 or LTS, though maybe there are other reasons why it helps to upgrade those versions. I was hoping someone more familiar with the OpenXR code would assess whether it constitutes a vulnerability worthy of backporting. I apologize that this is a bit of a drive-by; I noticed this only because I was surveying the use of wordexp in applications on my system, and it wasn't clear to me whether it was possible for a user to open glTF files that might have been supplied from an untrusted source or not -- I don't know where the controller models come from. Clearly it's worth fixing anyway, so no one else decides to use the broken version for a broader purpose. Let me know if you'd like me to target this against a different branch.

Brecht Van Lommel commented

2023-03-08 18:05:50 +01:00

I think we might as well target this at 3.5 and backport to LTS. But will leave final decision to @JulianEisel.

Julian Eisel commented

2023-03-09 15:07:52 +01:00

If this is easy for platform maintainers to update for 3.5, I'm fine with it. Don't have a strong opinion though.

Indeed, we just use TinyGLTF to get the controller geometry from the OpenXR runtime which is installed on the system (like a driver).

If this is easy for platform maintainers to update for 3.5, I'm fine with it. Don't have a strong opinion though. Indeed, we just use TinyGLTF to get the controller geometry from the OpenXR runtime which is installed on the system (like a driver).

Brecht Van Lommel commented

2023-03-09 15:09:36 +01:00

It's in extern, there is no work for platform maintainers. Doesn't hurt to check on the buildbot though.

@blender-bot build

It's in extern, there is no work for platform maintainers. Doesn't hurt to check on the buildbot though. @blender-bot build

Julian Eisel approved these changes 2023-03-09 16:50:01 +01:00

Julian Eisel left a comment

A Linux PLY test is failing but that should be unrelated.

PR looks good to me.

A Linux PLY test is failing but that should be unrelated. PR looks good to me.

Julian Eisel commented

2023-03-09 16:51:03 +01:00