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 is any 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 why we have NSSecureCoding. Some things to be aware of:

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

• Even when using NSSecureCoding 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 to create 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 because NSCoder still doesn’t support NSError. [Update (2015-11-08): See the comments below.] I have not tested what happens if a Swift class implements init(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).

Cocoa iOS Java Mac NSError Objective-C Programming Python Security Swift Programming Language

2 Comments RSS · 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