huaweicloud / external-sfs Goto Github PK

/kind bug
What happened:
see
https://quay.io/repository/huaweicloud/sfs-provisioner/manifest/sha256:03252e558645dab00f9f2ee8f3a198bf0384dacd3dc6313f91801e8aa69caef0?tab=vulnerabilities

**BUG REPORT **:
/kind bug
What happened:
when a pvc for sfs is send
on the log of the pod I can see :
controller.go:1167] claim update received: MODIFIED default/sfs-pvc Pending
I0315 14:30:42.591766 1 leaderelection.go:215] succesfully renewed lease to provision for pvc default/sfs-pvc
I0315 14:30:42.949463 1 provisioner.go:90] Get share: 28bfc2ad-25e3-48af-96e4-9cb73639c5e2
I0315 14:30:43.378123 1 provisioner.go:97] Grant access: 28bfc2ad-25e3-48af-96e4-9cb73639c5e2
1 event.go:221] Event(v1.ObjectReference{Kind:"PersistentVolumeClaim", Namespace:"default", Name:"sfs-pvc", UID:"ca527663-472e-11e9-aa78-fa163ebd8fd7", APIVersion:"v1", ResourceVersion:"35339", FieldPath:""}): type: 'Warning' reason: 'ProvisioningFailed' Failed to provision volume with StorageClass "sfs": Failed to grant access: Invalid request due to incorrect syntax or missing required parameters.

On the Flexibleengine console I can see that the SFS volume is created but always as not avialable status and a new one is recreated until reach the quota limit exceed of sfs

What you expected to happen:
A PV should be created

This is a proposal than an issue, the name of this repository is fine as a project under kubernetes-incubator, but not clear here. to make the name clear, I suggest to change the repository name to following candidate:

1. k8s-external-huaweicloud-sfs
2. huaweicloud-k8s-external-sfs
3. huaweicloud-k8s-external-sfs-provisioner
4. ....

please feel free to reply your thoughts or any suggestion.

Is this a BUG REPORT or FEATURE REQUEST?:

I am deployed CFCR cluster on huawei cloud. Now, i need to attach sfs volume to it. Manually by using mount command on each worker i am able to mount voulme. but, when i am trying to deploy staefulset.yaml i am facing issue

What happened:
Events:
Type Reason Age From Message

Normal Scheduled 6m10s default-scheduler Successfully assigned default/sfs-provisioner-0 to vm-b24a5d70-158c-4667-9cbd-3744844e010b
Warning Failed 85s kubelet, vm-b24a5d70-158c-4667-9cbd-3744844e010b Failed to pull image "quay.io/huaweicloud/sfs-provisioner:latest": rpc error: code = Unknown desc = context canceled
Warning Failed 85s kubelet, vm-b24a5d70-158c-4667-9cbd-3744844e010b Error: ErrImagePull
Normal BackOff 85s kubelet, vm-b24a5d70-158c-4667-9cbd-3744844e010b Back-off pulling image "quay.io/huaweicloud/sfs-provisioner:latest"
Warning Failed 85s kubelet, vm-b24a5d70-158c-4667-9cbd-3744844e010b Error: ImagePullBackOff
Normal Pulling 71s (x2 over 6m8s) kubelet, vm-b24a5d70-158c-4667-9cbd-3744844e010b Pulling image "quay.io/huaweicloud/sfs-provisioner:latest"

and ultimately container goes in CrashLoopBackOff state.

What you expected to happen:
Generally Pod needs to be created and running.

Is there anything extra i need to do?

FEATURE REQUEST:
Could you tag/release the docker image ?
https://quay.io/repository/huaweicloud/sfs-provisioner?tab=tags
keep only 'latest' tag is not a good idea and should not be use in production env
please publish version with last PR as it contains cve fix.

Hello,

I am writing to report a potential Regular Expression Denial of Service (ReDoS) vulnerability or Inefficient Regular Expression in the project. This issue arises when specially crafted input strings are used in the context of distributed, high-volume requests, potentially leading to a denial-of-service attack.

Location of Issue:

The vulnerability is related to a regular expression used in the following validation file, which may result in significantly prolonged execution times under certain conditions.

PoC Files and Comparisons:

// Proof of concept
filename := os.Args[1]
content, err := ioutil.ReadFile(filename)
re := regexp.MustCompile("(?s)<(?:style|script)[^<>]*>.*?</(?:style|script)>|</?[a-z][a-z0-9]*[^<>]*>|<!--.*?-->")
re.ReplaceAllString(string(content), "")

PoC Files Here: poc.zip

To evaluate the performance of this inefficient regular expression matching with varying input contents, the following commands can be executed within the PoC folder:

time ./poc AttackString10MB.txt
# real    72m38.173s
# user    72m30.083s
# sys     0m5.653s
time ./poc RandomString10MB.txt
# real    0m0.029s
# user    0m0.016s
# sys     0m0.026s
time ./poc AttackString1MB.txt
# real    0m54.028s
# user    0m53.917s
# sys     0m0.088s
time ./poc RandomString1MB.txt
# real    0m0.011s
# user    0m0.007s
# sys     0m0.011s

The significant difference in processing time between random strings and malicious strings highlights the potential effectiveness of this regex for malicious exploitation. And as string length grows, the nonlinear increase in processing time reflects potentially greater risks.

Proposed Solution:

A possible mitigation strategy could include limiting the input length to prevent excessive processing times. If the corresponding function or feature is not in use, it is recommended to clean up risky third-party packages or code content to prevent malicious exploitation through methods such as code injection.

Additional Considerations:

Historically, it was believed that using regex engines with non-backtracking implementations (such as those in Rust or Go) would not lead to ReDoS vulnerabilities. However, recent studies have shown that this is not always the case. I recommend an assessment of how this issue might impact this project.

Thank you for your attention to this matter. Your evaluation and response to this potential security concern would be greatly appreciated.

Best regards,