Apple recently began notifying mobile app developers who use hot patching with the assistance of frameworks such…
Step 2 of 2:
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
In an email to developers, Apple stated: “Your app, extension and/or linked framework appears to contain code designed explicitly with the capability to change your app’s behavior or functionality after App Review approval, which is not in compliance with section 3.3.2 of the Apple Developer Program License Agreement and App Store Review Guideline 2.5.2.”
Guideline 2.5.2 reads: “Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install or execute code, including other iOS, watchOS, macOS or tvOS apps.”
Hot patching is a remote update process that’s transparent to the end user, and it is a great approach for developers and end users in most situations, such as when mobile application vulnerabilities need urgent fixes. However, hot patching may not be viewed favorably by an application ecosystem such as the Apple App Store because of its capability to change app behavior or functionality after Apple’s App Store review. This could presumably allow rogue developers or man-in-the-middle attackers to inject or change code as desired, bypassing Apple’s oversight.
Knowing what I know about malicious code, combined with the number of hackers and government agencies who wish to exploit the security and privacy of people’s systems, I can’t say that I blame Apple for doing this. With the security of its App Store constantly being scrutinized, allowing developers to use hot patching could be a vehicle for undermining what Apple is trying to accomplish in the best interests of its users.
When Apple decided to allow this type of patching, it probably had not considered the bigger picture of possible abuse from those with ill intent. It impacts a relatively small number of developers, given the overall number of mobile app users, but a business decision was made to put a stop to it in order to minimize the overall risks.
So how does this change impact your enterprise environment? From an end-user perspective, any iOS apps that were being hot patched may now, according to Apple, be more secure than they were before, since app updates will now have to be rereviewed by Apple (bug updates must go through an App Store review process, but developers can apply for what are called expedited reviews for critical vulnerabilities).
Still, I’m not convinced that Apple can assure us that they’re going to find every flaw in every mobile app that goes through this process. By eliminating hot patching, I’m guessing they’re now going to have to perform even more security checks to track down mobile application vulnerabilities. Still, given all the basic computer and information vulnerabilities we still face, any exploits associated with hot patching are down toward the bottom of the list in my mind.
In terms of enterprise security, the following areas need to be considered:
- The level of security that is — or needs to be — built into your mobile app development lifecycle. Do mobile apps fall under your traditional software development lifecycle controls? Who defines the standards and models the threats?
- The level of scrutiny that is applied to mobile apps that are used in your environment, especially those used for core business purposes. How are they at risk? Have they been tested for security flaws using tools from vendors such as Checkmarx and NowSecure?
- The decisions that users are allowed to make in terms of BYOD and mobile app usage. How does this form of shadow IT impact your attack surface or increase your level of business risk?
- The amount of mobile and mobile app monitoring and alerting that is taking place in your environment. Can you detect broken apps or malicious network traffic? What’s your game plan once you uncover it?
- The security architecture of your overall network, including virtual LANs, guest wireless and cloud services. How could vulnerable mobile apps put critical parts of your production environment at risk if and when apps are exploited in these ways?
I feel for developers and the folks at companies such as Rollout.io who are simply looking to make the mobile app experience better and more secure. At the end of the day, Apple’s decision to eliminate hot patching has certainly ruffled some feathers, and it kills certain levels of efficiency and security in the mobile app development and support lifecycles. Rollout.io has proposed a certificate-based solution, which may help everyone find a happy middle ground.
Regardless of how things end up, if you are in charge of application security or information security, this issue and its outcome needs to remain on your radar.