Skip to main content
Skip to main content
Microsoft Security

Recent Symantec and IBM vulnerabilities, giblets, banned APIs and the SDL

  • Michael Howard

Hi, Michael here. Happy New Year!

Recently, Symantec issued a security advisory warning users of critical remote code-execution security vulnerabilities in various Symantec email security products. The bugs caught my eye for a number of reasons:

  • First and foremost, security bugs in security products are always of great interest and concern to me, because customers use security technology to defend themselves from attack.
  • Second, I like to analyze security vulnerabilities in other products to gauge where attackers are going. As the SDL hardens Microsoft products, we are seeing attackers move elsewhere.
  • Third, I like to think about how the SDL might have caught the bugs. There is always a chance to learn from these occurrences, and we sometimes make tweaks to the SDL after vulnerabilities are discovered on other platforms or third-party code. And because the SDL is far from perfect we update the SDL twice a year as we learn new vulnerability types.

Symantec’s advisory and some of the ensuing analysis were a goldmine of information for me.  The vulnerabilities are not in Symantec code, yet Symantec customers are still open to attack. The issues lie in a small number of file parsers used in many applications created by a third party vendor. As you probably know, file parsing vulnerabilities are very common, and even though the number of such bugs has dropped significantly in Microsoft products, in the past we had many. Thankfully, the SDL’s fuzzing requirements have significantly helped reduce the number of parsing-related vulnerabilities in our products.

As I mentioned, the vulnerabilities are not in Symantec code; they are in dependencies, in DLLs provided by another company. The SDL refers to these as “giblets,” a term coined by Steve Lipner, a Senior Director at Microsoft and my co-author on “The Security Development Lifecycle.” Giblets are of real concern because they are pieces of code that are used by your product but that you did not produce, and hence have little, if any control over. In short, if there’s a security bug in a giblet you use, you have a security bug too. Symantec acknowledged this issue in its advisory:

“Symantec engineers have worked with (the third-party vendor) to identify these vulnerabilities and are working to update the affected module.”

One of the hallmarks of a giblet is that they often affect more than one product, and sure enough, the same is true of these bugs; the same bugs affect IBM’s Lotus Notes 7.0.2 and some other products too.

Now to the bugs themselves. I looked at four of the parser bugs as they affected IBM’s Lotus Notes:

  • WordPerfect (.WPD) files
  • AMI Pro (.SAM) files
  • Microsoft Word (.DOC) files
  • FrameMaker (.MIF) files

I would supply a CVE number for each of these, but it appears none have been assigned. However, all of these bugs are explained in detail at the Web site, and include an assembly-level analysis, which I used to determine the offending code, and sample exploit code.

.WPD File Parser Vulnerability

The WPD bug is due to an integer overflow:

… it is possible to cause more than 2400 bytes to be copied from the WordPerfect file into the stack buffer. This overwrites the saved EIP and SEH, and can be exploited for arbitrary code execution

Could the SDL have caught this bug? Probably, either through fuzzing, code inspection or static-analysis. All of which are SDL requirements. With that said, integer overflows can be hard to spot.

.SAM File Parser Vulnerability

This bug is caused by an insecure call to lstrcpy:

In several places within the DLL, the unsafe “lstrcpy()” function is used to copy each line read from the file into fixed sized stack and heap buffers

There is a very high probability that the SDL would catch this because lstrcpy (and all its evil brethren) are on the Banned API list. We have seen bugs that do not affect Windows Vista because of banned API removal, one such example is MS06-078 in Windows Media Player. The SDL’s Banned API removal requirement has proven to be very effective.

.MIF File Parser Vulnerability

Like the .SAM bug, this bug is an insecure call to a string copy function, in this case the strcpy and strcat duopoly. Again, banned API removal would probably have caught this.

.DOC File Parser Vulnerability

The DOC bug is due to an incorrect call to memcpy():

The “memcpy()” function expects a length value to be supplied to determine the number of bytes that will be copied into the destination buffer.

Could the SDL have caught this? Possibly, but I would err on the side of possibly not. With that said, we are now heavily focused on memcpy-related bugs as a result of having issued five memcpy-related security bulletins in the past few years. Examples include:

Bugs in memcpy() appear to be more common these days; in fact, MIT’s implementation of the Kerberos v5 authentication protocol had two remote root memcpy-related bugs recently:

Compiler and Linker SDL Requirements

There is no indication which compiler is used to compile these DLLs, but it looks like none have stack-based buffer overrun detection defense (such as the Visual Studio C++ /GS flag) or exception handler defenses (such as the Microsoft Link /SAFESEH flag) – both of which are SDL requirements. I also assume that the code is not linked with No-Execute (/NXCOMPAT), which is also an SDL requirement.


Bugs are interesting, you can learn a lot from your own bugs, but also from the bugs in other products. From an SDL perspective, there is nothing new about any of these vulnerabilities. It also appears that the DLLs are not compiled or linked with any other defenses. If I had my way they would be SDL compliant, and have as many defenses as possible as the parser code is an inch away from the Internet, and is used in a mission critical defensive position. What’s interesting to me is how many other products out there consume these giblets? Because those products have security bugs too!