[
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
