• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • core

      The change made for JENKINS-72636 breaks scripted downloads with wget
      If you follow the documentation https://www.jenkins.io/doc/book/system-administration/authenticating-scripted-clients/#shell-with-wget and use the command

      wget --auth-no-challenge \
          --user=user --password=apiToken \
          http://jenkins.example.com/job/yourjob/lastSuccessfulBuild/artifact/build_record.txt

      wget will pass the username and password both for the initial request to the jenkins URL.
      Upon receiving the redirect to the resource URL, wget will again supply the BASIC authentication.

      The change made causes the download to fail with a 400 error and a cryptic error message in the logs `hudson.security.AccessDeniedException3: anonymous is missing the Run/Artifacts permission`

      Currently a work around is to use a `.netrc` so that the credentials are only sent for the main jenkins domain and not the resource subdomain

          [JENKINS-73422] JENKINS-72636 breaks scripted downloads

          Daniel Beck added a comment -

          Upon receiving the redirect to the resource URL, wget will again supply the BASIC authentication. 

          It is unclear how the URL to trigger a new build redirects to an artifacts resource root URL. Did you skip a bunch of steps in the middle, or provide a wrong URL?

          Daniel Beck added a comment - Upon receiving the redirect to the resource URL, wget will again supply the BASIC authentication.  It is unclear how the URL to trigger a new build redirects to an artifacts resource root URL. Did you skip a bunch of steps in the middle, or provide a wrong URL?

          Liam Baker added a comment -

          In fact the page contains no example for downloading an artifact using a script, only triggering a build.

          Let me fix that end point URL.

          What the script is doing is downloading an artifact created by the job using the API token.
          wget then passes the token to the resource URL e.g. resource.jenkins.domain/static-files/tJhSwZX....=/build_record.txt
          However when a request with an Authorization header is sent to the resource URL, Jenkins returns a 400 Error

          Liam Baker added a comment - In fact the page contains no example for downloading an artifact using a script, only triggering a build. Let me fix that end point URL. What the script is doing is downloading an artifact created by the job using the API token. wget then passes the token to the resource URL e.g. resource.jenkins.domain/static-files/tJhSwZX....=/build_record.txt However when a request with an Authorization header is sent to the resource URL, Jenkins returns a 400 Error

          [Authorization - HTTP | MDN|https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization#browser_compatibility] only mentions the following about redirects:

          > This header is stripped from cross-origin redirects.

          Here the host differs on redirect, so the header should be stripped automatically by clients.. But then looking at the clients implementation, it gets interesting.

          curl seem to have this default behavior of stripping the authorization header on redirect by default, though whatever the host in the redirection.

          curl - HTTP authentication leak in redirects - CVE-2018-1000007

          But wget for example does not, there is actually a CVE because it sends the Authorization header on redirection, whatever the host:

          NVD - CVE-2021-31879

          To sum up, curl is always stripping which is not actually necessary. curl is unaffected. wget is never stripping which is apparently a security issue.. In a way, clients that are affected probably are affected by a similar security issue.

          For the issue at stake, maybe we could revert the commit or maybe log a warning that Auth is used instead of failing the request ?

          Allan BURDAJEWICZ added a comment - [Authorization - HTTP | MDN|https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization#browser_compatibility] only mentions the following about redirects: > This header is stripped from cross-origin redirects. Here the host differs on redirect, so the header should be stripped automatically by clients.. But then looking at the clients implementation, it gets interesting. curl seem to have this default behavior of stripping the authorization header on redirect by default, though whatever the host in the redirection. curl - HTTP authentication leak in redirects - CVE-2018-1000007 But wget for example does not, there is actually a CVE because it sends the Authorization header on redirection, whatever the host: NVD - CVE-2021-31879 To sum up, curl is always stripping which is not actually necessary. curl is unaffected. wget is never stripping which is apparently a security issue.. In a way, clients that are affected probably are affected by a similar security issue. For the issue at stake, maybe we could revert the commit or maybe log a warning that Auth is used instead of failing the request ?

          Daniel Beck added a comment - - edited

          log a warning

          One of the more critical ways to exploit CVE-2024-23897 ("Remote code execution via Resource Root URLs (Variant 2)" in https://www.jenkins.io/security/advisory/2024-01-24/ ) requires sending requests like are being prohibited by JENKINS-72636, so I'd rather not revert it if the motivation is an unresolved CVE in a different tool.

          Having a system property escape hatch to opt out of protection should be fine though.

          (Prohibiting authenticated requests is only a workaround as well, the real solution would be a change to how resource root URL works, including changes to Stapler.)

          Daniel Beck added a comment - - edited log a warning One of the more critical ways to exploit CVE-2024-23897 ("Remote code execution via Resource Root URLs (Variant 2)" in https://www.jenkins.io/security/advisory/2024-01-24/ ) requires sending requests like are being prohibited by JENKINS-72636 , so I'd rather not revert it if the motivation is an unresolved CVE in a different tool. Having a system property escape hatch to opt out of protection should be fine though. (Prohibiting authenticated requests is only a workaround as well, the real solution would be a change to how resource root URL works, including changes to Stapler.)

          I see. Makes sense. I have proposed https://github.com/jenkinsci/jenkins/pull/9644.

          Allan BURDAJEWICZ added a comment - I see. Makes sense. I have proposed https://github.com/jenkinsci/jenkins/pull/9644 .

          Liam Baker added a comment -

          Thanks for the fix, we will wait for it to make it to LTS.
          I assume this is set as a JAVA opt at startup e.g.
          `-Djenkins.security.ResourceDomainRootAction.allowAuthenticatedUser=true` 

          Liam Baker added a comment - Thanks for the fix, we will wait for it to make it to LTS. I assume this is set as a JAVA opt at startup e.g. `-Djenkins.security.ResourceDomainRootAction.allowAuthenticatedUser=true` 

            allan_burdajewicz Allan BURDAJEWICZ
            sm__liam_baker Liam Baker
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: