Craig Hockenberry:
The href points to an SVG file and the color is used to draw the vector shape contained in the file (the background color for the tab changes depending on whether the browser window is active and if it’s selected.)
The documentation states that the graphic should be a vector shape filled with black. In our first test, we used a fill color that wasn’t black: the image is used as a mask, so the opacity of a filled shape is the only thing that matters. Any opacity in the shape’s fill color will be used, but we don’t recommend using it (and you’ll see why in just a second.)
[…]
Of course, at such a small size, a hand-tuned bitmap graphic would be a better choice.
[…]
It’s our guess that the company has other plans for these files. They currently only appear in pinned tabs, but as more sites support this new style of “favicon”, it’s likely that they’ll make their way into lists for browser history or frequently visited sites.
[…]
Of course you’ll want to preview your work as you tune your vectors. Safari caches the SVG files, so it takes a bit of effort to clear the old data and see your changes.
Design Favicons Graphics Mac Mac OS X 10.11 El Capitan Safari SVG Web
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
