Sahib Aulakh created YUNIKORN-1536:
--------------------------------------
Summary: 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
Fix For: 1.1.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: [email protected]
For additional commands, e-mail: [email protected]
