Security Issue in Parsing XML using NSXMLDocument

[prathaps]

Hi Guys,

There is a security issue in the way Sparkle parses the xml. In the SUAppCast.m, in the:

• (void)downloadDidFinish:(NSURLDownload *)aDownload {
  ....

document = [[[NSXMLDocument alloc] initWithContentsOfURL:[NSURL fileURLWithPath:downloadFilename] options:0 error:&error] autorelease];
...
}

If the xml file being parsed contains a reference to an external entity, that entity would be parsed. For instance take this simple xml file:

]>

Tove
Jani
Reminder

Don't forget me this weekend!+&someEntity;

notice that someEntity is an external entity pointing to some file on disc. This file could be dangerous. In this case it is simply a text file. But the above code that parses the xml document would subsititute the contents of the file when parsing the element.

Please see details of this security risk in:

http://www.securityfocus.com/archive/1/297714/2002-10-27/2002-11-02/0

Instead if you use:

document = [[[NSXMLDocument alloc] initWithContentsOfURL:[NSURL fileURLWithPath:downloadFilename] options: options:NSXMLDocumentTidyXML error:&error] autorelease];

Notice the use of 'options:NSXMLDocumentTidyXML' instead of 'options:0', what you get after parsing is:

ToveJaniReminderDon't forget me this weekend!+&someEntity;

That is the external entity name has be quoted and hasn't been resolved.

My questions are:

1. Are you going to address this in your next patch? If so, when will it be released?

2. If not, can you please provide a way to make this change in the sparkle 1.5 without having to recompile sparkle? That is can we override some class in the application that is linking with sparkle framework to enable this secure xml parsing?

Thanks,

Prathap

[andymatuschak]

I am told that one should not use NSXMLDocumentTidyXML to ensure that these entities are stripped (it's essentially just luck that they are stripped out by the tidier), but that NSXMLParser will take care of this situation reliably. I will try to make time in the next few weeks to rewrite the appcast parsing implementation on top of NSXMLParser, but if it gets much closer to WWDC, I'll be underwater.

[prathaps]

Andy,

Thank you for your reply. It would be awesome if you can use NSXMLParser to patch the security hole. Please let me know when this is available. I will get back in touch with you in a few weeks!

Prathap

[andymatuschak]

Using NSXMLParser would have been more work than I could spare time for in the near future, but I think that's okay: while we are mostly just getting lucky that NSXMLDocumentTidyXML happens to strip out these entities, and that would not be a future-proof approach, there's a new NSXMLDocument option for 10.7+ (NSXMLNodeLoadExternalEntitiesSameOriginOnly) which we can use going forward. Old OS versions that happened to behave in the way we want will continue to behave that way.