Microsoft KB Archive Search

Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

  1. Home
  2. You may receive the "Linker tools error LNK2001" error messages when you build source code by using the Win32 Software Development Kit (SDK) or the Windows Server 2003 Driver Development Kit (DDK) for Windows Server 2003 Service Pack 1

You may receive the "Linker tools error LNK2001" error messages when you build source code by using the Win32 Software Development Kit (SDK) or the Windows Server 2003 Driver Development Kit (DDK) for Windows Server 2003 Service Pack 1

Symptoms

When you build either 32-bit source code or 64-bit code source code, you may receive one of the following error messages at compile time or at link time:

Error message 1
Linker Tools Error LNK2001
'unresolved external symbol __security_cookie '
Error message 2
Linker Tools Error LNK2001
'unresolved external symbol __security_check_cookie '
To build the code, you use either the Microsoft Win32 Software Development Kit (SDK) for Microsoft Windows Server 2003 Service Pack 1 or the Microsoft Windows Server 2003 Driver Development Kit (DDK) for Windows Server 2003 Service Pack 1.

↑ Back to the top

Cause

In Microsoft Visual Studio 2002, a new compiler switch that is named " /GS" has been introduced to the Microsoft Visual C++ compiler. When the " /GS" switch is set, the compiler injects buffer overrun detection code in the compiled code.

On functions that the compiler determines might be subject to buffer overruns, the compiler inserts a security cookie before the return address. The security cookie is computed one time at module load. The value of the security cookie is pushed to the stack on function entry. On function exit, the compiler helper is called to make sure that the value of the cookie is still the same. If the value changes, this is treated as a sign of a buffer overrun in the stack corruption. Therefore, you can detect some direct buffer overruns in the return address.

Even though the "/GS" switch has been significantly improved in Visual Studio 2003 and in Visual Studio 2005, the "/GS" switch does not help protect user code from all possible buffer overrun security attacks. However, the list of conditions that the "/GS" switch can help protect user code against has continued to grow. Because of minimal performance effect by the "/GS" switch, the recent versions of the Visual C++ compiler automatically set the "/GS" switch. When the "/GS" switch is set, an application receives buffer overrun enhanced protection at run time. This may significantly reduce the number of attacks that the application is vulnerable to.

By default, the Visual C++ compiler that is included with the Platform SDK for Windows Server 2003 Service Pack 1 sets the "/GS" switch. When source code is compiled, the compiler introduces references to code that insert a security cookie on the stack on function entry. Then, the value of the security cookie is checked on function exit. Additionally, most libraries in the Platform SDK have been built with the "/GS" switch set. The libraries already reference code that is required to provide the "/GS" switch enhanced protection at runtime.

In Visual Studio, the code for the "/GS" switch resides in the C Runtime Library. This is the default library that is pulled in by the linker. However, the version of the C Runtime Library that is included with the Platform SDK does not contain the same code as the C Runtime Library for Visual Studio. This difference occurs because the Platform SDK lets users build applications and services that can target different modes of the operating system. The verification of the security cookie that is added to the compiled code has to be performed in different ways. The different ways depend on what operating system mode a service or an application is running in. Therefore, it was decided to provide three libraries that implement verification of the security cookie.
bufferoverflowU.libThis library implements functionality for security cookie verification that can be used in the user mode and in applications that use the Win32 API. Most applications link to this library.
bufferoverflowK.libThis library implements the check of a security cookie that works in the kernel mode of the operating system. Services and subsystems that run in the kernel mode have to be linked to this library.
bufferoverflow.libThis library implements functionality for security cookie verification that can be used in the user mode. However, bufferoverflow.lib is different from bufferoverflowU.lib because bufferoverflow.lib can be used in services and in applications that do not use the Win32 API.

↑ Back to the top

Resolution

To resolve errors that are thrown by the linker, you have to link your project by using one of the bufferoverflow*.lib libraries that are previously mentioned. For example, the following program is a simple program that you can build by using the Platform SDK.
#include <stdio.h>
#include <string.h>

void mymethod(char* szIn) 
{
  char szBuf[10];
  strcpy(szBuf, szIn);
  puts(szBuf);
}
int main(int argc, char* argv[]) 
{
    if(argc>1) 
      mymethod(argv[1]);
}

The following code example shows incorrectly written code that asks for buffer overrun enhanced protection. The Visual C++ compiler adds enhanced protection to the compiled code. The compiled code cannot link because the linker cannot resolve the references to the following:
  • __security_cookie
  • __security_check_cookie
>cl a.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.32 for AMD64
Copyright (C) Microsoft Corporation.  All rights reserved.

a.cpp
Microsoft (R) Incremental Linker Version 8.00.40310.31
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:a.exe
a.obj
a.obj : error LNK2019: unresolved external symbol __security_cookie referenced in function "void __cdecl mymethod(char *)" (?mymethod@@YAXPEAD@Z)
a.obj : error LNK2019: unresolved external symbol __security_check_cookie referenced in function "void __cdecl mymethod(char *)" (?mymethod@@YAXPEAD@Z)
a.exe : fatal error LNK1120: 2 unresolved externals
To resolve these errors, you have to specify that the linker must also use bufferoverflowU.lib. This assumes that your application targets the user mode and can use the Win32 API.
>cl a.cpp bufferoverflowU.lib
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.32 for AMD64
Copyright (C) Microsoft Corporation.  All rights reserved.

a.cpp
Microsoft (R) Incremental Linker Version 8.00.40310.31
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:a.exe
a.obj
bufferoverflowU.lib
>
If you use a two step build process, the following code example applies.
>cl –c a.cpp bufferoverflowU.lib
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.32 for AMD64
Copyright (C) Microsoft Corporation.  All rights reserved.

a.cpp

>link a.obj bufferoverflowU.lib
Microsoft (R) Incremental Linker Version 8.00.40310.31
Copyright (C) Microsoft Corporation.  All rights reserved.

>

↑ Back to the top

Status

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

↑ Back to the top

References

For additional information about the "/GS" buffer security check in Visual C++ compiler options, visit the following Microsoft Developer Network (MSDN) Web site:
http://msdn2.microsoft.com/en-us/library/8dbf701c(vs.71).aspx
For additional information about compiler security checks, visit the following MSDN Web site:
http://msdn2.microsoft.com/en-us/library/aa290051(VS.71).aspx

↑ Back to the top

Keywords: vs2008swept, kbtshoot, kbprb, kb

↑ Back to the top

Article Info
Article ID : 894573
Revision : 4
Created on : 3/30/2017
Published on : 3/30/2017
Exists online : False
Views : 1758