Fortnite Android to be Vulnerable to MitD Attacks

According to Google researchers, Android version of one of the most popular videogames had a serious security gap
28 August 2018   1946

Security experts from Google found a vulnerability in the installation package of Fortnite for Android-smartphones. The application is vulnerable to Man-in-the-Disk (MitD) attack. It allowed to download and run any application with an unlimited number of privileges. The company-developer has already released version 2.1.0 with security fixes.

Researchers of the corporation published information about the problem in Google's bug-tracker on August 15, 2018. They became interested in the app after the publisher decided not to release the game in the Google app store, thereby deciding not to give the company 30% of the revenue for in-game purchases.

After it became known, profile publications like Android Central expressed concerns about the safety and usefulness of such an Epic strategy. The company promotes the game installer through its own site, and to launch it, it is necessary to put a checkmark in the box "Installing from unreliable sources" of the device settings.

Using the MitD vulnerability in the Fortnite installer, an attacker could download any program to the device, including malware. This was due to the peculiarity of external memory management in Android - it is used by all applications together. Because the mobile version of Fortnite does not contain the game itself, but loads additional files from the Epic Games repository, it leaves the external memory open to hackers.

Any app with the WRITE_EXTERNAL_STORAGE permission can substitute the APK immediately after the download is completed and the fingerprint is verified. This is easily done using a FileObserver. The Fortnite Installer will proceed to install the substituted (fake) APK. If the fake APK has a targetSdkVersion of 22 or lower, it will be granted all permissions it requests at install-time. This vulnerability allows an app on the device to hijack the Fortnite Installer to instead install a fake APK with any permissions that would normally require user disclosure.
 

Google Researcher

After publishing the information in the bug tracking system, the researchers of the corporation informed Epic developers about the need to release the patch. The specialists made a report on the problem public on August 25, 2018, a week after the correction appeared in version 2.1.0.

Android is an open platform. We released software for it. When Google identified a security flaw, we worked around the clock (literally) to fix it and release an update. The only irresponsible thing here is Google’s rapid public release of technical details. We asked Google to hold the disclosure until the update was more widely installed. They refused, creating an unnecessary risk for Android users in order to score cheap PR points. Google did privately communicate something to the effect that they’re monitoring Fortnite installations on all Android devices(!) and felt that there weren’t many unpatched installs remaining.
 

Tim Sweeney

CEO, Epic Games

Another Battle Royale game - PlayerUnknown's Battlegrounds - also became the target of hackers. In April 2018, the researchers found a related ransomware.

Java SE 14 to be Available

Java SE 14 is as a regular support period version for which updates will be released before the next release
18 March 2020   352

After six months of development, Oracle released the Java SE 14 (Java Platform, Standard Edition 14), which uses the OpenJDK open source project as its reference implementation. Java SE 14 maintains backward compatibility with previous releases of the Java platform; all previously written Java projects will work without changes when launched under the new version. Ready-to-install Java SE 14 builds (JDK, JRE, and Server JRE) are prepared for Linux (x86_64), Windows, and macOS. The Java 14 reference implementation developed by the OpenJDK project is fully open under the GPLv2 license with GNU ClassPath exceptions that allow dynamic linking to commercial products.

Java SE 14 is categorized as a regular support period for which updates will be released before the next release. As a branch with a long service life (LTS), you should use Java SE 11, updates for which will be released until 2026. The previous Java 8 LTS branch will be supported until December 2020. The next LTS release is scheduled for September 2021. Recall that since the release of Java 10, the project has switched to a new development process, which implies a shorter cycle of generating new releases. New functionality is now being developed in one constantly updated master branch, in which ready-made changes are included and from which branches are released every six months to stabilize new releases.

These are some of the changes and updates:

  • Added experimental support for pattern matching in the instanceof operator, which allows you to immediately determine the local variable to access the checked value.
  • Experimental support has been added for the new “record” keyword, which provides a compact form for defining classes, avoiding the explicit definition of various low-level methods, such as equals (), hashCode () and toString (), in cases where data is stored only in fields, the behavior of work with which does not change.
  • This declaration will automatically add implementations of the equals (), hashCode (), and toString () methods in addition to the constructor and methods that control the change of data (getter).
  • Standardized and enabled by default is support for a new form of switch statements that does not require a break statement, allows you to combine duplicate labels, and allows use not only in the form of an operator, but also as an expression.
  • The experimental support for text blocks has been expanded - a new form of string literals that allows you to include multiline text data in the source code without using character escaping and preserving the original text formatting in the block
  • The informative value of diagnostics in case of NullPointerException exceptions has been expanded.
  • A preliminary version of the jpackage utility has been implemented, which allows you to create packages for self-contained Java applications.
  • A new memory allocation mechanism has been added to the G1 garbage collector, taking into account the specifics of working on large systems using the NUMA architecture.
  • Added API for tracking on-the-fly JFR events (JDK Flight Recorder), for example, for organizing continuous monitoring.
  • Added the jdk.nio.mapmode module, which offers new modes (READ_ONLY_SYNC, WRITE_ONLY_SYNC) for creating mapped byte buffers (MappedByteBuffer) that reference non-volatile memory (NVM).
  • A preliminary version of the Foreign-Memory Access API has been implemented, which allows Java applications to safely and efficiently access memory areas outside the Java heap by manipulating new abstractions of MemorySegment, MemoryAddress, and MemoryLayout.
  • Ports for Solaris OS and SPARC processors (Solaris / SPARC, Solaris / x64 and Linux / SPARC) declared obsolete with intent to delete.

Get more at the Oracle website.