Comments on: Long time no see, hello Chrome

By: BK RIos

BK RIos — Thu, 04 Dec 2008 07:07:21 +0000

Swwweeet! Thor’s Back! Look out browser world!

By: Thor Larholm

Thor Larholm — Tue, 25 Nov 2008 14:06:03 +0000

Thanks Nate, I have some new vulnerabilities lying around that I might just have to post

By: Nate McFeters

Nate McFeters — Sun, 23 Nov 2008 18:14:44 +0000

Very interesting find Thor. Hoping to see more posts from you soon.

-Nate

By: Wes

Wes — Tue, 14 Oct 2008 01:28:41 +0000

I diff’ed the file file_util_win.cc from prior to the code fix to better understand. Trying to learn the code to start patch work. Great catch.

By: mxatone

mxatone — Wed, 10 Sep 2008 16:25:51 +0000

Hum the issue is not on the snippet code you copy past.

The diff is here : http://src.chromium.org/viewvc/chrome/branches/chrome_official_branch/src/chrome/common/win_util.cc?r1=1766&r2=1765&pathrev=1766

The code was :

// Initially populated by the file component of ’suggested_name’, this buffer
// will be written into by Windows when the user is done with the dialog box.
wchar_t file_name[MAX_PATH+1];
std::wstring file_part = file_util::GetFilenameFromPath(suggested_name);
memcpy(file_name, file_part.c_str(), (file_part.length()+1) * sizeof(wchar_t));

and becomes:

// The size of the in/out buffer in number of characters we pass to win32
// GetSaveFileName. From MSDN “The buffer must be large enough to store the
// path and file name string or strings, including the terminating NULL
// character. … The buffer should be at least 256 characters long.”.
static const size_t kMaxFilenameSize = MAX_PATH + 1;

// Initially populated by the file component of ’suggested_name’, this buffer
// will be written into by Windows when the user is done with the dialog box.
std::wstring file_part = file_util::GetFilenameFromPath(suggested_name);
wchar_t file_name[kMaxFilenameSize];
base::wclscpy(file_name, file_part.c_str(), kMaxFilenameSize);

file_part length is not trusted anymore.

It is because GetDirectoryFromPath is not restrained to a specific size. If the path is superior to MAX_PATH, GetFullPathName return the number of required chars (not 0) and then the entire string is returned.

By: Thor Larholm

Thor Larholm — Wed, 10 Sep 2008 15:04:28 +0000

You’re not missing anything. The overflow itself is triggered in GetDirectoryFromPath when path.c_str() is called, but the actual corruption happens earlier.

Cheers
Thor

By: Harry Johnston

Harry Johnston — Tue, 09 Sep 2008 21:58:42 +0000

I don’t see a buffer overflow in that function. GetFullPathName won’t write more than MAX_PATH characters, which is the size of the buffer.

The function fails to test the return value of GetFullPathName to see if the buffer was too small, and the documentation doesn’t specify what happens to file_ptr in this case, which means that the string length might be calculated incorrectly. However, as the string length is only passed to the wstring constructor, that can’t cause a buffer overflow either.

Am I missing something?