3 ms·
Consider something like wchar_t buff[MAX_PATH] = {0}; int (*callback)(void); if (NULL == ::PathCombine(buff, /* ... */)) { return; // Er
by mappu 13y ago
Consider something like
wchar_t buff[MAX_PATH] = {0};
int (*callback)(void);
if (NULL == ::PathCombine(buff, /* ... */)) {
return; // Error, don't continue
}
callback();
If this is compiled with a small MAX_PATH and run on a system with a large MAX_PATH, then the system can write a value that's too long, overflow `buff` and overwrite `callback`, which would then execute the buffer contents and probably crash. Building an exploit out of this is left as an exercise for the reader (e.g. supply PathCombine with some shellcode)
I picked a random API, but there are several win32 functions which accept a character buffer without an explicit size, and mention MAX_PATH in the MSDN documentation.
- XorNot 13y agoYou could patch those functions if you were Microsoft and overload them so they had a form which worked explicitly with long paths, though I suppose that's getting beside the point since Windows already has the necessary APIs - the problem is MS for some reason insists on not transitioning to them.
- jussij 13y agoThere is nothing to say the developer did not create their own version of that API function: if (NULL == ::MySpecialPathCombine(buff, /* ... */)) { return; // Error, don't continue } There is no way Microsoft can patch that, but the problem is still there. Also back to the PathCombine example. When the third party executable was compiled, the Windows SDK would have defined PathCombine to take a string the size of 260 (or whatever value MAX_PATH was at the time it was compiled). If Microsoft did patch the call and then return more than 260 it would just crash the calling third party executable as it would only be expecting at most 260 characters. In effect Microsoft would effectively re-defined the static PathCombine API signature at runtime and making it some sort of dynamic signature.