ompi
ompi copied to clipboard
open-mpi
BlackDuck raises high security issue in libopen-pal.so.40.30.2 against libevent 2.0.21
Background information
What version of Open MPI are you using? (e.g., v3.0.5, v4.0.2, git branch name and hash, etc.)
v4.1.x
BlackDuck raises high security issue in libopen-pal.so.40.30.2 against libevent 2.0.21. Maybe it should be updated to newer version?
See #10565 and #10542 -- a PR which back-ports the fixes (even though Open MPI doesn't use any of the CVE-affected code).
@artemry-nv A few questions for you:
- This CVE is several years old. Do you know how/why it happened to come up now?
- What version of libopen-pal.so.40.32.2 -- is that Open MPI v4.1.4?
- Do you know how BlackDuck found this -- is it flagging the fact that Open MPI is linking against libevent 2.0.21? Or is it something deeper?
See #10565 and #10542 -- a PR which back-ports the fixes (even though Open MPI doesn't use any of the CVE-affected code).
@artemry-nv A few questions for you:
- This CVE is several years old. Do you know how/why it happened to come up now?
- What version of libopen-pal.so.40.32.2 -- is that Open MPI v4.1.4?
- Do you know how BlackDuck found this -- is it flagging the fact that Open MPI is linking against libevent 2.0.21? Or is it something deeper?
As far as I see the issue exists quite a long period (was ignored before). We use Open MPI v4.1.x (1c67bf1c6a156f1ae693f86a38f9d859e99eeb1f). Not sure how BlackDuck found this (suspect that it tries to find any versioning reference). If it's unable to find version it raises an issue and you need to specify version manually.
@artemry-nv What I'm trying to determine is whether PR #10565 will fix the issue. I.e., if we patch the existing Libevent 2.0.21 source code, will Black Duck still complain (because it's just looking at the Libevent version number, and not the actual source code)? Or is Black Duck looking at the source code, and it will see the patches, and therefore #10565 will resolve the issue.
Can you test applying the patches on #10565 and see if Black Duck still complains about the CVE?
Also, what is the urgency level of this for Nvidia? Per the discussion on #10565, the CVE does not affect Open MPI (because we don't use those parts of Libevent at all). Do you have customers complaining about this CVE? Or is this just something you happened to notice in a Black Duck report?
@artemry-nv What I'm trying to determine is whether PR #10565 will fix the issue. I.e., if we patch the existing Libevent 2.0.21 source code, will Black Duck still complain (because it's just looking at the Libevent version number, and not the actual source code)? Or is Black Duck looking at the source code, and it will see the patches, and therefore #10565 will resolve the issue.
Can you test applying the patches on #10565 and see if Black Duck still complains about the CVE?
Also, what is the urgency level of this for Nvidia? Per the discussion on #10565, the CVE does not affect Open MPI (because we don't use those parts of Libevent at all). Do you have customers complaining about this CVE? Or is this just something you happened to notice in a Black Duck report?
We'll try the patch. I suspect BlackDuck just parses version info. Regarding the urgency, taking into account it's quite old issue and the justification that known libevent CVE more likely doesn't impact Open MPI, so I'd say it isn't urgent.
Checked BlackDuck details also: libevent 2.0.21
| Identifier | Overall Score | Status | CWE | Exploit | Workaround | Solution |
|---|---|---|---|---|---|---|
| NVDCVE-2015-6525 | 7.5High | New | CWE-189 | – | – | |
| NVDCVE-2014-6272 | 7.5High | New | CWE-189 | – | – | |
| BDSABDSA-2017-2645(CVE-2016-10197) | 4.8Medium | New | CWE-416 | – | ||
| BDSABDSA-2017-2642(CVE-2016-10196) | 4.8Medium | New | CWE-121 | – | ||
| BDSABDSA-2017-2644(CVE-2016-10195) | 4.8Medium | New | CWE-205 | – |
Short Term Upgrade Recommendation [release-2.0.22-stable] Has no known vulnerabilities Long Term Upgrade Recommendation [release-2.0.22-stable] Has no known vulnerabilities
@artemry-nv Can you clarify your last comment -- does that mean you tried applying the patch and BlackDuck still reported the 5 CVEs?
@artemry-nv Can you clarify your last comment -- does that mean you tried applying the patch and BlackDuck still reported the 5 CVEs?
Not yet tried, will try shortly.
@janjust @artemry-nv Could really use an answer from NVIDIA here -- it's been almost 4 weeks.
@janjust @artemry-nv Hey NVIDIA. Can someone please reply? I've been asking for a reply since August 2. It's pretty rude to publicly post about a CVE and then not follow up about it.
@janjust @artemry-nv Hey NVIDIA. Can someone please reply? I've been asking for a reply since August 2. It's pretty rude to publicly post about a CVE and then not follow up about it.
Hi Jeff, Sorry for the delay. What is the actual version of the fix? PR https://github.com/open-mpi/ompi/pull/10602?
@artemry-nv Please see https://github.com/open-mpi/ompi/issues/10583#issuecomment-1192474466.
@artemry-nv Please see #10583 (comment).
Thanks, started Blackduck scanning - if everything is OK, we'll see the results tomorrow. Again sorry for the inconvenience.
@artemry-nv Please see #10583 (comment).
As far as I see BlackDuck still reports about libevent 2.0.21 findings - now there's 1 match instead of 2 previously.
@artemry-nv Can you share a little more information? Your July 23 comment on this issue (https://github.com/open-mpi/ompi/issues/10583#issuecomment-1193143273) showed a table with 5 rows -- are those what you are calling "matches"?
And just to be clear, you're saying that you applied the patches from #10565, ran the scanner, and Black Duck is still reporting 1 match (which assumedly means it found a vulnerability), right? If that's the case, and before you applied the patch, it found 2 matches, then Black Duck is not just looking at the Libevent version number and is actually scanning the Libevent source code. Is the 1 remaining match a CVE that we need to care about / is it fixed upstream such that we can back-port the fix to make the CVE go away?
Can you share a little more information? Your July 23 comment on this issue (https://github.com/open-mpi/ompi/issues/10583#issuecomment-1193143273) showed a table with 5 rows -- are those what you are calling "matches"?
No, these are issues in libevent 2.0.21 known to BlackDuck.
And just to be clear, you're saying that you applied the patches from https://github.com/open-mpi/ompi/pull/10565, ran the scanner, and Black Duck is still reporting 1 match (which assumedly means it found a vulnerability), right? If that's the case, and before you applied the patch, it found 2 matches, then Black Duck is not just looking at the Libevent version number and is actually scanning the Libevent source code. Is the 1 remaining match a CVE that we need to care about / is it fixed upstream such that we can back-port the fix to make the CVE go away?
We tried https://github.com/BrendanCunningham/ompi/tree/libevent/10542-cve-fixes-v4.1.x and https://github.com/open-mpi/ompi/commits/v4.1.x (https://github.com/open-mpi/ompi/commit/0d8b7375c7df8d65f4ce8d2c333d1badd33306bc) - BlackDuck still reports that ompi/lib/libopen-pal.so.40.30.2 uses libevent 2.0.21 with known vulnerabilities. Please ignore about 1/2 matches - previously it seems it was scanned twice. BlackDuck calls its findings "match" - it means that it found ompi/lib/libopen-pal.so.40.30.2 linked with libevent 2.0.21.
@artemry-nv When you applied the Brendan Cunningham fixes, did Black Duck identify fewer vulnerabilities in Libevent 2.0.21?
Or does it not matter whether the Brendan Cunningham fixes are applied or not -- Black Duck just says "I found Libevent 2.0.21, and it is known to have CVEs" (but does not provide any details).
I'm trying to determine whether Black Duck is actually scanning the source code (and we could just apply patches to fix the known problems), or whether Black Duck is solely looking at the Libevent version number.
@artemry-nv When you applied the Brendan Cunningham fixes, did Black Duck identify fewer vulnerabilities in Libevent 2.0.21?
No, found the same issues. There were some duplication of the same issues counted twice (specificities of our BD scanning), so I might a bit confuse you initially.
Or does it not matter whether the Brendan Cunningham fixes are applied or not -- Black Duck just says "I found Libevent 2.0.21, and it is known to have CVEs" (but does not provide any details).
Yes, something like this.
I bet it just looks for version info and raises CVEs known to the detected version. For example, we observed that BD wasn't able to detect version for some components and we have to define it manually.
Well, shoot. Ok, thanks. Per your July 23 comment, this isn't particularly urgent for Nvidia. Will have some offline discussions to decide what to do here.
Given that there's effectively no risk to our customers, and given that updating from libevent 2.0.21 to something newer in the v4.1.x release series turned out to be a pain in the butt, we decided to not fix this (beyond the patches that actually fix the CVE).
