As you are likely aware, a serious vulnerability has been discovered in Apache Log4J 2, a very popular logging library for Java services. This attack is informally referred to as log4shell, presumably due to the way it allows an attacker to make privileged JNDI calls via the logging of simple input data from an API or web form.

We are pleased to report that brainCloud’s Production Services are unaffected by this vulnerability – and that we have further patched our services to eliminate any future risk of attack.

More specifically:

• brainCloud’s API and Portal services do not use Log4J 2 – and are thus not affected by log4shell.
• Some secondary Datastream and RTT services do use Log4J 2 – but these services do not log raw input data in our Production configuration – and thus, once again – are not affected by log4shell.
• To eliminate any future risk of exposure, we have now patched all services that use Log4J 2 to version 2.16.0, which disables the compromisable functionality.

The security of your apps and user data is of utmost importance to us. Thank you for trusting your business to brainCloud!

Hi folks,

We are currently tracking some oddities in the reliability of the brainCloud libraries running in Unity 2019.X on iOS devices.

Updates:

1. We have confirmed that this issue is limited to iOS only (edit: also probably tvOS). It does not occur on Android, Mac, Windows or WebGL.
2. A Unity Rep has confirmed the defect, and that they are working on a fix. See this Unity Forum thread.
3. The defect now appears in Unity’s Issue Tracker – click and add your +1 – https://issuetracker.unity3d.com/issues/ios-unitywebrequest-errors-large-packets-with-examples  
4. Further updates in this brainCloud Forum Post.

Executive Summary: We highly advise developers to stick with Unity 2018.X until further notice.

Symptoms

The symptom is that requests are being sent to brainCloud, and occasionally rejected with what brainCloud calls a signature error.

Signature errors are flagged if the content of the message that brainCloud receives doesn’t match the MD5 that has been calculated for the message. They generally mean that either the client had the wrong secret (likely a hacking attempt) or the message content has been tampered with (also likely a man-in-the-middle hacking attempt).

In this case, neither of these has occurred – rather, the message content has been corrupted somehow by Unity’s libraries (we suspect a combination of the UnityWebRequest and/or UploadHandler classes).  

This doesn’t happen all-the-time… (in fact, it very rarely occurs if requests are less than 2K). But we’re seeing it happening quite often with requests that are 7K or greater in size.

After enough of these errors occur, the UnityWebRequest class is locking up – causing the brainCloud client library to stop functioning properly – requiring the app to be terminated.

Note – the good news is that brainCloud’s servers catch this issue and prevent the bad message from corrupting your data. The bad news is that a client experiencing this issue might have to retry several times to send a request – impairing client performance.

Reproducing the error

We have only been able to reproduce this error in Unity 2019.1.X (as well as 2019.2.0b5 (alpha) and 2019.3.0a5 (beta)) and only when running on iOS devices. 

We do have reason to suspect that Android devices may also be impacted (but we haven’t had time to test + prove that yet). Update: We have since tested on Android and cannot reproduce the problem. So this appears to be an iOS-only issue. 

Certainly, the same code running from the editor on Mac and Windows workstations seems to run just fine.

And certainly, the same brainCloud libraries (with test code) running under Unity 2018.X runs fine as well. Also, our C++/Objective-C libraries are still running fine under iOS – this issue is limited to Unity. 

We have noted, as per their 2019 release notes, that Unity seems to be making significant changes to their iOS communications.

• 2019.1 Release notes
  • iOS: UnityWebRequest will use new backend based on NSURLSession. Old NSUrlConnection backed is still available (commented out in trampoline)
• 2019.1.4 Release notes:
  • iOS: Fixed larger than 2k payloads not sent by UnityWebRequest when HTTP/2 (1146305, 1152777)

Recommendation

For now, we recommend that developers limit their production iOS builds to Unity 2018.X or earlier.

We are constructing a limited function test app that we will submit to Unity when we report this defect. We will keep the community posted as to how that progresses.

Update – you can see the brainCloud forum post, with repro code and details, here.

In the meantime, we thought it best that our community have a heads up regarding this potential problem.

We apologize for the inconvenience and hope that through working with Unity, we can get a solution to you ASAP!