I was surprised to learn a few weeks ago that Vista added symlink support to Windows.  Whereas I found people rejoicing at the new feature, I anticipate with dread a number of vulnerability announcements in products that worked fine under XP but are now insecure in the presence of symlinks in the file system.  This should continue for some time still, as Windows programmers may take time to become familiar with the security issues that symlinks pose.  For example, in the CreateFile function call, “If FILE_FLAG_REPARSE_POINT is not specified and:

  * If an existing file is opened and it is a symbolic link, the handle returned is a handle to the target.
  * If CREATE_ALWAYS, TRUNCATE_EXISTING, or FILE_FLAG_DELETE_ON_CLOSE are specified, the file affected is the target.”
(reference:  MSDN, Symbolic link effects on File system functions, at:  http://msdn2.microsoft.com/en-au/library/aa365682.aspx)

So, unless developers update their code to use that flag, their applications may suddenly operate on unintended files.  Granted, the intent of symbolic links is to be transparent to applications, and being aware of symbolic links is not something every application needs.  However, secure Windows applications (such as software installers and administrative tools) will now need to be ever more careful about race conditions that could enable an attacker to unexpectedly create symlinks.  They will also need to be more careful about relinquishing elevated privileges as often as possible. 

In addition, it is easy to imagine security problems due to traps planted for administrators and special users, to trick them into overwriting unintended files.  UNIX administrators will be familiar with these issues, but now Windows administrators may learn painful lessons as well. 

Hopefully, this will be just a temporary problem that will mostly disappear as developers and administrators adjust to this new attack vector.  The questions are how quickly and how many vulnerabilities and incidents will happen in the meantime.  One thing seems certain to me:  MITRE’s CWE will have to add a category for that under “Windows Path Link problems”, ID 63.