Robert Horvick's Weblog : Defects

Struct packing, source listings and the Zen of preprocessed code.

RobertHorvick — Fri, 20 Feb 2004 17:36:00 GMT

It seems that no matter how good at people (definitely including me) are at writing buggy code they are much less adept at creating good reproduction cases or using their existing tools to figure out what’s going on.

A recent issue I saw involved a piece of C++ code where a struct was being sent over a socket and was arriving corrupted.

I was giving a laundry list of what they had tried. Debugging the send and receive through all the layers of the stack, network analysis to verify the packet came through each hop uncorrupted, debugging both sides of the connection extensively. What they concluded was that there was a compiler bug causing bogus code to be generated on one side of the connection.

Compiler do break sometimes. But this block of code was a series of integral assignments (int = int, char = char, etc). This was also a shipping version of VC – not some random developer desktop build. I was highly skeptical of their claim.

So I asked to see the struct. It looked something like this:

#ifdef PLATFORM_SPECIFIC_VALUE

#pragma pack (push, 2)

#else

#pragma pack (push, 4)

#endif

struct Foo

{

char Character;

int Integer;

short Short;

long Long;

};

#pragma pack(pop)

See the problem(s) yet?

So imagine a function that looks like this:

void SetFoo(Foo *foo)

{

foo->Character = 'a';

foo->Integer = 42;

foo->Short = 128;

foo->Long = 99999;

}

This is where I pulled out “compiler bug reproduction tool #1” (in my book anyway) – Generate Preprocessed File (/P).

People spend a lot of time assuming (i.e. guessing) what their code looks like once the maze of #ifdef and preprocessor goo are complete. But sometimes people make mistakes so to check you use /P.

They recompiled the source file SetFoo was defined in using /P and found this (some whitespace removed):

#line 1 "c:\\temp\\genrepro\\worker.cpp"

#line 1 "c:\\temp\\genrepro\\juice.h"

#pragma once

#pragma pack (push, 4)

#line 8 "c:\\temp\\genrepro\\juice.h"

struct Foo

{

char Character;

int Integer;

short Short;

long Long;

};

#pragma pack(pop)

#line 2 "c:\\temp\\genrepro\\worker.cpp"

void SetFoo(Foo *foo)

{

foo->Character = 'a';

foo->Integer = 42;

foo->Short = 128;

foo->Long = 99999;

}

So they are using 4 byte packing.

Why is this a problem? Well – let’s look at the generated asm to set those values in SetFoo:

; 5 : foo->Character = 'a';

00000 8b 44 24 04 mov eax, DWORD PTR _foo$[esp-4]

00004 c6 00 61 mov BYTE PTR [eax], 97 ; 00000061H

; 6 : foo->Integer = 42;

00007 c7 40 04 2a 00

00 00 mov DWORD PTR [eax+4], 42 ; 0000002aH

; 7 : foo->Short = 128;

0000e 66 c7 40 08 80

00 mov WORD PTR [eax+8], 128 ; 00000080H

; 8 : foo->Long = 99999;

00014 c7 40 0c 9f 86

01 00 mov DWORD PTR [eax+12], 99999 ; 0001869fH

Notice the offsets? 0, 4, 8, and 12? 4 byte packing.

Now let’s look at the other side setting those same values:

0001e 50 push eax

0001f c6 00 61 mov BYTE PTR [eax], 97 ; 00000061H

00022 c7 40 02 2a 00

00 00 mov DWORD PTR [eax+2], 42 ; 0000002aH

00029 66 c7 40 06 80

00 mov WORD PTR [eax+6], 128 ; 00000080H

0002f c7 40 08 9f 86

01 00 mov DWORD PTR [eax+8], 99999 ; 0001869fH

Offsets 0, 2, 6 and 8. 2 byte packing.

What do you think sizeof(Foo) returns on each platform? It’s 12 (for 2 byte packing) and 16 (4 byte packing).

(Hey – you too can generate your own asm listing using the Assembly Listing /Fx flags – I generated these using /FAcs).

Really there is nothing fancy about this whole exercise. A lot of you are probably reading this and saying “Well Duh!” but walk around the office and ask a handful of people how to generate an assembly listing of their code or how to see the preprocessed results for a source file and a surprising amount may not even know you could.

Once they had fixed the packing problem we began talking about their other problem.

Do you see it?

SOLUTION : Spotting Code Defects #3 (C++ 101)

RobertHorvick — Fri, 06 Feb 2004 23:21:00 GMT

As always thanks to those that emailed responses. Please feel free to post them in the feedback area too!

The biggest problem with this piece of code is that the stream is not being checked for errors after reading. Look at this block:

int age;

cin >> age;

people[name] = age;

What happens when a invalid value (anything non-integer, for example) is given as input? The stream read fails and cin has some flags set to indicate that failure. What you should do is something more like the following (though this is not how I would actually ever write it – but without changing the over-all program flow…)

So first prompt. Next attempt to read. If the stream is still good then set our success flag and get out. But if not then first clear the error bits. Do this so anything else can happen. Next ignore the first character in the stream. Perhaps they entered “a32” – that is invalid so ignore the “a”. Then peek into the stream. Are we are eof()? If so then abort. Perhaps stdin came from a file or pipe and that is EOF or closed. Who knows. Basically we keep trying until it succeeds. Removing one character at a time from the failure stream until either it succeeds or until the >> operator has nothing to work with and blocks on stdin for input again.

bool readAge = false;

int age;

cout << "Adding a new person! Enter " << name << "\'s age: ";

while(true)

{

cin >> age;

if(cin)

{

readAge = true;

break;

}

else

{

cin.clear();

cin.ignore();

if(cin.peek() == char_traits<char>::eof())

{

cout << "End of stream detected. Aborting" << endl;

break;

}

if(readAge)

{

people[name] = age;

cout << "Added " << name << endl;

}

else

{

break;

}

Is this the right thing to do?

That depends on your goals. This example takes “a32”, skips the “a” and uses the “32”. But what if they entered “a32bbb”? Well, the “a” is skipped, the 32 is used and the next cin still contains “bbb\n” (notice the newline is still there) – so when we loop back to prompt for a name there is one already on stdin. That’s probably not what we want.

The easiest way to handle this is to simply clear the line after reading an age … something like this:

cin >> age;

if(cin)

{

cin.ignore(numeric_limits<int>::max(), '\n');

readAge = true;

break;

}

This really doesn’t excite me that much but it works well enough for now.

Of course we use cin’s extraction operator (>>) twice so we’d need to do this twice. And now the function is huge. So large I’m not going to paste it here.

It’s not long before we start looking at other solutions. Perhaps we need a custom extractor that does all of this for us. A very straight forward one would be something like this:

template<class T>

istream& readFromStream(istream &in, T &obj, bool discardRestOfLine = true)

{

while(true)

{

in >> obj;

if(in)

{

if(discardRestOfLine)

{

in.ignore(numeric_limits<int>::max(), '\n');

}

break;

}

else

{

in.clear();

in.ignore();

if(in.peek() == char_traits<char>::eof())

{

cout << "End of stream detected. Aborting" << endl;

break;

}

return in;

}

Then we could replace our original function to look like this:

bool readAge = false;

int age;

cout << "Adding a new person! Enter " << name << "\'s age: ";

if(readFromStream(cin, age))

{

readAge = true;

}

if(readAge)

{

people[name] = age;

cout << "Added " << name << endl;

}

else

{

break;

}

I’m still not really happy with this though. There are just so many edge conditions where things could go wrong. But I think it’s enough for C++ 101.

There are still a lot of problems I have with this code. The logic is wrong (negative ages?), there is a performance problem here:

if(people.find(name) != people.end())

{

cout << name << " is " << people[name] << " years old." << endl;

}

We do the look up twice. Something like this would be better:

map<string,int>::iterator lookUp = people.find(name);

if(lookUp != people.end())

{

cout << name << " is " << lookUp->second << " years old." << endl;

}

Why pay the penalty twice?

Bottom line is that the code has problems. Aside from the stream bug there are several serious design problems we won’t even attempt to address J If this were something beyond C++ 101 we’d be talking about refactoring. But it’s not. So in the spirit of the original I didn’t want to change too much.

Thoughts?

Spotting Code Defects #3 (C++ 101)

RobertHorvick — Wed, 04 Feb 2004 00:19:00 GMT

This is an easy one – something for the C++ 101 kids J

When first learning C++ there are some fairly canonical samples people go through. Hello World, a simple address book, a simple game of adventure, etc.

The name/age lookup sample is another one I see a lot. It’s a great way to learn about console I/O, strings and associative containers. But even in such simple examples it’s easy to write some bugs.

This sample creates a name/age associative mapping. Then prompts the user for a name. If the name is known the age will be displayed, otherwise the user will be prompted for the age and the container will be updated.

And it works almost all the time!

Why such a trivial bug? Because I’ve seen the defects in production code in the last 5 years. Sometimes we need to go back to the basics (and it can’t all be buffer overflows and security hacks). Post comments

using namespace std; is not a defect, by the way. I’m just keeping the code readable.

#include <iostream>

#include <string>

#include <map>

using namespace std;

int main()

{

map<string, int> people;

people["johnny"] = 10;

people["megan"] = 29;

people["morgan"] = 17;

while(true)

{

string name;

cout << "Enter a name (or \"quit\" to quit): ";

cin >> name;

if(name == "quit")

{

break;

}

if(people.find(name) != people.end())

{

cout << name << " is " << people[name] << " years old." << endl;

}

else

{

int age;

cout << "Adding a new person! Enter " << name << "\'s age: ";

cin >> age;

people[name] = age;

cout << "Added " << name << endl;

}

SOLUTION: Spotting Code Defects #2 (Accessing Registry Values)

RobertHorvick — Tue, 27 Jan 2004 19:18:00 GMT

This defect seems to have led a few more people astray then the last. While no one posted publicly several people emailed me solutions. Thanks to all who contributed!

So let’s start with the hints:

Hint #1: It is not only important to test return values, but also to make sure you understand how to get extended error information.

Several people saw this up front and the hint helped a few more. The Reg* functions do not call SetLastError and therefore GetLastError will return bogus information. The return value from the Reg* function is the error code. The Windows API is not always consistent. Some HANDLES are invalid if they are NULL, others if they are INVALID_HANDLE_VALUE. Some functions call SetLastError, others don’t. The bottom line is to always double check.

Hint #2: What is the potential range of values for a LONG?

Only 2 people noticed this in the first go-round. Consider the line of code in question:

LONG cbLength = (LONG)cchLengthIn * sizeof(TCHAR);

If we are in a UNICODE build (or anytime sizeof(TCHAR) > 1) then there is a chance we’ll have an overflow and wrap-around. So it’s possible that cbLength will be a negative number. Why is that a problem? Well, consider what would happen if cchLengthIn were 1073741824 or greater? In a UNICODE build it would become a negative number.

Now let’s think extra hard for a second … RegQueryValue has the following signature:

LONG RegQueryValue(

HKEY hKey,

LPCTSTR lpSubKey,

LPTSTR lpValue,

PLONG lpcbValue

);

But RegQueryValueEx has the following signature

LONG RegQueryValueEx(

HKEY hKey,

LPCTSTR lpValueName,

LPDWORD lpReserved,

LPDWORD lpType,

LPBYTE lpData,

LPDWORD lpcbData

);

Anything catch your eye?

Look at lpcbValue in RegQueryValue … it’s a PLONG. But lpcbData, the comparable parameter, is a LPDWORD.

Why do we care?

Well – let’s play a little game… It’s one of my favorites. It’s called “Crash the program.” You may have heard of it. Heck, you may have written your own version of it in the past.

Consider this program:

#include <tchar.h>

#include <windows.h>

int _tmain()

{

TCHAR lpszVersion[1];

LONG cbLength = -1;

RegQueryValue(HKEY_CURRENT_USER, _T("Software\\MagicApp"), lpszVersion, &cbLength);

}

Compile it as UNICODE. Also – assume that the cbLength is bogus because of a bug in the program (like an integer overflow), it’s hardcoded to make it clear what’s going on. Also assume that lpszVersion is not [1], I did that to make it obvious too … and assume that the key we’re reading from has lots and lots and lots of data (well … more then 1 character anyway :). Use your imagination – it’s not hard.

Now we know that RegQueryValueW is actually what we’re calling. And we know that RegQueryValueW is in advapi32.dll. So let’s open that DLL in depends.exe (this is a PSDK tool - but this page also allows you to download it without the entire PSDK. If you have Visual Studio installed - you already have this. I put it in my Send To menu so I can right-click DLL's and open then with Depends.exe).

Now we can see that (on my machine, anyway) RegQueryValueW has an entry point of 0x00004367 relative to the load point of the module. Since it is possible that the DLL might be relocated let’s only worry about the offset for now.

Now start debugging using F10 (don’t F5 it … it will just crash randomly. We want to trace the execution).

When you get to the first line hit CTRL+ALT+U. This will open up the module window. Advapi32 is loaded at 0x 77DA0000-0x 77E30000. So let’s set a breakpoint on 0x77DA4367 (0x77DA000+0x4367). Now hit F5. If you didn't hit the break point try starting over with a new debugging session and hitting CTRL+ALT+D to view your disassembly and trace through what is happening.

Before we go any further … you do have symbols loaded, right? Check this URL for more info:

http://support.microsoft.com/default.aspx?scid=kb;en-us;319037

Still don't have symbols? Please - I'll wait. This is worth the effort. Believe me.

Alright … let’s keep going.

Now, for me … at 0x77DA443B (that is 0x77DA4367+D4) there is a call opcode to 0x77DA2FAA. Now that was in that advapi32.dll range we saw (and since we are using symbols we know) – it’s calling RegQueryValueExW. Oh man … that LPLONG just became an LPDWORD. We just took our negative value and made it positive. HUGELY positive.

By this time you know that when you hit F5 again – you’re going to crash (if the key exists and contains too much data).

I talk too much. Let’s go on to the next hint.

Hint #3: Is the caller given enough information on error?

No, the caller is not. When RegQueryValue[Ex] fails it gives you back the length you would need. We need to pass that back as well. If we don’t then how does the caller stand a chance of getting it right the second time (or the third, or forth … who knows how many times you might have to guess)! The function needs to define some interface for passing back this information to the caller. Perhaps another parameter, perhaps a ERROR_MORE_DATA style return code, something. Doesn’t really matter to me except that it has to do it.

Hint #4: http://dictionary.reference.com/search?q=deprecated

RegQueryValue is deprecated. Use RegQueryValueEx instead. If we had we would have started with a DWORD and hopefully done it right the first time. Also we avoid, as we just saw, an unnecessary level on indirection. Take the extra 4 seconds and use the right function.

Summary (about time, too)

So we have a serious integer overflow problem, two moderate design problems and we’re not handling failure correctly (also serious). Considering we’re talking about a function with only a handful of statements this is not good – but we’re better off now then we were 30 minutes ago.

HINT: Spotting Code Defects #2 (Accessing Registry Values)

RobertHorvick — Mon, 26 Jan 2004 18:18:00 GMT

There are a few defects here ... ranging from a design issue to a potential buffer-overrun that could cause your system to be comprised and the attacker to be able to execute arbitrary code on your machine.

Hint #1: It is not only important to test return values, but also to make sure you understand how to get extended error information.

Hint #2: What is the potential range of values for a LONG?

Hint #3: Is the caller given enough information on error?

Hint #4: http://dictionary.reference.com/search?q=deprecated

Think you know the defects? Post your comments!

Spotting Code Defects #2 (Accessing Registry Values)

RobertHorvick — Sat, 24 Jan 2004 01:18:00 GMT

Since there was positive feedback on the last one - here is another. I will post hints and the solution next week. There are multiple defects in this code.

I added the _tmain to give some context on how the function getVersionString might be called. The defects I'm interested in are in the function getVersionString.

The function's requirements are to populated the user provided buffer with the version string from the registry and to return a HRESULT indicating success or failure. Also the size of the string should be returned as well.

Found the defects? Want to ask a question or discuss an issue? Post your comments by clicking on the Feedback link on the bottom of the post. Don't want to post in public? Email me instead.

#include <tchar.h>

#include <windows.h>

inline HRESULT HRESULT_FROM_GetLastError()

{

DWORD dw = GetLastError();

return HRESULT_FROM_WIN32(dw);

}

HRESULT getVersionString(LPTSTR lpszValue, size_t cchLengthIn, size_t *cchLengthOut)

{

HRESULT hr = E_FAIL;

LONG cbLength = (LONG)cchLengthIn * sizeof(TCHAR);

const TCHAR lpszVersionKey[] = _T("Software\\MagicApp");

if(ERROR_SUCCESS == RegQueryValue(HKEY_CURRENT_USER, lpszVersionKey, lpszValue, &cbLength))

{

*cchLengthOut = cbLength / sizeof(TCHAR);

hr = S_OK;

}

else

{

// e.g. ERROR_MORE_DATA

hr = HRESULT_FROM_GetLastError();

}

return hr;

}

int _tmain()

{

TCHAR lpszVersion[256];

size_t cchOut = 0;

HRESULT hr = getVersionString(lpszVersion, sizeof(lpszVersion)/sizeof(lpszVersion[0]), &cchOut);

return SUCCEEDED(hr) ? EXIT_SUCCESS : EXIT_FAILURE;

}

SOLUTION: Spotting Code Defects - #1 (Named Pipe Server)

RobertHorvick — Wed, 21 Jan 2004 22:00:00 GMT

So the results are back – and that was some buggy code!

First I want to thank everyone who played along. Both those that had the courage to post to the public comments and those that replied offline.

Also - before I go further - is this something people would like to see done again?

There are no fewer then 12 defects (several critical), several design issues and still a few questions left to be answered.

I’m glad to see that most of the critical defects were identified however there were a few that were missed. I’ll summarize those:

1) ConnectNamedPipe might lie! If ConnectNamedPipe fails (returns FALSE) it still might have actually connected. You need to check GetLastError() == ERROR_PIPE_CONNECTED to find out if it actually succeeded. This will happen when a client connects to a pipe after CreateNamedPipe but before ConnectNamedPipe is called (I see a lot when debugging).

2) If DisconnectNamedPipe fails we need to abort. If we can’t disconnect then we can’t reconnect and our state is all screwed up.

3) We weren’t closing the pipe handle except in error conditions (this is actually more before we weren’t giving ourselves any way to leave the loop, really a design issue too).

The other defects were:

1) Chance for buffer overflow when appending the pipe name together. Can you say “owned”?

2) We need to provide a reasonable security descriptor when creating the pipe

3) Must test the return value of ImpersonateNamedPipeClient (and handle appropriately)

4) Must only call ImpersonateNamedPipeClient after performing a data transfer on the pipe (a read, in our case)

5) Must only impersonate the magical action

6) Must test the success of RevertToSelf and abort very quickly on failure.

7) Must test the result of our WriteFile on the ACK and close the connection if we fail.

8) Flush the file buffers when (gracefully) closing the connection.

9) Return a reasonable error code at the program’s exit.

There, at least 12 issues.

A 13^th issue was brought up by David Larsson. He noted that the SeImpersonatePrivilage must be present on the caller (the service) otherwise the impersonate might succeed but only at the identity level. It’s really not hard to check for privileges – consider something like this:

HRESULT haveImpersonatePrivilege(HANDLE hProcess, LPBOOL fResult)

{

if(!fResult)

{

return E_INVALIDARG;

}

HANDLE hToken = NULL;

HRESULT hr = E_FAIL;

if(OpenProcessToken(hProcess, TOKEN_QUERY, &hToken))

{

PRIVILEGE_SET privImpersonate = {0};

privImpersonate.PrivilegeCount = 1;

privImpersonate.Control = PRIVILEGE_SET_ALL_NECESSARY;

if(LookupPrivilegeValue(NULL, _T("SeImpersonatePrivilege"), &privImpersonate.Privilege[0].Luid))

{

if(!PrivilegeCheck(hToken, &privImpersonate, fResult))

{

hr = HRESULT_FROM_GetLastError();

}

else

{

hr = HRESULT_FROM_GetLastError();

}

CloseHandle(hToken);

}

else

{

hr = HRESULT_FROM_GetLastError();

}

return hr;

}

Basically open your token, build your privilege set and check your token against the set.

However in our case I didn’t worry about it. I could assert that we had the privilege but another thread could adjust our token privilege between my check and the action. Short of using a critical section to make the operations atomic there is no way to assert the success – and since it is not a privilege elevation risk I’m content letting it ride (until the magical action is well defined, and then maybe it matters more).

So what does our new code look like?

I made the changes based on reader feedback, some personal design choices and the list of defects.

Is it perfect? Probably not. But it’s better.

Will it have defects? If it does please call me on it. These exercises are for my education as much as anything else! J

#include <tchar.h>

#include <windows.h>

#include <stdio.h>

#include <strsafe.h>

HRESULT createReasonableSD(SECURITY_DESCRIPTOR *sd)

{

/// create reasonable SD for intented action

}

void TRACE_Error(HRESULT hr)

{

// do tracing actions...

}

inline HRESULT HRESULT_FROM_GetLastError()

{

DWORD dw = GetLastError();

return HRESULT_FROM_WIN32(dw);

}

const int PIPE_BUFFER_SIZE = 1024

const int PIPE_MAX_NAME_LENGTH = 256;

int _tmain(int argc, TCHAR **argv)

{

if(argc != 2)

{

// DESIGN ISSUE: not fixing in example, but remove to avoid loading the CRT.

_tprintf(_T("pipeServer.exe <pipeName>\n"));

// DESIGN ISSUE: use standard return codes.

return EXIT_FAILURE;

}

HRESULT hr = E_FAIL;

// DESIGN ISSUE: avoid magic numbers (was 256).

// This value is documented in MSDN.

TCHAR lpszPipeName[PIPE_MAX_NAME_LENGTH] = _T("\\\\.\\pipe\\");

// DEFECT: use strsafe library functions for string actions.

// this enforces bounds checking and promotes error checking

hr = StringCbCat(lpszPipeName, sizeof(lpszPipeName), argv[1]);

if(FAILED(hr))

{

// DESIGN ISSUE: trace errors for debugging assistance

TRACE_Error(hr);

return EXIT_FAILURE;

}

// DEFECT: use a reasonable security descriptor.

// a NULL DACL is not generally reasonable.

SECURITY_DESCRIPTOR sd;

hr = createReasonableSD(&sd);

if(SUCCEEDED(hr))

{

SECURITY_ATTRIBUTES sa = {0};

sa.nLength = sizeof(SECURITY_ATTRIBUTES);

sa.lpSecurityDescriptor = &sd;

sa.bInheritHandle = TRUE;

HANDLE hPipe = CreateNamedPipe(

lpszPipeName,

PIPE_ACCESS_DUPLEX,

PIPE_UNLIMITED_INSTANCES,

512,

INFINITE,

&sa);

if(hPipe != INVALID_HANDLE_VALUE)

{

// DESIGN ISSUE: use conditional loops, provide some means of graceful escape.

bool continueAcceptingConnections = true;

while(continueAcceptingConnections)

{

BOOL bConnected = ConnectNamedPipe(hPipe, NULL);

// DEFECT: there is an edge case with ConnectNamedPipe.

// If it returns false, but GetLastError == ERROR_PIPE_CONNECTED

// then everything actually worked.

if(!bConnected)

{

DWORD dwError = GetLastError();

if(ERROR_PIPE_CONNECTED == dwError)

{

bConnected = TRUE;

}

else

{

hr = HRESULT_FROM_WIN32(dwError);

TRACE_Error(hr);

continueAcceptingConnections = false;

}

if(bConnected)

{

// DESIGN ISSUE: avoid magic numbers. (was 1024).

TCHAR lpszCommand[PIPE_BUFFER_SIZE];

DWORD dwRead = 0;

// DESIGN ISSUE: conditional loop rather then infinite with breaks.

bool continueReading = true;

while(continueReading)

{

if(ReadFile(hPipe, lpszCommand, sizeof(lpszCommand), &dwRead, NULL))

{

// DESIGN ISSUE: I prefer the Win32 lstrcmp to _tcscmp.

// especially when this can mean not loading the CRT.

if(lstrcmp(lpszCommand, _T("QUIT")) == 0)

{

continueReading = false;

}

else

{

// DEFECT: Test return value of INPC

// DEFECT: Only call INPC after data transfer on the pipe

// DEFECT: Only impersonate the magical action

if(ImpersonateNamedPipeClient(hPipe))

{

/* PERFORM MAGICAL ACTION based on user input */

// DEFECT: Test return value and exit

// without additional action on failure.

if(!RevertToSelf())

{

exit(EXIT_FAILURE);

}

// DEFECT: test return value of ACK and handle failure

DWORD dwWrote = 0;

if(!WriteFile(hPipe, lpszCommand, dwRead, &dwWrote, NULL))

{

hr = HRESULT_FROM_GetLastError();

TRACE_Error(hr);

continueReading = false;

}

else

{

hr = HRESULT_FROM_GetLastError();

TRACE_Error(hr);

continueReading = false;

}

// DEFECT: flush file buffers before disconnecting the pipe

if(!FlushFileBuffers(hPipe))

{

hr = HRESULT_FROM_GetLastError();

TRACE_Error(hr);

}

// DEFECT: if you can't disconnect the pipe then gracefully quit.

if(!DisconnectNamedPipe(hPipe))

{

hr = HRESULT_FROM_GetLastError();

TRACE_Error(hr);

continueAcceptingConnections = false;

}

// DEFECT: Close the handle in success, as well as error, conditions

if(!CloseHandle(hPipe))

{

TRACE_Error(HRESULT_FROM_GetLastError());

}

else

{

TRACE_Error(HRESULT_FROM_GetLastError());

}

// DEFECT: return a reasonable error code at program end.

return SUCCEEDED(hr) ? EXIT_SUCCESS : EXIT_FAILURE;

}

Valuable?

Waste of time?

Let me know!

Thanks.

Spotting Code Defects - #1 (Named Pipe Server)

RobertHorvick — Mon, 19 Jan 2004 19:48:00 GMT

When you read bad code you learn what not to do. You learn to identify the many classes of errors and the patterns that often lead up to them.

When you read good code you learn how to write good code. You observe “tricks” of good programmers (the best tricks aren’t tricks at all), you see defensive coding, pessimistic coding, efficient coding. Robust code that can run anywhere at any time and handle any situation with grace and security.

The question is – do you know the difference between good and bad code?

This is a basic pipe server. It sits around waiting for a client to connect, reads some input and performs some action (the action is not implemented, it’s not a meaningful detail), and when it’s done it write backs to the client to acknowledge that it performed the action.

To ensure that the client does not do something they don’t have permissions to do, the server impersonates the client before performing that magical action (so assume it could be registry read/write, executing a process, processing some file, etc).

While this is a console application, assume that this could be running under a privileged account on the system (e.g. member of Local Administrators).

I wish that .Text allowed me to hide the comments until I post the defects, but they don’t. So if you don’t want spoilers don’t read the comments. If you do … then do. If someone else has already posted a defect feel free to list it again (if you really identified it on your own). It’s the honor system.

The only prize is a warm fuzzy feeling you get from participating.

#include <tchar.h>

#include <windows.h>

#include <stdio.h>

int _tmain(int argc, TCHAR **argv)

{

if(argc != 2)

{

_tprintf(_T("pipeServer.exe <pipeName>\n"));

return 100;

}

TCHAR lpszPipeName[256] = _T("\\\\.\\pipe\\");

_tcscat(lpszPipeName, argv[1]);

HANDLE hPipe = CreateNamedPipe(

lpszPipeName,

PIPE_ACCESS_DUPLEX,

PIPE_UNLIMITED_INSTANCES,

512,

INFINITE,

NULL);

if(hPipe != NULL)

{

for(;;)

{

if(ConnectNamedPipe(hPipe, NULL))

{

TCHAR lpszCommand[1024];

DWORD dwRead = 0;

ImpersonateNamedPipeClient(hPipe);

for(;;)

{

if(ReadFile(hPipe, lpszCommand, sizeof(lpszCommand), &dwRead, NULL))

{

if(_tcscmp(lpszCommand, _T("QUIT")) == 0)

{

break;

}

else

{

/* PERFORM MAGICAL ACTION based on user input */

DWORD dwWrote = 0;

WriteFile(hPipe, lpszCommand, dwRead, &dwWrote, NULL);

}

RevertToSelf();

DisconnectNamedPipe(hPipe);

}

else

{

CloseHandle(hPipe);

break;

}