Well it’s been a long time since I last wrote any entries here. What, almost a year.. time flies by when you’re having fun :) especially when you’re working a lot.

Just wanted to give a quick heads-up that I will start posting again. And what better way to celebrate that than by expanding on that buffer overflow which SVRT-Bkis found this friday.

The overflow is triggered by an overly long TITLE tag, which is later used by SaveFileAsWithFilter as a suggested file name.

The actual overflow is triggered in file_util_win.cc, here’s a snippet:

std::wstring GetDirectoryFromPath(const std::wstring& path) {

wchar_t path_buffer[MAX_PATH];

wchar_t* file_ptr = NULL;

if (GetFullPathName(path.c_str(), MAX_PATH, path_buffer, &file_ptr) == 0)

The current Proof-of-Concept exploit requires social engineering and manual interaction from the user in order to be triggered.

However, the GetDirectoryFromPath function is also being used elsewhere, and one of those places is in download_manager.cc, here’s a snippet:

void DownloadManager::CheckIfSuggestedPathExists(DownloadCreateInfo* info) {
DCHECK(info);

// Check writability of the suggested path. If we can’t write to it, default
// to the user’s “My Documents” directory. We’ll prompt them in this case.
std::wstring path = file_util::GetDirectoryFromPath(info->suggested_path);

This code is automatically called whenever Chrome initiates a file download. The suggested_path in the DownloadCreateInfo struct can be based on different inputs, such as the URL itself. It can also be based on more specific information which will take precedence, such as the one we can specify in a Content-Disposition HTTP header. Therefor, we can automatically trigger the buffer overflow with the following HTTP headers:

Content-Type: application/x-zip-compressed
Content-Disposition: attachment; filename=”$overflowingstringiscontainedwithinthesequotes$”

With that I will go back to enjoying my Laphroaig :)

UPDATE:

I reported this to the Chromium project as Issue 1980.
They have confirmed that this is now fixed in Google Chrome 0.2.149.29.