The Java Deserialization Bug and NSSecureCoding

Charles Miller:

The problem, described in the talk the exploit was first raised in —Marshalling Pickles — is that arbitrary object deserialization (or marshalling, or un-pickling, whatever your language calls it) is inherently unsafe, and should never be performed on untrusted data.

[…]

This means that if there isany object reachable from your runtime that declares itself serializable and could be fooled into doing something bad by malicious data, then it can be exploited through deserialization. This is a mind-bogglingly enormous amount of potentially vulnerable and mostly un-audited code.

In Cocoa land, this is whywe haveNSSecureCoding. Some things to be aware of:

• If you’re decoding a collection containing custom classes, it’snot enough for them to conform toNSSecureCoding. You also have to use-[NSCoder decodeObjectOfClasses:forKey:] and add your classes to the set.

• Even when usingNSSecureCoding to check that you are decoding objects with the proper classes, you should still verify that the structure of the objects is correct.

• There’s a special (rather inconvenient) way that you need tocreate your archiver and unarchiver:

  tl;dr: don’t use-[NSKeyedArchiver encodeRootObject:] or-[NSKeyedUnarchiver decodeObject] in new code unless you need compatibility with Format 1 archives.

  Since+[NSKeyedArchiver archivedDataWithRootObject:] and+[NSKeyedUnarchiver unarchiveObjectWithData:] don’t give you an opportunity to call-setRequiresSecureCoding:YES, they’re out of the party as well.

  That leaves us with-[NSKeyedArchiver encodeObject:forKey:NSKeyedArchiveRootObjectKey] and-[NSKeyedUnarchiver decodeObjectForKey:NSKeyedArchiveRootObjectKey].

• Especially if you’re using Swift, you’ll need a top-level Objective-C wrapper to catch exceptions becauseNSCoder still doesn’t supportNSError. [Update (2015-11-08): See the comments below.] I have not tested what happens if a Swift class implementsinit(coder:) and an exception is raised.

Update (2015-11-10):Paul Kim:

Even if you don’t call-decodeObject:… in your-initWithCoder: you still have to implement+supportsSecureCoding and return YES in your class, even if a superclass already did it.

[…]

Objects like NSPredicate and NSSortDescriptor can take in key paths or selectors making them potentially unsafe. As a result, they are disabled after being securely decoded. To re-enable them, you have to call-allowEvaluation (presumably after doing some sort of check).

CocoaiOSJavaMacNSErrorObjective-CProgrammingPythonSecuritySwift Programming Language

2 CommentsRSS ·Twitter

- (nullable id)decodeTopLevelObjectAndReturnError:(NSError **)error;- (nullable id)decodeTopLevelObjectForKey:(NSString *)key                                     error:(NSError **)error;- (nullable id)decodeTopLevelObjectOfClass:(Class)aClass                                    forKey:(NSString *)key                                     error:(NSError **)error;- (nullable id)decodeTopLevelObjectOfClasses:(nullable NSSet<Class> *)classes                                      forKey:(NSString *)key                                       error:(NSError **)error;- (void)failWithError:(NSError *)error;

+ (nullable id)unarchiveTopLevelObjectWithData:(NSData *)data                                         error:(NSError **)error;

Leave a Comment

←  →

Support this site viaPatreon.

Try my Mac apps:

DropDMG
EagleFiler
SpamSieve
ToothFairy