Disclosing a directory traversal vulnerability in Kubernetes copy

The number scheme changed around 2014 when the numbers started getting close to -9999

https://cve.mitre.org/cve/identifiers/syntaxchange.html

Might as well add a massive 1000 prefix when upping the number of digits to catch truncating bugs early (seeing a bunch of 1000 is more obvious than if just the last of 5 digits is dropped)

there is a good justification for running tar inside the container to implement copy. if you don't run code inside the container then the code outside the container would be used to implement the copy. in this case when code outside the container is tricked to read/write files the situation is still bad because it doesn't require tricking a higher privileged kubectl operator in order to escalate access. a lower privileged kubectl operator can read/write any file. depending on whether you have lower privileged kubectl operators this situation can be worse than the other situation.

it can be stopped by running the 'outside' code in the containers namespace (or writing correct code.). but this is tricky. if you use the containers pid namespace, then the container can inject into your process and you have the same problem. i believe this mistake has been made in the past. also, if you are using hypervisor based isolation then this is not an option.