What are the world writable directories by default?
The only FHS-mandated directories that are commonly world-writable are /tmp and /var/tmp. In both cases, that's because they are intended for storing temporary files that may be made by anyone.
Also common is /dev/shm, as a tmpfs (filesystem backed by RAM), for fast access to mid-sized data shared between processes, or just creating files that are guaranteed to be destroyed on reboot.
There may also be a /var/mail or /var/spool/mail, and sometimes other spooler directories. Those are used to hold mail temporarily before it's processed. They aren't always world-writable, depending on the tools in use. When they are, it's because files can be created there by user tools for processing by daemons.
All of these directories usually have the sticky bit (t) set, meaning that only the owner of a file or of the directory can move or delete the files in it.
Any program running as any user can make files in these directories, and it's up to the creating program to do the right thing as far as security for its particular data goes. There's no particular general security problem other than someone potentially filling up the filesystem, but plenty of scope for a program to get it wrong.
There have been some moves towards service-specific /tmp directories. These avoid some of the potential bugs that can come up, so it's not as vital for the program to be bug-free in how it uses the directory.
You can find the world-writable directories on your system with:
find / -maxdepth 3 -type d -perm -777
/tmp, /var/tmp, and /var/lock are world-writable by default. There may be symlinks, such as /usr/tmp → /var/tmp, provided for compatibility with older applications.
/tmp and /var/tmp world-writable because they are meant to be used by any user for any temporary storage. /var/lock is world-writable so that any process, running as any user, can create lock files in a central location.
Is there a security risk? No, but sort of yes.
The permissions for all of those directories are 1777, with the leading 1 being the sticky bit. That means that while anyone can create a file in those world-writable directories, only the owner can delete his/her own files (and of course, the root user can too).
The possible security risk can arise from insecure temp file creation. Since those directories are a free-for-all, users need to take precautions to ensure that the files they create are actually new files, rather than opening an existing file or symlink that may have been planted there by a malicious user. If files are created using proper techniques, such as open(…, O_EXCL) or mkstemp(3), then such risk is avoided.
/tmp
It is risky, because you need to add extra code to use it safely. Obviously this gets overlooked.
A recent example is given by Steve Kemp. http://blog.steve.org.uk/sometimes_reading_code_makes_you_scream_.html
./mgmt/tools/SysAPI.cc: tmp = fopen("/tmp/shadow", "w"); ./mgmt/tools/SysAPI.cc: system("/bin/mv -f /tmp/shadow /etc/shadow");
If you (the attacker) replace /tmp/shadow before the second line, you get to replace everyone's password. (I guess the attack requires you to create the file before the first line, and make the file world-writeable).
Systemd on linux allows mitigating such vulnerabilities by isolating /tmp for many system services. (Except ones that "misuse /tmp as a location for IPC sockets and other communication primitives").
In Fedora Linux - http://fedoraproject.org/wiki/Features/ServicesPrivateTmp
Systemd explanation - http://0pointer.de/blog/projects/security.html