March 27, 2013 Update: I wanted give you all an update to the App-ID cache pollution issue that was discovered earlier this year. First off, we should have managed this issue more effectively – we learned from the experience and we will be customer-focused in our comments moving forward. As promised back in January, the App-ID cache function in PAN-OS is no longer used for security policy.
- PAN-OS 5.0.2 and subsequent releases posted to support site on or after January 15, 2013.
- PAN-OS 4.1.11 and subsequent releases posted to support site on or after February 6, 2013.
We still recommend that you use the following security policy best-practices:
- For applications that you are enabling, you should assign a specific port (default or custom).
- For applications that you explicitly want to block, expand the policy to any port, to maximize the identification footprint.
For any further updates, please work with your local Palo Alto Networks sales team and channel partner.
Nir
The App-ID cache pollution blog entry elicited many responses – thanks for reading and showing significant interest. Some of the responses felt that this evasion technique had existed for more than two years and they questioned why we had not fixed it; other responses took issue with how we addressed the evasion technique and finally, some of the responses felt we were too emotional. Rather than try to reply to each individual response, we felt a general update would be more effective.
- The evasion technique is an old one. Several of you pointed out that this evasion technique is the same one shown two years ago at DevCon and CanSec West by Juniper. Yes, both techniques polluted the App-ID cache, but this variant used a different set of applications (Facebook and SIP) and a different set of conditions than the earlier variant (which used HTTP and SMTP). We made changes to PAN-OS to eliminate the earlier evasion, just as we will make changes to eliminate this variant. There will be those readers who feel we are splitting hairs, but our position is that the techniques used to evade the firewall, and the conditions required are quite different.
- The public manner in which we responded was wrong. Several responses felt that the public manner in which we responded was wrong – again, comparing it to the previous evasion. We believe that the level of response was commensurate with the level of visibility and impact. The previous evasion, published by Juniper at a developer forum (and eventually to YouTube), was made public a bit more quietly, in a forum where evasions are commonly discussed and our response was published at an equal level – quietly and quickly. In this case, our existing and prospective customers were sent a YouTube link to the new evasion by Check Point and other firewall vendors. They all wanted a response and we felt that the quickest way to give them access to a response was our public website.
- The response was too emotional. Finally, many of you felt we were too emotional and we were wrong with accusing Check Point of a practicing double standards by not following responsible disclosure. Yes, in hindsight, the stress of the holidays, the fact that many of my colleagues were on vacation and the volume of requests for a response influenced the reply. However, we do believe however that Check Point did not follow responsible disclosure processes. And again, there are differences between the previous evasion, which was published in an educational forum where these subjects are commonly vetted. The Check Point variant was published and marketed widely on YouTube, which we felt was inappropriate.
Hopefully, the information above will clarify our line of reasoning for how we responded. There will be those who continue to disagree with how we addressed this issue, and there will be those who will move on. Again, thanks for reading and thanks for your support.