Closed skkosuri-amzn closed 3 years ago
Merging #353 (ad05a3e) into main (8f1b7d5) will increase coverage by
0.69%
. The diff coverage is94.59%
.
@@ Coverage Diff @@
## main #353 +/- ##
============================================
+ Coverage 79.12% 79.82% +0.69%
- Complexity 199 213 +14
============================================
Files 151 151
Lines 5323 5342 +19
Branches 698 700 +2
============================================
+ Hits 4212 4264 +52
+ Misses 741 702 -39
- Partials 370 376 +6
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 8f1b7d5...792bb7f. Read the comment docs.
This pull request addresses a security issue in the Open Distro for Elasticsearch Alerting plugin on version 1.12.0.2 that allowed for server side request forgery. This made it possible for an existing Server Side Request Forgery in Open Distro for Elasticsearch (ODFE) 1.12.0.2, which allows an existing privileged user to enumerate listening services or interact with configured resources via HTTP requests exceeding the Alerting plugins intended scope. To address this, we added support to configure deny list of IP address and/or network ranges for web-hook destinations. For example, in elasticsearch.yml add the following option to deny webhook to all IP's in 10.0.0.0/8 network range and to localhost. "opendistro.destination.host.deny_list": "[\"10.0.0.0/8\", \"127.0.0.1\"]"
If it was SSRF security issue, wouldn't be good to assign an official CVE to it?
This pull request addresses a security issue in the Open Distro for Elasticsearch Alerting plugin on version 1.12.0.2 that allowed for server side request forgery. This made it possible for an existing Server Side Request Forgery in Open Distro for Elasticsearch (ODFE) 1.12.0.2, which allows an existing privileged user to enumerate listening services or interact with configured resources via HTTP requests exceeding the Alerting plugins intended scope. To address this, we added support to configure deny list of IP address and/or network ranges for web-hook destinations. For example, in elasticsearch.yml add the following option to deny webhook to all IP's in 10.0.0.0/8 network range and to localhost. "opendistro.destination.host.deny_list": "["10.0.0.0/8", "127.0.0.1"]"
If it was SSRF security issue, wouldn't be good to assign an official CVE to it?
Updating the thread to include reference to the CVE - https://nvd.nist.gov/vuln/detail/CVE-2021-31828
If it was SSRF security issue, wouldn't be good to assign an official CVE to it?
Thank you @p-rog , updated above thread to reference the associated CVE.
Issue #, if available: Support deny list for destinations
Description of changes: Support deny list for destinations. In elasticsearch.yml add the following option and the network ranges to deny for destinations.
"opendistro.destination.host.deny_list": "[\"10.0.0.0/8\", \"127.0.0.1\"]"
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or
(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.
(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.