

Ask HN: How to communicate security issues to the community of software project - remotebug

Some project recently had an issue that let remote, unauthenticated users read any file from the server it ran on as long as user permissions did not interfere.<p>The fix to that issue was implemented in a reasonable time frame but the release was not specially advertised. Instead the mention was inside the body of a generic &quot;softwareproject Version 1.2.3 released&quot; post.<p>When I posted some pretty angry comments about this, I was met with a mixture of understandable personal defense (&quot;we do this in our free time, don&#x27;t be so negative&quot;) and ignorance (&quot;the users should take care about sandboxing and permissions themselves&quot;).<p>The software is widely deployed on government systems and companies all over the world. Randomly sampling Google results gave me more vulnerable servers than not.<p>I feel that the project misses the severity of this issue and neglects the security of its users. I want to make sure they understand this and how to prevent similar problems in communication in the future.<p>Looking around for some best practices on this, I came up blank.<p>How could the project have communicated the issue better? What are the commonly exercised best practices. Are there industry standards?<p>Thanks!
======
davismwfl
I don't think there are really any industry standards, but there are common
practices that you can see from good companies and projects.

I think this project is likely one or more of these 1: fearful of what full
disclosure could do, 2: ignorant to the severity of the issue, 3: feel you are
over stating the risk. Any of the 3 should still be managed if they want to be
taken seriously. If #1 is it, they should realize it is worse to bury it in
the details as someone will point it out sooner or later. #2, well, that's
just not good and they should have been asking lots of questions. #3, they
should discuss it with you to try to make sure they have understood what you
found fully and attempted to convince you why it isn't as severe as you think
it is.

The good projects/companies I see that handle these things well is put it out
there and are quite blunt about it, read any security bulletin from Microsoft
etc. You don't have to be so blunt you scare people away from your software,
but you must be honest with the risk it poses so that people using the
software feel informed enough to weigh the risk or compelled to update to the
latest release etc. Or so that they know how to mitigate it through proper
configuration etc.

You could take an approach to put out a blog post etc how to mitigate the
issue, and discuss the issue without bashing the project or its maintainers.
If it is something that is used quite frequently as you say, you will be
helping the community even if the project maintainers still aren't being
honest enough. But I don't see it as your job to bash them, just to help the
community understand the issue, know there is a patch and also that proper
permission settings mitigate the risk to a certain degree.

------
sarciszewski
If the fix is implemented, wait a reasonable amount of time, then post the
vulnerability to the Full Disclosure mailing list.

If they feel that they don't have to advertise the security fix, it becomes
your privilege to decide how it gets advertised.

