When an application has some logic to receive arbitrary data (for example over the network) and to then de-serialize the data into an object, caution should be used when implementing this logic.
If raw data can choose an arbitrary class as the the object it gets de-serialized to, this can lead to remote code execution.
In iOS applications, object deserialization/serialization is usually implemented using the NSCoding protocol, which allows the developer to implement the serialization logic for their own classes, or the NSSecureCoding protocol which extends the NSCoding protocol.
An implementation which uses the NSCoding protocol is vulnerable to data being deserialized to a different object than what was expected by the developer, also referred to as an "object substitution attack" in Apple's documentation.
For more information, watch https://developer.apple.com/videos/play/wwdc2018/222/.
Steps to Reproduce
While the app is running on a physical device, this test checks for unsafe use of NSCoding and NSSecureCoding object deserialization.
Regardless of the use of NSCoding or NSSecureCoding, the use of unarchive*ObjectWithData and unarchive*ObjectWithFile (which are deprecated classes) instead of the unarchive*OfClass methods is indicated here.
Business Impact
Due to the way the app processes some information, it can be sent malicious data in order for an attacker to execute unintended commands.
Remediation Resources
Make sure you have adopted NSSecureCoding in the data you decode.
When writing a class that supports secure coding, ensure that the + (BOOL)supportsSecureCoding class property's getter returns true.
Ensure that all - (id)decodeObjectForKey:(NSString*)key calls are replaced with - (id)decodeObjectOfClass:(Class)c forKey:(NSString*)key.
Also avoid using the deprecated unarchive*ObjectWithData and unarchive*ObjectWithFile classes and implement unarchive*OfClass classes instead.
Refer to NSSecureCoding for further details.
Finding Description
When an application has some logic to receive arbitrary data (for example over the network) and to then de-serialize the data into an object, caution should be used when implementing this logic. If raw data can choose an arbitrary class as the the object it gets de-serialized to, this can lead to remote code execution.
In iOS applications, object deserialization/serialization is usually implemented using the NSCoding protocol, which allows the developer to implement the serialization logic for their own classes, or the NSSecureCoding protocol which extends the NSCoding protocol. An implementation which uses the NSCoding protocol is vulnerable to data being deserialized to a different object than what was expected by the developer, also referred to as an "object substitution attack" in Apple's documentation. For more information, watch https://developer.apple.com/videos/play/wwdc2018/222/.
Steps to Reproduce
While the app is running on a physical device, this test checks for unsafe use of NSCoding and NSSecureCoding object deserialization. Regardless of the use of NSCoding or NSSecureCoding, the use of
unarchive*ObjectWithDataandunarchive*ObjectWithFile(which are deprecated classes) instead of theunarchive*OfClassmethods is indicated here.Business Impact
Due to the way the app processes some information, it can be sent malicious data in order for an attacker to execute unintended commands.
Remediation Resources
Make sure you have adopted NSSecureCoding in the data you decode. When writing a class that supports secure coding, ensure that the
+ (BOOL)supportsSecureCodingclass property's getter returns true. Ensure that all- (id)decodeObjectForKey:(NSString*)keycalls are replaced with- (id)decodeObjectOfClass:(Class)c forKey:(NSString*)key. Also avoid using the deprecatedunarchive*ObjectWithDataandunarchive*ObjectWithFileclasses and implementunarchive*OfClassclasses instead. Refer to NSSecureCoding for further details.Risk and Regulatory Information
Severity: medium CVSS: 4.3
Application
See more detail in the NowSecure Report