Live2D: Why Full Disclosure

Yesterday I released the MOC³ingbird proof of concept alongside an article about some serious vulnerabilities I found in Live2D Cubism Core. There has been some criticism about how I did not consult the Live2D developers before releasing this information, so in this article I will explain my rationale for choosing full disclosure over coordinated vulnerability disclosure¹.

Coordinated Vulnerability Disclosure

From Wikipedia:¹

Developers of hardware and software often require time and resources to repair their mistakes. Often, it is ethical hackers who find these vulnerabilities. Hackers and computer security scientists have the opinion that it is their social responsibility to make the public aware of vulnerabilities. Hiding problems could cause a feeling of false security. To avoid this, the involved parties coordinate and negotiate a reasonable period of time for repairing the vulnerability. Depending on the potential impact of the vulnerability, the expected time needed for an emergency fix or workaround to be developed and applied and other factors, this period may vary between a few days and several months.

I highlighted a couple of key words there: coordinate and negotiate. Keep those in mind as you read this article, and try to consider how possible those actions would be in practice.

Licensing Tarpit and Past Behavior

In the past, Live2D Inc. has not been too kind toward developers discovering anything about their software. When a developer tried to implement a MOC3 reader, a Live2D quickly chimed in with legal threats and legal soup from the pot known as an end-user license agreement.² Naturally, they did not even have evidence that there were any violations, nor did they have evidence that the relevant provisions were valid in the developer’s jurisdiction.

We see that the content of your GitHub Repository is a clear violation against our EULA. https://github.com/UlyssesWu/FreeLive

From the issue posted by Takuya Itoh, current Live2D employee and lead software engineer.

It stands to reason that contacting them about the vulnerabilities would have likely resulted in a cease and desist. For that reason, I would not be willing to send them details without a special agreement for my protection, which I am sure they would not sign.

From the EULA, for reference:

5.1.2 No Reverse Engineering

The Customer may not reverse engineer, decompile, disassemble, or otherwise attempt to discover the source code of the Software except in case which the Customer performs modifications of the Software for its own use and reverse engineering for debugging such modifications.

Well, actually we don’t even know if the developer of FreeLive did that, and Live2D Inc. doesn’t know either. Still, something tells me they may be like the many companies that aren’t a fan of security researchers³.

The Past Is The Present: Corporate Culture Doesn’t Change

Japanese corporate culture and attitudes toward copyright are two things I would call unique. Of course, I’m generalizing, and not all companies will fit what I’m saying, but there is a noticeable trend, and Live2D is a part of it. The attitudes I’m referring to are fixed and unchanging for all intents and purposes. Live2D Inc. is not a big company, and has had mostly the same employees for a while, as far as I can tell. There is no reason to believe that the past events mentioned above would not be repeated in some way.

When Japanese businesses open their doors to international customers, there tends to be a tension between the viewpoints, expectations, and laws of foreigners, and those of Japan and the Japanese business. For example, the infamous EULA⁴ says there are no refunds. That probably isn’t legal in Australia, regardless of what the EULA says. When you play ball in a foreign country, you’d better play by their standards and rules.

From a non-legal perspective, the views of foreigners and the views of a Japanese business are often irreconcilably different. Because of the practice of “saving face,”⁵ negative reports from anyone are extremely unlikely to be well received.

Negligence Is Not Good Faith

Live2D Cubism is not new software. Cubism 4 was released in September 2019, during a time when VTubers were growing in popularity and would soon grow to be 70% of their userbase as of 2020.⁶ They should have understood that Live2D models would be circulated and used without regard to their origin or safety, yet they neglected to implement a more secure SDK or file format.

I would not have been so criticial if they had included bounds checking, but merely missed checking a few sections or had an off-by-one error. Unfortunately, this is not the case. The complete lack of bounds checking is a level of negligence one only expects to find in overly optimistic C code from the 1990s, equivalent to using gets() and strcpy() in modern C code.

Even outside of C programming, one of the core tenets of developing user-facing software is to never trust user input, even if that input is in the form of a file. Live2D’s development team completely ignored this. One might say they believed their license would prevent people from discovering the MOC3 format and publishing malicious models. Actual criminals do not care one bit about their license, and opaque file formats are a terrible form of security through obscurity. If Live2D Inc. believed these things would keep them safe, then they gave themselves a false sense of security.

Price Should Equal Quality, Or Else

Live2D Cubism Editor is far too expensive for the quality provided. Yes, software development is hard and bugs are a given. Still, software vendors have certain ethical obligations to their users, to the extent that they are reasonably able to fulfill them: to provide a product with value equal to the price and to provide a product that does not put their customers at excessive risk. Repeating three decade old mistakes throughout the entirety of an ostensibly professional software program costing well over a hundred dollars a year⁷ should not be seen as excuseable.

Third-party developers implementing the Cubism SDK have it worse, price-wise.⁸ You could end up giving half your revenue to Live2D⁹, only to be gifted critical security vulnerabilities in return. Even if they don’t care about end users, they should at least care about the companies paying them $50,000 a year! Not to mention, the other infamous EULA¹⁰ (SDK edition!) prevents the companies paying them from using alternative, more secure solutions alongside Cubism:

The Customer may not use the Derivative Work or the Output File with software(s) or middleware(s) that compete with or could compete with the Software or any other software(s) or middleware(s) produced by Live2D;

In case you aren’t sure what a “Derivative Work” is:

“Derivative Work” means application, animation, or any work developed through using all or any part of the Software.

Yes, that means your entire game, application, or whatever it is you made. If you implement an alternative anyway, then Live2D reserves the right to drop a nuclear warhead on your entire business:

8.4 If this Agreement is terminated pursuant to Section 8.1, the Customer shall promptly destroy the Software, all copies thereof, and all Derivative Work including the Output Files and any other derivatives arising from use of the Software.

Good grief! If I’m paying $50,000 a year to sell products with an SDK, I’d want better contract terms and a more secure SDK. It seems businesses relying on Live2D are locked in to insecurity. Fun, right? If you’re not scared, your shareholders should be.

A Lumpy Rug: They Can’t Save Face

At this point, even if Live2D Inc. responds to my work with legal threats, they still have no choice but to fix their software and protect their users’ security, or lose customers and thus revenue. Many companies will try to sweep vulnerabilities reported to them under the rug, but if their users are aware of the vulnerabilities, then the users now have the capability to advocate for their own security and needs. Publicizing information like MOC³ingbird shifts the balance of power away from the software vendor and toward their users and the general public.

My goal was to either make them fix their software or get their users to be more careful/switch to more secure solutions. I believe I accomplished at least one of those goals, and that is enough. While I do not intend to “fully disclose” every vulnerability I find, this is one of the cases where I believe it is appropriate. If you, as a company developing software, show a record of behaving in good faith, then I will always be more than happy to help you resolve any security problems. If you do not, then I will help your users by providing them with the information necessary to make informed decisions. When the train derails, someone ought to tell them to evacuate.