Live2D: Why Full Disclosure
Yesterday I released the MOC3ingbird 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 disclosure1.
Coordinated Vulnerability Disclosure
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.2 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 researchers3.
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 EULA4 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,”5 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.6 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
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 year7 should not be seen as excuseable.
Third-party developers implementing the Cubism SDK have it worse, price-wise.8 You could end up giving half your revenue to Live2D9, 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 EULA10 (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 MOC3ingbird 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.
Also CVD, formerly responsible disclosure. See https://en.wikipedia.org/wiki/Coordinated_vulnerability_disclosure. ↩︎ ↩︎
“There are several cases where we’ve identified fairly terrifying bugs and vendors have invoked our clients’ EULAs (which may forbid reverse engineering, or even explicitly prohibit security testing) and made legal threats. In some cases the vendors then either refused to fix bugs we reported, or delayed fixes indefinitely.” See https://www.linkedin.com/pulse/avoiding-eula-drama-shawn-moyer/. ↩︎
The article is paywalled, but the first paragraph is exactly what you need to know: “a dislike of giving and receiving honest feedback due to an emphasis on ‘saving face’.” See https://www.investmentweek.co.uk/feature/4032279/is-saving-face-worth-it-why-old-cultural-practices-hinder-engagement-in-japanese-boardrooms. ↩︎
“In 2021, 70% of Live2D Cubism Pro users is Vtuber […].” See https://en.wikipedia.org/wiki/Live2D#Software and https://s.inside-games.jp/article/2021/12/30/136055.html. ↩︎
You do the math. See https://www.live2d.com/en/download/cubism-sdk/release-license/. ↩︎
“So if you want all regions and platforms, for a company making about $100k a year revenue (whatever the tier was in Yen), they want about 50% of your revenue.” See https://news.ycombinator.com/item?id=35014957. ↩︎
#Security Reports: Full Disclosure #Live2D #Security #MOC3ingbird #Exploit