The trouble with symbolic links

Posted Jul 15, 2022 10:57 UTC (Fri) by ma4ris5 (guest, #151140)
In reply to: The trouble with symbolic links by sven_wagner
Parent article: The trouble with symbolic links

I remember when I started studying at "Helsinki University of Technology (HUT)" in 1992.
It is named now as "Aalto University", this is different from "University of Helsinki", where Linus studied.

There were VT computer terminals with UART serial ports, attached to Unix desktops for shared
use with private home folders on NFS. I remember learning Gopher, and also Mosaic browser:
Maybe it was an early version of Mosaic - according to Wikipedia first release was at 1993.

IT administrators told, that Unix vendors had fixed the TOCTTOU soft link race conditions:
Some students in universities were using soft links in /tmp/ folders to gain root access before the fixes.
Unix administrators in HUT forbid to try such attacks on the computers: attempts would be noticed and there were severe consequences.

Fortunately symbolic link races were history: students were safe, and we learned to prevent the race conditions in the future.

to post comments

The trouble with symbolic links

Posted Jul 15, 2022 22:19 UTC (Fri) by ma4ris5 (guest, #151140) [Link]

So maybe the mistake was already made in 1992:
TOCTTOU races were (partially) fixed, for the remaining ones,
there was logging and software level booby traps.

If somebody would try to search for the remaining race conditions,
alerts would be raised for one of the first attempts,
and user would be thrown out and blocked.

IT departments were in control again.

The world would look quite different in Linux side, if universities would have demanded
for Unixes to remove soft link TOCTTOU races at file system level before 1992.

Something like this might happen in next 10 years:

Security scanners
- open(), chmod() chcon() stat() etc. TOCTTOU hazard libc functions will be marked as insecure at source code level.
- All applications that use those functions, will need to be altered (just like Samba multi year project to fix one CVE),
to avoid unsafe calls, otherwise those projects will become obsolete.
- All commands, that have in source code such calls (like "setfacl -R" command which was mentioned in the Samba video )
are marked as vulnerable because of the possibility of existing TOCTTOU races.
- Security aware application container deployments must use latest OS, because older OS versions don't get the (massive multi year) fixes.
- Container (non-root-path) mounts that use data disks that follow soft links by default will be marked as insecure.

Other attack mitigations
- Of course, SELinux might come into containers too as mandatory, when OS is present at file system level.
- Single binary containers take more ground (Examples: Rust, Go).
There is only host kernel, read only binary, configuration and root disk, data partition with no
soft link support, no vulnerable OS binaries at file system (only minimal set like "/work/", "/dev/", "/proc" and "/sys")).
No suid binaries. Container runs as non-root user.

Converting all existing code bases into safety should be as easy as possible (the 10 year project).
Creating new safe applications should be the easy (default) way. Creating vulnerable code is fine to be a bit harder to do.