Bug 1859331 - OpenShift 4.4.5: Directory listings allowed for "downloads" route
Summary: OpenShift 4.4.5: Directory listings allowed for "downloads" route
Keywords:
Status: VERIFIED
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Management Console
Version: 4.4
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: 4.6.0
Assignee: W. Trevor King
QA Contact: XiaochuanWang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-07-21 17:53 UTC by jteagno
Modified: 2020-09-17 02:16 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github openshift console-operator pull 457 None closed Bug 1859331: manifests/07-downloads-deployment: Create index.html 2020-09-15 12:23:31 UTC
Github openshift console-operator pull 464 None closed Bug 1859331: Fix downloads index 2020-09-15 12:23:33 UTC

Description jteagno 2020-07-21 17:53:07 UTC
Description of problem:

The "downloads" route exposed by the openshift-console allows directory listings.

A customer has identified this is a vulnerability requiring remediation.


Version-Release number of selected component (if applicable): Openshift 4.4.5


How reproducible: every time


Steps to Reproduce:
1. Browse to the "downloads" route, https://downloads-openshift-console.apps.FOO.BAR/

Actual results:

Confirm that a directory listing is served.


Expected results:

No directory listing is served.


Additional info:

$ OPENSHIFT_CONSOLE_DOWNLOADS_ROUTE="$(oc -n openshift-console get route/downloads -o jsonpath='{"https://"}{.spec.host}{"\n"}')"

$ echo $OPENSHIFT_CONSOLE_DOWNLOADS_ROUTE 
https://downloads-openshift-console.apps.FOO.BAR

$ curl -k $OPENSHIFT_CONSOLE_DOWNLOADS_ROUTE 
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html>
<title>Directory listing for /</title>
<body>
<h2>Directory listing for /</h2>
<hr>
<ul>
<li><a href="amd64/">amd64/</a>
<li><a href="arm64/">arm64/</a>
<li><a href="ppc64le/">ppc64le/</a>
<li><a href="s390x/">s390x/</a>
</ul>
<hr>
</body>
</html>

Comment 10 XiaochuanWang 2020-08-05 03:07:55 UTC
Will check on latest version (later than 4.6.0-0.nightly-2020-08-04-210224)

Comment 11 W. Trevor King 2020-08-05 04:35:01 UTC
Why recheck, this is still ASSIGNED, and has, to my knowledge, no attempt at implementing a fix yet.  If someone else has implemented a fix, please remove me as the assigned dev :).  Otherwise I hope to get around to this this week.

Comment 16 Yadan Pei 2020-08-25 02:21:54 UTC
a test case is attached and will be automated

Comment 18 W. Trevor King 2020-08-26 21:12:26 UTC
Going with "no docs needed", because this is a small security guard to an out-of-the-way place.  Explaining that we are closing a possible data-leak against admins who exec into the downloads pod and drop sensitive content onto the disk under the served directory tree, seems... like it would be more distracting than useful.

Comment 23 XiaochuanWang 2020-09-01 03:46:43 UTC
Checked on 4.6.0-0.nightly-2020-08-31-224837

From CLI: 
$ curl -k https://downloads-openshift-console.apps.xxia91aws.qe.devcluster.openshift.com/
<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
</head>
<body>
  <ul>
  <li><a href="oc-license">license</a></li>
  <li><a href="amd64/linux/oc">oc (amd64 linux)</a> (<a href="amd64/linux/oc.tar">tar</a> <a href="amd64/linux/oc.zip">zip</a>)</li>
  <li><a href="amd64/mac/oc">oc (amd64 mac)</a> (<a href="amd64/mac/oc.tar">tar</a> <a href="amd64/mac/oc.zip">zip</a>)</li>
  <li><a href="amd64/windows/oc.exe">oc (amd64 windows)</a> (<a href="amd64/windows/oc.exe.tar">tar</a> <a href="amd64/windows/oc.exe.zip">zip</a>)</li>
  <li><a href="arm64/linux/oc">oc (arm64 linux)</a> (<a href="arm64/linux/oc.tar">tar</a> <a href="arm64/linux/oc.zip">zip</a>)</li>
  <li><a href="ppc64le/linux/oc">oc (ppc64le linux)</a> (<a href="ppc64le/linux/oc.tar">tar</a> <a href="ppc64le/linux/oc.zip">zip</a>)</li>
  <li><a href="s390x/linux/oc">oc (s390x linux)</a> (<a href="s390x/linux/oc.tar">tar</a> <a href="s390x/linux/oc.zip">zip</a>)</li>
</ul>
</body>
</html>


Console display the route as index page looks the same (with links):
license
oc (amd64 linux) (tar zip)
oc (amd64 mac) (tar zip)
oc (amd64 windows) (tar zip)
oc (arm64 linux) (tar zip)
oc (ppc64le linux) (tar zip)
oc (s390x linux) (tar zip)

@jteagno Could you take a look at the current fix? I think this could be Verified.

Comment 24 jteagno 2020-09-01 13:47:35 UTC
(In reply to XiaochuanWang from comment #23)
> @jteagno Could you take a look at the current fix? I think this could be
> Verified.

Thanks!  Looks good to me.  This can be considered verified.

Comment 25 XiaochuanWang 2020-09-02 00:59:18 UTC
Thanks!
Moving to Verified on 4.6.0-0.nightly-2020-08-31-224837

Comment 27 W. Trevor King 2020-09-16 23:22:22 UTC
4.4 and earlier are in maintenance phase [1], so I don't think we need to backport this low-priority fix that far.  I'm agnostic about whether this gets picked back to 4.5 or not.  I have a really hard time imagining someone accidentally exec'ing into these containers and writing sensitive content to disk.  But the backport wouldn't be that hard either.

[1]: https://access.redhat.com/support/policy/updates/openshift#dates

Comment 28 Yaakov Selkowitz 2020-09-17 02:16:29 UTC
If there is need, 4.5 cherry-pick with squashed fixes: https://github.com/multi-arch/console-operator/commit/83cf1c8dfde1568881fb9da4f0a52810d33a9853


Note You need to log in before you can comment on or make changes to this bug.