Inconsistent reading of XML leading to an Apple iOS 0 day
Ensuring that different programs follow the same specifications when parsing input is crucial to avoiding vulnerabilities. Without this alignment, critical weaknesses can lead to vulnerabilities in your product. Allocate the appropriate time to check this feature as your developers could be writing code without bugs (implementation errors) but still have flaws (design errors).
This is demonstrated in a blog post by Siguza regarding XML and iOS. It reminds us that sometimes weaknesses are not in a specific piece of code or executable but in how multiple executables interpret the same inputs which can cause them to behave differently. We enumerate these situations with the entries CWE-436: Interpretation Conflict and CAPEC-153: Input Data Manipulation. This is where your proxy and/or security appliance reads HTTP requests differently than a back-end server.
This kind of problem goes back to at least 1998 with the classic Newsham/Ptacek paper on evading the intrusion detection system. This attack sent crafted packets that followed the specification but were reassembled by the target server in different way than the IDS did. This caused the IDS to misinterpret the actual network traffic. This also occurred in the X.509 Null Char Exploit where different applications (apps) handled a null character differently in multiple apps which led to the ability to spoof SSL certificates.
In the Siguza blog, he noticed that there were three different pieces of code that read XML files to give permissions to iOS apps, and they do not always agree. This could be leveraged by an advisory to provide elevated permissions to an iOS app that were greater than intended. Ultimately, he could generate a signed profile from Apple allowing for sandbox bypass that gave the program access and control all data from all apps.
When looking at an ecosystem where input needs to be read multiple times, consider using the same library to make sure that they are all in sync. If this is not possible, consider fuzz testing the tools to make sure that they give the same output under varied circumstances.
