[ https://issues.apache.org/jira/browse/YUNIKORN-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Wilfred Spiegelenburg resolved YUNIKORN-1536. --------------------------------------------- Fix Version/s: 1.3.0 Resolution: Duplicate As part of YUNIKORN-1535 this is now done as all images are now scratch images > Avoid spurious Twistlock flags when scanning web package > -------------------------------------------------------- > > Key: YUNIKORN-1536 > URL: https://issues.apache.org/jira/browse/YUNIKORN-1536 > Project: Apache YuniKorn > Issue Type: Improvement > Components: webapp > Reporter: Sahib Aulakh > Priority: Minor > Fix For: 1.3.0 > > > Twistlock raises spurious CRITICAL issues when scanning web-1.1.0. Potential > amelioration to the issue is suggested in the discussion below by Craig. > > Twistlock scan of Yunikorn > This pertains to the CRITICAL issues surfaced by Twistlock on the YuniKorn > image. > h3. Question on Slack Channel > (https://yunikornworkspace.slack.com/archives/CLNUW68MU/p1673369962230479) > For a client in the financial industry, in order to use Yunikorn, we have to > pass the security scans from Twistlock > (https://www.cloudfoundry.org/the-foundry/twistlock/). Twistlock is currently > raising the following issues at CRITICAL level for the following images: > admission-1.1.0, scheduler-1.1.0 > ================================ > (1) https://nvd.nist.gov/vuln/detail/CVE-2022-37434 (zlib) > (2) https://nvd.nist.gov/vuln/detail/CVE-2022-2068 (libssl1.1, libcrypto1.1) > > web-1.1.0 > ========= > (3) https://nvd.nist.gov/vuln/detail/CVE-2022-42915 (libcurl, curl) > (4) https://nvd.nist.gov/vuln/detail/CVE-2022-32221 (libcurl, curl) > > I need some advice as to how to make progress here: > (a) For (1), is it sufficent to say that the API call inflateGetHeader is not > being made in YK code, so this issue is not relevant? Is it sufficient to > search for "inflateGetHeader" in YK sources to verify that the call is not > being made anywhere by YK code? I am assuming that the C programming API is > not being renamed somewhere. > (b) For (2), is it sufficent to say that the offending shell command > "c_rehash" is not being exercised anywhere in the YK code base? > (c) For (3), the offending command is curl before 7.86.0. Is it sufficient to > say that curl is not being exercised in the manner indicated in the CVE? > (d) For (4), again can we rule out this scenario for Yunikorn? > (e) Fixes for all these issues exist in later versions of zlib, libssl, > libcrypto, libcurl and curl. How much work is involved in switching to these > later versions of the libraries? I can supply the additional details here. > > (f) Finally, if I were to undertake this task and create git pull request, > can someone from YK team work with me and provide some basic guidance? I have > extensive programming experience but am new to Go. > h3. Response from Craig Condit from YuniKorn team > For #1 and #2 vulnerabilities, YuniKorn is not affected. The yunikorn > scheduler and admission controller components are the only things that run > within the generated containers, and both are static go executables which do > not make use of the affected libraries. It's likely they are being triggered > due to libraries / binaries included in the base alpine images. For #3 and > #4, the web image uses nginx internally, which does not use curl / libcur. > To prevent issues like #1/#2 in the future, we should probably look at moving > the scheduler images to use the scratch (basically empty) base image. This > would limit any potential surface area to the YK binary itself. For #3/#4, we > need nginx, so we'll need to keep updating to newer nginx-alpine images. -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org For additional commands, e-mail: dev-h...@yunikorn.apache.org