I'm reading an Ubuntu security guide developed for the US Department of Defense, to be found here. Written for 16.04 but I don't think this particular item has changed much. The guide says,
Group ID (Vulid): V-75583
Group Title: SRG-OS-000480-GPOS-00227
Rule ID: SV-90263r2_rule
Severity: CAT II
Rule Version (STIG-ID): UBTU-16-010840
Rule Title: All world-writable directories must be group-owned by root, sys, bin, or an application group.
Vulnerability Discussion: If a world-writable directory has the sticky bit set and is not group-owned by a privileged Group Identifier (GID), unauthorized users may be able to modify files created by others.
I'm not getting the logic here. Sticky bit on a directory prevents deletion of files, not modification. My only guess is that they are talking not about modifying the file but about reading the file, deleting and then recreating it. This scheme works only if the file was world-readable in the first place, which it should have been not if it was any sensitive.
Overall, I'm lost. Does this rule make any sense at all?
Yes, it sounds like this is exactly what they are talking about. Whether the file is readable is irrelevant. Deleting a file and recreating it with whatever you want in it is--practically speaking--the same as modifying it. Sure, if you want to split hairs you could argue it's not the same file because it might have a different inode or take up different blocks on the disk, but that doesn't matter for security. Either way, it has the same filename and different contents than the user who owns it is expecting. That's a security risk.
For example, let's say this directory is a temporary directory where any user applications running can write out or read back in their own temporary files. This works fine as long as nobody can modify each others' files. But as soon as that becomes possible... whether or not they are readable... it opens up those applications to various attacks. If the attacker understands how the application works and what it's expecting to read from that temporary file, then they could replace the file without the user who is using the application even knowing. And in many cases, this allows them to control the behavior of the application, making it do something unexpected like send the user using it to a phishing site instead of a real site, or even send out fake emails to other people, etc.
This is a vulnerability even if the file is not readable. But there are also legitimate cases where an application might want to write out a file that's world readable but only modifiable by the user who created it. For example: a public key which identifies them to others, or allows other applications to send secure information to them.