HN Explorer

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

6 points by remotebug ↗ HN
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.

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 "softwareproject Version 1.2.3 released" post.

When I posted some pretty angry comments about this, I was met with a mixture of understandable personal defense ("we do this in our free time, don't be so negative") and ignorance ("the users should take care about sandboxing and permissions themselves").

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.

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.

Looking around for some best practices on this, I came up blank.

How could the project have communicated the issue better? What are the commonly exercised best practices. Are there industry standards?

Thanks!

2 comments

[ 3.3 ms ] story [ 19.5 ms ] thread
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.