Usernames on multiple operating systems (especially ones which are AD-joined) support "." in [long] usernames. Unfortunately, userspec.c treats "." like a user/group separator for unclear legacy reasons. This is very problematic behavior that can cause very unportable unexpected results in consumers which leverage the API, like chown(1).
Say, for instance, someone introduced a user, root.wheel, then tried to chown the file as root.wheel -- it would actually chown the file to user=root, group=wheel, which is unexpected, instead of chowning it to a user named root.wheel.
If an attacker was aware of this caveat and there was a program run as root or had superuser permissions to set file ownership and the system had a user named root.wheel, which sanitized the input to ensure that the user first existed before passing the string to chown(1), files could be setuid to allow permissions to root:wheel, and thus could be abused by the attackers to run the intercepted program with superuser privileges.
Ref: 693dd1d
Usernames on multiple operating systems (especially ones which are AD-joined) support "." in [long] usernames. Unfortunately, userspec.c treats "." like a user/group separator for unclear legacy reasons. This is very problematic behavior that can cause very unportable unexpected results in consumers which leverage the API, like chown(1).
Say, for instance, someone introduced a user,
root.wheel, then tried to chown the file asroot.wheel-- it would actually chown the file to user=root, group=wheel, which is unexpected, instead of chowning it to a user namedroot.wheel.If an attacker was aware of this caveat and there was a program run as root or had superuser permissions to set file ownership and the system had a user named
root.wheel, which sanitized the input to ensure that the user first existed before passing the string tochown(1), files could be setuid to allow permissions toroot:wheel, and thus could be abused by the attackers to run the intercepted program with superuser privileges.Ref: 693dd1d