Fix critical bug in symlink command handling found during testing
authorJacob Bachmeyer <jcb@gnu.org>
Sat, 29 Jan 2022 02:56:49 +0000 (20:56 -0600)
committerJacob Bachmeyer <jcb@gnu.org>
Sat, 29 Jan 2022 02:56:49 +0000 (20:56 -0600)
commitc4f8b99e11e3737266b17fbb24ee1b9bb73a2aaf
tree2ace361f26abc7aad6c2fdabb9fc85ce488eecfe
parente6f49e953f5ae2d557ec2e933886dcda759e0816
Fix critical bug in symlink command handling found during testing

Previously, while symlink targets were checked for the string "..", symlink
names were unchecked; this allowed symlinks to be placed outside of the
permitted areas for which the signing key is authorized and even outside of the
managed file tree, requiring only that the containing directory already exist.
The test case places a symlink directly into the top-level pub/ directory to
demonstrate the issue and confirm that it is fixed.

I consider this bug critical because while the rogue symlink can only refer to
something else at or below its own location, it could replace an existing
symlink.  While I do not expect that this provides any way to crack system
security, careful misuse could certainly cause considerable nuisance, possibly
breaking the entire system if an attacker can find a symlink that is critical
for the system's operation and replace it with a dangling symlink.
upload-ftp-v1.2.pl