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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <97nIKplkCYITCrLOEXAZQ-woNky0E_BgK4joMQ02O5Ac5ywrPCMOoa_7ig2aXRS2lvyOev29XKrCWCQ4a0_BWqU6yro39cB2pDCATE1jKGY=@pm.me>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ