Insecure Storage: Lacking Data Protection

[Balakrishnan-R07]

usr/local/share/agentWork/app/App_iOS-2/App/Pods/FirebaseCrashlytics/Crashlytics/Crashlytics/Models/FIRCLSFileManager.m : 64

usr/local/share/agentWork/app/App_iOS-2/App/Pods/GoogleUtilities/GoogleUtilities/Environment/GULHeartbeatDateStorage.m : 150

Summary
On line 64 of FIRCLSFileManager.m, the method createFileAtPath:contents:attributes:() writes data to a file lacking sufficient encryption settings.The identified method writes data to a file lacking sufficient encryption settings.

On line 150 of GULHeartbeatDateStorage.m, the method writeDictionary:forWritingURL:error:() writes data to a file lacking sufficient encryption settings.The identified method writes data to a file lacking sufficient encryption settings.

Explanation
The Data Protection API is designed to let applications declare when items in the Keychain and files stored on the file system should be accessible. It is available for most file and database APIs, including NSFileManager, CoreData, NSData, and SQLite. By specifying one of four protection classes for a given resource, a developer can instruct the underlying file system to encrypt it either using a key derived from both the device's UID and the user's passcode or using a key solely based on the device's UID (as well as when to automatically decrypt it).

The Data Protection classes are defined for NSFileManager as constants meant to be assigned as the value for the NSFileProtectionKey key in an NSDictionary associated with the NSFileManager instance, and files can be created or have their data protection class modified through use of NSFileManager functions including setAttributes:ofItemAtPath:error:, attributesOfItemAtPath:error:, and createFileAtPath:contents:attributes:. In addition, corresponding Data Protection constants are defined for NSData objects as NSDataWritingOptions that can be passed as the options argument to NSData functions writeToURL:options:error: and writeToFile:options:error:. The definitions for the various Data Protection class constants for NSFileManager and NSData are as follows:

-NSFileProtectionComplete, NSDataWritingFileProtectionComplete:
The resource is stored in an encrypted format on disk and cannot be read from, or written to, while the device is locked or booting.
Available in iOS 4.0 and later.
-NSFileProtectionCompleteUnlessOpen, NSDataWritingFileProtectionCompleteUnlessOpen:
The resource is stored in an encrypted format on disk. Resources can be created while the device is locked, but once closed, cannot be opened again until the device is unlocked. If the resource is opened when unlocked, you may continue to access the resource normally, even if the user locks the device.
Available in iOS 5.0 and later.
-NSFileProtectionCompleteUntilFirstUserAuthentication, NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication:
The resource is stored in an encrypted format on disk and cannot be accessed until after the device has booted. After the user unlocks the device for the first time, your app can access the resource and continue to access it even if the user subsequently locks the device.
Available in iOS 5.0 and later.
-NSFileProtectionNone, NSDataWritingFileProtectionNone:
The resource has no special protections associated with it. It can be read from, or written to, at any time.
Available in iOS 4.0 and later.

Even though all files on an iOS device, including those without an explicitly assigned Data Protection class, are stored in an encrypted form, specifying NSFileProtectionNone results in encryption using a key derived solely based on the device's UID. This leaves such files accessible any time the device is powered on, including when locked with a passcode or when booting. As such, usages of NSFileProtectionNone should be carefully reviewed to determine if further protection with a stricter Data Protection class is warranted.

[morganchen12]

What exactly is the security concern here? That someone with access to the unlocked device can read the crash logs?