I have really, really mixed feelings about the whole “responsible disclosure” process. On the one hand, I don’t want uninformed users to have a greater chance of being attacked due to someone who has revealed the vuln to people who didn’t know it before, thus “putting a crowbar in their hands” in front of a plate glass window. Giving a publisher some time to correct the code and “immunize” their userbase against the vuln seems advantageous, but then again, anyone who would leverage the vuln might be of lesser moral character in the first place and disclose it to their cracker buddies anyway. This leaves the userbase subject to attack anyway. If someone discovers it and soon tells the world, the userbase may have mitigations against the attack until the publisher figures out how to fix it. This could save an awful lot of grief.
A lot of the discussion revolves around how much time is enough time. That is a VERY difficult question.
I have personally been in this position. See CVE-2004-1320 and the related CVE-2004-1321 (some trackers use the same message I wrote, and point to the paragraph which says the configuration backups show the credentials in plaintext). I mean, I was just futzing around with my config backup, wondering how the heck they might store the parameters, and here I see the strings “superuser” and “asante” in the hex-dump, as well as the administration username and password I set, and I wonder to myself, could they have been so stupid as to put a backdoor into their firmware? And indeed, yes, they were, because logging in with those worked.
As I recall, I waited more than a month. I figured, how long could it take Asante to bypass accepting these credentials and publish an update? Presuming they had nothing more urgent (and this seemed pretty urgent, because you could reboot the switch from this CLI, thus presenting a DoS condition), couldn’t it be wrapped up in a week or two? If I recall correctly, it took them OVER A YEAR to release v1.07. So in all that time, anyone with Telnet access to the switch could connect and repeatedly take it offline, leaving the poor user(s)/admin(s) scratching their head(s) as to why their switch is not working or constantly rebooting. At least in my (constructive) hacking, I discovered a mitigation strategy before disclosing the vuln which ANYONE could use protect themselves.