Share via

Subtle holes let in the most dangerous people

  • Article

Hello again

As Will correctly pointed out, the signed/unsigned ‘conversion’ will break the code here. Some of the things that make code less than secure can be very subtle indeed. If you didn’t see the comment then I will restate the point here. With a signed comparison, an integer comparison with the high bit set will be negative and therefore less than the buffer size but the string copy operation takes a size_t which is unsigned and therefore will take the value as huge – and overwrite the heap.

So, good error checking is hard but we have added some things to make it a little easier. I mentioned strncpy_s in my last posting. In the most recent versions of Visual C++, we added more secure versions of the string manipulation functions which take both the number of characters to copy and the size of the buffer and they ensure that they are not being used to write past the end of the buffer. That should save a crash or two even if you are not worried about security. Of course, you could do as the sample code in the last blog did and manually check – and if you are using older versions of C or a non-MS compiler then that is what you have to do. The advantage of using the new functions is that you never forget to check.

Another thing that can help is stack cookies. One of the options that you can give the compiler is /GS with a + or – to turn the feature on and off. It doesn’t cost a great deal in time or space but what it does is add a number to the stack in the function prologue and a check that nothing changed that number before heading for the return. If the number doesn’t match, your process dies. The feature came in with VC 7.1 which was part of Visual Studio 2003 so you don’t have to have the latest and (arguably) greatest to get this feature. Now, while it might seem that this would be pretty expensive, it turns out to be not so bad because the compiler is smart. If there is no array type or allocation of a buffer on the stack then you haven’t got anything to overflow so it doesn’t generate the code for you.

Unfortunately, none of this helps with legacy code. You will have noticed that we are still shipping security updates. We have a huge amount of legacy code because Office has to open a Word document that was lasted edited on Word 95 and so on. Also, the next version of Windows evolves from the previous one and some of the code has been through a lot of revisions over the years. You guys are mostly developers and you know the pain.

Now, all through this section, I have been talking about C and C++ with nary a whisper about managed code or VB6. The reason is that you can’t get into the same mess. However, in theory, we could on your behalf. MS04-028 showed that it wasn’t just a theory since a malicious JPG could and did cause remote code execution on systems with the “gold” version of GDIPLUS. That caused a critical vulnerability in thousands of third party applications, Office and multiple versions of our image editing software. Buffer overruns are not good things and the Black Hats never stop looking for them. The code in question had been reviewed pretty carefully so you might want to look with a suspicious eye next time you are editing.

Signing Off

Mark

Comments