4 ms·

MAX_PATH is a #define, so by increasing it you immediately cause buffer overflow vulnerabilities in every program which ever does a wchar_t foo[MAX_PATH] = {0};

by mappu 13y ago

MAX_PATH is a #define, so by increasing it you immediately cause buffer overflow vulnerabilities in every program which ever does a wchar_t foo[MAX_PATH] = {0}; since the old limit will be baked into the binaries. Even if VS restricts itself to 32k-aware APIs, you'll hit this eventually when shelling out or calling any third-party code. Never going to happen.

jussij 13y ago
Not only is it never going to happen, they would be mad to try. Even, if they did make the change and somehow managed to re-test and fix all their software, they would still have created the potential of breaking every piece of Windows software in existence. Making the change has to potential to cause untold chaos, the likes never before seen in the software industry. It would make Y2K look like a paper cut.
XorNot 13y ago
Ok I may just be overtired but how would changing a define cause this? Its a static number - you make it bigger and ordinary programs just can't see the extra length in buffers. They're not going to be assuming they can execute memory they didn't allocate, and Windows won't allocate them memory from a buffer string that's already been handed out. Even if they're just looking for a null terminator, they'll crash when they overrun the bounds if written properly.
- 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 ago
    You 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 ago
      There 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.

by mappu 13y ago

jussij 13y ago

Not only is it never going to happen, they would be mad to try. Even, if they did make the change and somehow managed to re-test and fix all their software, they would still have created the potential of breaking every piece of Windows software in existence. Making the change has to potential to cause untold chaos, the likes never before seen in the software industry. It would make Y2K look like a paper cut.

XorNot 13y ago

Ok I may just be overtired but how would changing a define cause this? Its a static number - you make it bigger and ordinary programs just can't see the extra length in buffers. They're not going to be assuming they can execute memory they didn't allocate, and Windows won't allocate them memory from a buffer string that's already been handed out. Even if they're just looking for a null terminator, they'll crash when they overrun the bounds if written properly.

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 ago
  You 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 ago
    There 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.