NSCoding cyber security issue founding

[chopeace]

thanks for the contribution on your git. we are currently using it ; WebImage(url
However, we found that there is some cyber security issue(NSCodin) on your git repository and I just wonder if your organization have a plan to convert NSCoding to NSKeyedArchiver in a near future; if you have don't have any capacity to fix soon, it would be appreciated if you could response saying that you don't have plan on it now. Then, we could keep using your repository; otherwise, we have to drop it off unfortunately. Looking forward to hearing from your organization.

Thanks for your time and your contribution to our development community is crucial.
Best Regards,
Peace Cho.

Here is the founding

The NSKeyedArchiver or NSKeyedUnarchiver methods used by the App are insecure because they are incompatible with the NSSecureCoding protocol. An attacker-controlled payload that is deserialized via these APIs may result in attacker-controlled code being executed.

NSCoding is an Objective-C protocol that interoperates with NSKeyedArchiver and NSKeyedUnarchiver. Together, these APIs allow serialization and deserialization of code objects. However, the NSKeyedUnarchiver methods used by the app, and the NSCoding protocol itself, do not verify the type of object upon deserialization. Thus, an attacker may craft a malicious payload that results in unexpected code being executed.

To mitigate this vulnerability, Apple introduced the NSSecureCoding protocol along with the following secure methods of NSKeyedArchiver and NSKeyedUnarchiver, which are robust against this type of attack:

// Secure NSKeyedUnarchiver methods
- (instancetype)initForReadingFromData:(NSData *)data error:(NSError **)error;
+ (id)unarchivedObjectOfClass:(Class)cls fromData:(NSData *)data error:(NSError **)error;
+ (id)unarchivedObjectOfClasses:(NSSet<Class> *)classes fromData:(NSData *)data error:(NSError **)error;

// Secure NSKeyedArchiver methods
- (instancetype)initRequiringSecureCoding:(BOOL)requiresSecureCoding;
+ (NSData *)archivedDataWithRootObject:(id)object requiringSecureCoding:(BOOL)requiresSecureCoding error:(NSError **)error;

These APIs protect against object substitution attacks by requiring the programmer to declare the expected type of object before deserialization completes. Thus, if an invalid object is deserialized, the error can be handled safely.

Apple provides more information in the WWDC20 session, 'Securing Your App'.

here is the

Remediation Guidance

[dreampiggy]

You'd better transfer this issue to https://github.com/SDWebImage/SDWebImage/issues

For fixing

We don't know your Type of associated object. See 'sd_extendedObject' documentation

So, this need a API break changes (You, as a user, now need to pass extra params for SDWebImage with your Type/Class) and need SDWebImage 6.

[chopeace]

thanks for the response. I see that your latest SDWebImageSwiftUI git uses 5.19.1 that is not 6.
Any plan to upgrade to use SDWebImage 6 in your git repository? @dreampiggy

[chopeace]

just found that latest SDWebImage is 5.19.1( 6 does not exist). Do you guys know that when we use WebImage(url:); based on my search with sd_extendedObject, it said, "By default, if the image is cached, we do not send request to query new metadata.". the most important question is that whether SDWebImage use NSCoding or not by default when user use WebImage(url:)

[dreampiggy]

This API seems for advanced user. If you don't know what's that for, you will never trigger the NSCoding code

(which means, Your app will never has this security issue)

[dreampiggy]

Only when you use something like this one ( I guess no one except me use that): https://github.com/SDWebImage/SDWebImageLinkPlugin

It may trigger the NSCoding archive/unarchize cofe