Stack crash caused by sprintf. Cost of not using sprintf_s ()

Problem description:

The engine has been running stably for a long time. It is also stable on all computers.

However, only one notebook does not work. The engine collapsed when running on it.

 

Problem Analysis:
Based on the generated dump file, the analysis result of windbg is:
The stored exception information can be accessed via. ecxr.
(C98.da0): Stack Buffer Overflow-code c0000409 (first/second chance not available)

The frame IP address is damaged. (what is the IP address? Command address? Forgot, the permission should be treated as the base address of the current frame.) It can be seen that the base address of the stack is damaged.

View the call Stack:
... Some system DLL internal functions
Xeyez! Funxeyeloadalldll (),

....

 

The problem should be found in funxeyeloadalldll,
Locate the last line of the function based on the error line prompted by windbg !! It can be seen that when the function returns, the return fails!

View the implementation of this function:

Int funxeyeloadalldll ()
{
Char * stroldenv;
Stroldenv = getenv ("path ");
// Add the plug-in directory to the environment variable so that the system can find the DLL dependencies between plug-ins when loading the DLL.
Char newenv [1024] = {0 };
Sprintf (newenv, "Path = % s;. // external;. // USB", stroldenv );

Tchar Buf [max_path] = {0 };
Tchar * psz;
Getmodulefilename (null, Buf, max_path );
 

......

......
} // Windbg prompts that this row has an error <-------------

After analysis, the problem may occur in the following code. The following Code reads the PATH environment variable of the current system into newenv.
Because sprintf is not a secure version, the stack may be damaged!
Char newenv [1024] = {0 };
Sprintf (newenv, "Path = % s;. // external;. // USB", stroldenv );

Check the PATH variable of the notebook. There are more than 10 rows, and each row has more than 100 letters!

It seems that defensive programming is necessary!
Do not assume the customer's computer!
Fortunately, now we can use the windbg + PDB file for debugging. If not, I don't know when to adjust this bug! Even worse, attackers may be attacked.