Add security policy #2245
Add security policy #2245
Conversation
SECURITY.md
Outdated
|
|
||
| You may submit the report in the following ways: | ||
|
|
||
| - send an email to ???@???; and/or |
There was a problem hiding this comment.
Sure thing! Would you want to adopt the GitHub reporting tool, then? (See #2244 for instructions on how to enable it for the repo) Or would you rather use an external website (we used the Chromium bug tracker in emscripten-core/emsdk#1224, don't know if that'd be reasonable here as well)?
There was a problem hiding this comment.
I have modified the policy to use GitHub's tool for now, let me know if you'd rather use something else.
There was a problem hiding this comment.
Sounds good.
Honestly, I'm afraid to say we have a lot of open CVE's from clusterfuzz and other places and our approach today is to pretty much ignore them. This is because wabt is mostly used on trusted inputs.
There was a problem hiding this comment.
I mean, the simplest/easiest thing would be to just say, "Our security policy is: if you find a security hole, please open a GitHub issue and our volunteers will take a look." and acknowledge that we're not at a point of maturity-with-regard-to-adversarial-input where private reporting and embargo periods make sense yet. That way we would have a security policy (fixing #2244) but everything would stay the same.
Hopefully if things continue going well, in a year or two we'll be fuzz-bug-free and maybe have some more critical downstream dependencies where a more "professional"/coordinated security-response process becomes worth it.
There was a problem hiding this comment.
What you describe I suppose is possible. In the same way that clang or gcc might take a trusted .c file and compile it to include at exploit. There types attacks where a compiler acts maliciously have been talked about but I'm not sure they have ever been found in the wild. I think Ken Thompson for talked about his stuff back in 1984! : https://wiki.c2.com/?TheKenThompsonHack.
But, as you say, those types of attacks are not detectable by fuzzing, so that doesn't motivate us to spend a lot of time fixing each and every fuzz bug.
Furthermore, the risk of gcc or clang injecting malicious code is way highter than it is for wabt since the output of wabt will always be running inside a sandbox so there its much hader to performs interesting exploits. i.e. the blast radius of any exploit is limited to the code running in the sandbox.
There was a problem hiding this comment.
How do clang and gcc deal with security issues like this?
There was a problem hiding this comment.
I honestly couldn't find info on gcc, but clang asks to report bugs to the LLVM page of the Chromium bug tracker.
There was a problem hiding this comment.
FWIW, here is the GCC/GNU position, which sounds similar to LLVM: https://gcc.gnu.org/bugs/ & https://www.gnu.org/software/security/
For WABT, I think my preference would be that we don't need to write down an exact policy of what we consider to be the "in scope" for security bugs right now -- that seems like needless effort. If we need to have a policy, let's just tell people to report bugs on the issue tracker (similar to GCC/LLVM) and move on.
For our own uses, we would like WABT to perform correctly (and not crash) even on adversarial inputs, so I'd love to get the bug reports when this doesn't happen---I don't want to be telling the reporters of those bugs to go away. :-)
There was a problem hiding this comment.
Ah, didn't occur to me to look at GNU's security policy!
I'd just like to note that both GCC and LLVM do offer some advice on how to send private reports:
- I wasn't clear in my last comment, but clang asks that vulnerabilities be reported in the Chromium bug tracker with a "security bug" label, which makes the bug private.
- GNU suggests sending emails directly to maintainers if you're concerned you may have found a sensitive vulnerability.
|
I revised the SECURITY.md to reflect what seemed (?) to be the consensus here. If no objections, I'll hope to merge in a week or so... |
keithw
force-pushed
the
security_policy
branch
from
5988b89
to
a4061d6
Compare
|
No objection heard; merging now. We can move to a system of private reporting if resources permit in the future. |
Signed-off-by: Pedro Kaj Kjellerup Nacht <[email protected]>
Signed-off-by: Pedro Kaj Kjellerup Nacht <[email protected]>
keithw
force-pushed
the
security_policy
branch
from
a4061d6
to
5058cc6
Compare
Fixes #2244.
As described in the issue above, this PR adds a security policy to the repository.
The policy currently allows private reporting to either an email (currently a placeholder) or using GitHub's private reporting tool. If you'd rather use just one of these (or something completely different like an external website), let me know and I'll change the policy.