full-disclosure - [FD] Live2D Cubism refusing to fix validation issue leading to heap corruption.

Open Source and information security mailing list archives

Date: Wed, 01 May 2024 12:47:41 +0000
From: PT via Fulldisclosure <fulldisclosure@...lists.org>
To: "fulldisclosure@...lists.org" <fulldisclosure@...lists.org>
Subject: [FD] Live2D Cubism refusing to fix validation issue leading to heap
	corruption.

Live2D Cubism is the dominant "vtuber" software suite for 2D avatars for use in livestreaming and integrating them in other software.
They publish various SDKs and a frameworks for integrating their libraries with your own program. You're supposed to use those to deserialize and render/animate the models created with their main software - often untrusted files from random people on the internet.
While their main java-based programs and their web toolkit seem to have at least minimal sanity checks for input, the same is not true for their "native" (C/C++) framework.
This is trivially, unintentionally and repeatedly triggered by people just testing it with janky rips available broadly on the internet, such as this model of a Discord moderator: https://github.com/Eikanya/Live2d-model/tree/master/%E4%B8%BA%E7%BE%8E%E5%A5%BD%E7%9A%84%E4%B8%96%E7%95%8C%E7%8C%AE%E4%B8%8A%E7%A5%9D%E7%A6%8F%EF%BC%81Fantastic%20Days/1399100

Those models have nonsense numbers of total segments and points for the animation curves because the Unity live2d asset ripper which was used to generate them calculates the totals wrong. The framework happily trusts the totals and lets you squirt as many bytes (or, more accurately, floating point numbers) as there is contiguous memory allocated. If you hit the upper bound you will segfault, otherwise your allocator will probably panic only on the next free() or allocation.

e.g. https://github.com/MizunagiKB/gd_cubism/issues/52

TLDR: They don't validate that the total numbers of points and segments in animations actually match the total numbers in the corresponding arrays in serialized models. I sent them a patch to recalculate those numbers and ignore the totals, as it's really annoying to have to validate every model manually with an external python script, but they refuse to apply it because the data wasn't generated by their official program and they think this is a customer support issue ?

This leaves gaping wide open a heap corruption issue that I don't have the skill or time to actually exploit in any interesting way, but I'm just going to leave this here because fuck those guys. They also like to send their deranged fanboys after anyone reporting on their incompetence and negligence, because if you're not willing to spend thankless weeks/months trying to get RCE then your bug isn't really el8 enough: https://github.com/UlyssesWu/D2Evil/issues/6#issuecomment-1685596304

PT
Download attachment "publickey - pt4fd@...me - 0xD91D7AF6.asc" of type "application/pgp-keys" (624 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (250 bytes)

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives