Among other things I also deal with product vulnerabilities that are reported to us. It's great to be able to work with other security researchers as it allows us to make our products safer and get to know some great people out there. Most of the more "reputable" people and organizations that report vulnerabilities follow some variation of Rain Forest Puppy's "Full Disclosure Policy", which is a good framework for professional researchers and vendors to work together.
While investigating a very recent CAB/RAR scan bypass vulnerability reported to us I came across a post by kurt that links to a sales presentation by n.runs.
Imagine my surprise when I download the presentation and find out that n.runs has already publicly disclosed details of the very same vulnerability it has reported to us not even a week ago and which we're still researching. In their sales presentation they even use this vulnerability as their main argument on why you should buy their product!
Researchers normally release timelines in their disclosures. I think it's a good thing as it allows people to see how slowly or rapidly a vendor deals with reported vulnerabilities. This gave me an idea on how to clearly show the chain of events in this incident:
Nov. 6: n.runs initial vulnerability report and PoC to Panda
Nov. 7: Panda acknowledges receipt and starts investigating
Nov. 13: n.runs publicly discloses Panda as vulnerable
Nov. 16: Panda sends comments on vulnerability and PoC to n.runs
Nov. 16: n.runs responds to Panda comments (fails to mention the issue is already public)
Nov. 21: Panda sends final response to n.runs
I guess this serves as an example of a "specially crafted sales pitch may bypass your very own disclosure policy" vulnerability 🙂
Comments?
4 comments
Pedro is normal publicity, nruns is a new security company, the problem is another, nruns discredits other security companies for their convenience, is business
Cheers
How ironic! It’s a good thing that you discovered this and I hope that the vulnerability has been addressed already.
I haven’t been able to get Panda Anti-Rootkit to scan successfully past the 2nd step (windows registries I think it is) for months! Anyone have any idea how to go about fixing this? I’ve redownloaded it twice and thats about all the idea’s I’ve been able to come up with.
Thanks for the comments lucass and s. The “vulnerability” consists of prepending an MZ header to a compressed file. In fact you can also add a JPEG or TIFF header (even a complete image!) and WinRAR will still open it, as it searches for the compressed identifier in the first 500kb of each file. Of course parsing this for each file has tremendous impact and is not necessary as our products would catch this as soon as Winrar tried to execute the compressed file.
But this is all now a moot point. After all the back and forth in kurt’s blog and correspondence, it turns out that n.runs didn’t discover this vulnerability after all. It was discovered in 2005 by someone else. N.runs has now corrected their presentation to point this out.
Chris, I’m assuming you’re on Windows 2000, right? This is a known problem with Panda Anti-Rootkit under Win2k. Will be fixed in version 2.0.