####################################################################### Title: My policy: optimization of responsible disclosure 0.1 Author: Luigi Auriemma e-mail: aluigi@autistici.org web: aluigi.org ####################################################################### Introduction The Scheme ####################################################################### ============ Introduction ============ First of all this text doesn't want to be a paper but I have created it only for me to have a fixed scheme to use when I find a bug. It is focused on the time and on the speed of the patch releasing, more speed means faster fixes. I had this idea because I have noted that there are too much problems in the responsible disclosure that make it really poorly responsible so why we must continue to call it "responsible"? The responsible disclosure should consist not only in the finding and the reporting of a bug but is also needed that the author of the bug becomes an active part of the patching process. My idea so is a scheme with the target of rising the patching speed. In fact there is only one known method to improve this speed and is the releasing of the informations about the vulnerability publically, that will force the vendor to quickly move the ass and to take the problem more seriously but naturally this is not so good and responsible. This method has ever had positive effects (except some rare cases due the stupidity and the arrogance of the vendor) with lazy vendors but the keyword to be in-line with the responsible disclosure is the "equilibration". Comments and optimizations are welcome. ####################################################################### ========== The Scheme ========== What to do when we find a bug? ------------------------------------- Finding informations about the vendor ------------------------------------- We must contact who develops the vulnerable program (NOT who publish it) so we must first know the major number of e-mail addresses to successfully contact the right people. There are some sources to check: - vendor and product's homepage - websites that contain various vendors informations: http://www.neoseeker.com/Companies http://www.ugr.net/listings/listings.htm http://www.webdog.org/cgi-bin/showcompany.plm?company= others... - Google, the best way 8-) With a search engine we will be able to know also the e-mail addresses of some internal programmers so we will have more chances to be seen and to contact the specific people able to fix the bug --------------------- Contacting the vendor --------------------- Just when we have found the bug we can contact the vendor using the e-mail addresses retrieved with the previous operation. The best rule is: "more people contacted = more probabilities to be seen", so when we send a mail we must try to send it to at least 2 recipients (usually almost all the vendors have an info@ and a support@ mailbox). The important thing then is the number of mails, 3 is the perfect minimum number because we must be sure that the vendor receives or see at least one of our bug reports. Debugging informations are very important and useful so is better if we made a bit of debugging to find what causes the bug before contacting the vendor and possibly also locate the exact vulnerable code in the program. ----- Times ----- The time limit should be between one and two weeks (depended by the bug) in fact who doesn't reply within a week rarely will do in two. 2 weeks are also good to us for finding a possible work-around or retrieving other info about the vulnerability and the vendor. The 3 mails must be sent within the decided time ------------- It's the time ------------- If the vendor has not answered within the time limit means his product is no more supported, he has not seen our mails (impossible) or simply doesn't want to lost time with us (his worst choice). We must simply release all our informations to common security places (as Bugtraq) "specifying" that the vendor has not replied to our mails. Before releasing the informations is really an excellent idea to see if we are able to create a temporary work-around or a patch for the problem; this is possible with opensource programs but sometimes is also possible with closed-source programs but is needed a lot of testing to avoid contraindications so rarely suggested. ------------------- Vendor has answered ------------------- Although the vendor has answered we must not be too much happy... this is only the beginning. Now we should imagine the vendor as a lazy fat boy and us as a nuisance nerd because sometimes this is the real scenario 8-) ------------- Patching time ------------- Is important to decide a time limit for the releasing of the patch because a dangerous security bug MUST be quickly patched and who has developed the program know how to patch it. My suggestion is for one or two weeks (depending by the vulnerability) but we must remember that this time is dynamic so if the vendor needs (really needs) more time we can rise the number of days. Remember that patching a bug occupy just a bit of time if the developers are skilled and if we have provided all the informations. --------------------------- Important rule to remember! --------------------------- When you contact the vendor the first thing you must specify is to release a quick fix for the vulnerability and NOT to include the fix in the next planned patch. In fact some vendors usually decide to manage security bugs as normal bugs so are wasted some months. I repeat, we must specify the "quick fix" rule so the problem will be fixed in some days or also hours. --------- Nuissance --------- Is very useful to collaborate with the vendor for the patching of the bug if are needed some decisions about how to fix the bug or if is needed someone to test the new patch. But is also important to avoid that the vendor wastes time so we must try to don't lost the contact with him, we must request updates (what I call keep-alive mails) if the vendor doesn't give us too much info and we don't hear news by long time. -------------- Vendor'silence -------------- In the case the vendor we have successfully contacted will not continue to answer to our mails and requests of updates (complete silence also after a lot of our "keep-alive" mails) there is only one solution: look at the above section "It's the time". ---------------------- Delay before releasing ---------------------- When the bug is fixed is a good idea to wait some days before releasing the informations about the vulnerability so a major part of the users have the possibility to fix the problem. I think that a good idea is to wait at least 2 or 3 days but everything depends by the dangerousness of the security bug that has been fixed. A smaller delay means that people will probably know the existence of the bug and the patch soon and will update their program quickly. ---------------------- Other possible results ---------------------- When we release informations and proof-of-concepts about a vulnerability that has NOT been patched the vendor will have poor time to fix the problem so the target of the responsible disclosure (patching of the bug) will be reached, probably partially. In fact usually the vendor will be forced to do just what I have specified at the section "Important rule to remember!", so a specific fix for the specific bug (that is EVER the best choice). If the bug will not be patched (although it is public) means that the vendor is not interested to the vulnerable program or is really incredibly stupid... but this is not our problem. #######################################################################