{"id":1716,"date":"2012-06-06T13:10:00","date_gmt":"2012-06-06T20:10:00","guid":{"rendered":"http:\/\/marcbook.local\/wds\/playground\/cybertrust\/2012\/06\/06\/warnings-sdl-and-improving-uninitialized-variable-detection\/"},"modified":"2023-05-15T23:12:05","modified_gmt":"2023-05-16T06:12:05","slug":"warnings-sdl-and-improving-uninitialized-variable-detection","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/2012\/06\/06\/warnings-sdl-and-improving-uninitialized-variable-detection\/","title":{"rendered":"Warnings, \/sdl, and improving uninitialized variable detection"},"content":{"rendered":"

Tim Burrell and Thomas Garnier of the TwC Security Science team present the sixth and last blog\u00a0installment describing more\u00a0\/sdl functionality in Visual Studio 2012 RC. Please note that there will be an MSDN webcast discussing the security\u00a0enhancements\u00a0to Visual Studio\u00a02012 RC\u00a0– a wrap-up of sorts –\u00a0on June 13 at 9:00AM (PST)<\/strong>.<\/span><\/p>\n

——————————————————————————————————————–<\/span><\/p>\n

In <\/span>previous posts<\/span> \u00a0we introduced the \/sdl compiler switch and described its dual role of treating security-relevant warnings as errors to find bugs during development and enabling compiler mitigation features to help defend against residual bugs.<\/span><\/span><\/p>\n

This post highlights how the \/sdl compiler switch makes prioritizing important security warnings easier and describes a new warning useful to identify potentially uninitialized pointers. <\/span><\/span><\/p>\n

\/sdl and compiler warnings<\/span><\/span><\/span><\/h2>\n

As noted in our overview post, \/sdl causes a number of compiler warnings to be treated as errors \u2013 Microsoft\u2019s SDL treats these warnings as mandatory for native code:<\/span><\/span><\/p>\n

\n\n\n\n\n\n\n\n\n\n\n\n\n
Warning<\/span><\/span><\/b><\/td>\nCommand line switch<\/span><\/span><\/b><\/td>\nDescription<\/span><\/span><\/b><\/td>\n<\/tr>\n
C4146<\/span><\/a><\/td>\n\/we4146 <\/span><\/span><\/td>\nA unary minus operator was applied to an unsigned type, resulting in an unsigned result<\/span><\/span><\/td>\n<\/tr>\n
C4308<\/span><\/a><\/td>\n\/we4308 <\/span><\/span><\/td>\nA negative integral constant converted to unsigned type, resulting in a possibly meaningless result<\/span><\/span><\/td>\n<\/tr>\n
C4532<\/span><\/a><\/td>\n\/we4532 <\/span><\/span><\/td>\nUse of \u201ccontinue\u201d, \u201cbreak\u201d or \u201cgoto\u201d keywords in a __finally\/finally block has undefined behavior during abnormal termination<\/span><\/span><\/td>\n<\/tr>\n
C4533<\/span><\/a><\/td>\n\/we4533<\/span><\/span><\/td>\nCode initializing a variable will not be executed<\/span><\/span><\/td>\n<\/tr>\n
C4700<\/span><\/a><\/td>\n\/we4700 <\/span><\/span><\/td>\nUse of an uninitialized local variable<\/span><\/span><\/td>\n<\/tr>\n
C4703<\/span><\/span><\/b><\/td>\n\/we4703<\/span><\/span><\/b><\/td>\nPotential use of an uninitialized local pointer variable<\/span><\/span><\/b><\/td>\n<\/tr>\n
C4789<\/span><\/a><\/td>\n\/we4789<\/span><\/span><\/td>\nBuffer overrun when specific C run-time (CRT) functions are used<\/span><\/span><\/td>\n<\/tr>\n
C4995<\/span><\/a><\/td>\n\/we4995 <\/span><\/span><\/td>\nUse of a function marked with pragma deprecated<\/span><\/a><\/span><\/span><\/td>\n<\/tr>\n
C4996<\/span><\/a><\/td>\n\/we4996 <\/span><\/span><\/td>\nUse of a function marked as deprecated<\/span><\/a><\/span><\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

<\/h2>\n

Introducing the C4703 warning<\/span><\/span><\/span><\/p>\n

In reviewing available compiler warnings, we noted that <\/span>C4701<\/span><\/a> had interesting results but we believed that there was value in helping developers prioritize which instances were the most likely to have security implications. The C4701 warning identifies potential usage of uninitialized local variables. In MSRC cases involving uninitialized local variables, pointers are the most common case leading to code execution.<\/span><\/span><\/p>\n

Visual Studio\u00a02012 RC\u00a0introduces a new level 4 warning (C4703) as a subset of C4701 to detect potentially uninitialized local pointer variables:<\/span><\/span><\/p>\n

Both warnings are generated, maintaining the existing behaviour and also highlighting uninitialized pointers.<\/span><\/span><\/p>\n

The detection of potentially uninitialized local variables is achieved by finding a path where the local variable is used before being initialized. In this example, if size is bigger than 256 then a path exists that would lead to \u2018p\u2019 being used without being assigned a value.<\/span><\/span><\/p>\n

The C4701 and C4703 warnings are comparatively noisy as the existence of a bug depends on whether the path to the uninitialized usage is feasible. The compiler\u2019s analysis does not attempt to solve the constraints to determine this, leading to false positives.<\/span><\/span><\/p>\n

Expanding C4703 with LTCG (Link-time Code Generation) support<\/span><\/span><\/span><\/h2>\n

The warning analysis described in the previous section is done locally for each function. If a reference to a variable is passed to another function, the compiler\u2019s analysis lacks information and assumes that the function will initialize the variable correctly. Changing this assumption for all function calls would increase false positives making the warning unacceptably noisy.<\/span><\/span><\/p>\n

In Visual Studio\u00a02012 RC\u00a0we used <\/span>LTCG<\/span><\/a> and <\/span>optimization<\/span><\/a> support to increase the scope of the analysis on specific functions. A summary is generated on target functions and the resulting information is used during local analysis.<\/span><\/span><\/p>\n

These functions are examples of the problem we aimed to detect:<\/span><\/span><\/p>\n

ExampleFunction delegates the local variable p initialization to <\/span>Callee without verifying if this function succeeded on cleanup. From local analysis we cannot state if p would be initialized on failure or not. <\/span><\/span><\/p>\n

Prior to Visual Studio 2012 RC\u00a0the analysis would assume that Callee initialized p; in the absence of information about Callee this helped keep the number of false positives in check.<\/p>\n

In Visual Studio 2012 RC, the new inter-procedural analysis allows a warning to be reported while reducing the potential number of false positives. <\/span><\/span><\/p>\n

This type of analysis works only with these conditions:<\/span><\/span><\/p>\n