Responsible disclosure

Nov 09, 2010 17:26

I released my post-FA-debacle list of security vulnerabilities 23 days ago. Since then, only one person on FA staff has approached me about the list; this person is neither a technical contact nor a high-tier administrator, and he only asked vaguely about the admin panel CSRF exploit.

So, the question has become more relevant.

How should disclosure work?

I never gave a date on which I'd explain the exploits, because frankly it didn't occur to me to ever do so. But is it a good thing to do?

On the one hand, if I explain bugs in a product, other people very well may exploit them. In the immediate sense, this puts the userbase at more risk.

On the other hand, there's nothing stopping enterprising parties from finding and abusing these problems right now. Or three weeks ago. Or three years ago. And there seems to be no incentive to fix these problems-or prevent their recurrence-except for them all, individually, to be exploited.

I've listed everything I know about. I've offered advice to the lone dev when he talks about this stuff. I went so far as to explicitly offer (uh, somewhere) to patch the holes myself, though at this point my interest in doing so has considerably waned.

And still, not a single hole I listed last month has been patched. Instead, a colleague just pointed out a new one to me, which would allow for ★★☆ CSRF session hijacking. That means: with minor social engineering, anyone could gain access to an admin account.

I'm not interested in spite or retribution or squabbling. I'm interested in the optimal course of action, and it's not obvious to me. Declare a date, reveal the details of the exploits when it comes, and let nature take its course; or stop caring and let nature take its course. Hm.

security, furaffinity, geeky

Previous post Next post
Up