Comments for Larholm.com http://larholm.com Me, myself and I Tue, 09 Mar 2010 22:44:14 +0000 http://wordpress.org/?v=2.6.2 Comment on Safari for Windows, 0day exploit in 2 hours by TimWeb » Windows Safari http://larholm.com/2007/06/12/safari-for-windows-0day-exploit-in-2-hours/#comment-34851 TimWeb » Windows Safari Fri, 05 Dec 2008 22:05:43 +0000 http://test.larholm.com/?p=14#comment-34851 [...] June 13th: Apparently there have already been several vulnerabilities found in [...] [...] June 13th: Apparently there have already been several vulnerabilities found in [...]

]]> Comment on Long time no see, hello Chrome by BK RIos http://larholm.com/2008/09/09/long-time-no-see-hello-chrome/#comment-34786 BK RIos Thu, 04 Dec 2008 07:07:21 +0000 http://larholm.com/?p=29#comment-34786 Swwweeet! Thor's Back! Look out browser world! Swwweeet! Thor’s Back! Look out browser world!

]]> Comment on Long time no see, hello Chrome by Thor Larholm http://larholm.com/2008/09/09/long-time-no-see-hello-chrome/#comment-34404 Thor Larholm Tue, 25 Nov 2008 14:06:03 +0000 http://larholm.com/?p=29#comment-34404 Thanks Nate, I have some new vulnerabilities lying around that I might just have to post :) Thanks Nate, I have some new vulnerabilities lying around that I might just have to post :)

]]> Comment on Long time no see, hello Chrome by Nate McFeters http://larholm.com/2008/09/09/long-time-no-see-hello-chrome/#comment-34331 Nate McFeters Sun, 23 Nov 2008 18:14:44 +0000 http://larholm.com/?p=29#comment-34331 Very interesting find Thor. Hoping to see more posts from you soon. -Nate Very interesting find Thor. Hoping to see more posts from you soon.

-Nate

]]> Comment on Internet Explorer 0day Exploit by KVIrc 3.4.2 URI handler in combination with IE exploitable | IRC-Junkie.org http://larholm.com/2007/07/10/internet-explorer-0day-exploit/#comment-34287 KVIrc 3.4.2 URI handler in combination with IE exploitable | IRC-Junkie.org Sat, 22 Nov 2008 15:47:11 +0000 http://larholm.com/2007/07/10/internet-explorer-0day-exploit/#comment-34287 [...] malicious link is opened with Microsoft’s Internet Explorer and is possible because of its unique way to handle double quotes (”) in links. This time it is not possible to just let the client of a victim crash but to execute a [...] [...] malicious link is opened with Microsoft’s Internet Explorer and is possible because of its unique way to handle double quotes (”) in links. This time it is not possible to just let the client of a victim crash but to execute a [...]

]]> Comment on PHPMailer 0day remote command execution by hacker.com.br » Blog Archive » PHPMailer Vulnerável http://larholm.com/2007/06/11/phpmailer-0day-remote-execution/#comment-33479 hacker.com.br » Blog Archive » PHPMailer Vulnerável Sat, 08 Nov 2008 13:37:16 +0000 http://test.larholm.com/?p=13#comment-33479 [...] Mambo LaiThai Global 4.5.6 Release Notes (MamboXChange) PHPMailer 0day remote execution (Thor Larholm) Announcements: GLPI 0.68.3-2 bug fixes (GLPI) Knowledgeroot Knowledgebase Release [...] [...] Mambo LaiThai Global 4.5.6 Release Notes (MamboXChange) PHPMailer 0day remote execution (Thor Larholm) Announcements: GLPI 0.68.3-2 bug fixes (GLPI) Knowledgeroot Knowledgebase Release [...]

]]> Comment on Cheers and musing by Richard Bejtlich http://larholm.com/2007/04/05/hello-world-2/#comment-33180 Richard Bejtlich Sun, 02 Nov 2008 18:33:18 +0000 http://test.larholm.com/?p=4#comment-33180 Destroy him, my robots! Destroy him, my robots!

]]> Comment on Safari for Windows, 0day exploit in 2 hours by klee http://larholm.com/2007/06/12/safari-for-windows-0day-exploit-in-2-hours/#comment-32698 klee Thu, 23 Oct 2008 15:58:30 +0000 http://test.larholm.com/?p=14#comment-32698 Yeah. Windows versions has lots of bugs that are fixed after some time. Like this one, found recently: <a href='http://anotherquirk.blogspot.com/2008/10/safari-submit-back-submit-oops.html' rel="nofollow">Safari: submit, back, submit... ooops</a> Yeah. Windows versions has lots of bugs that are fixed after some time. Like this one, found recently:

Safari: submit, back, submit… ooops

]]> Comment on Long time no see, hello Chrome by Wes http://larholm.com/2008/09/09/long-time-no-see-hello-chrome/#comment-32258 Wes Tue, 14 Oct 2008 01:28:41 +0000 http://larholm.com/?p=29#comment-32258 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. 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.

]]> Comment on Long time no see, hello Chrome by mxatone http://larholm.com/2008/09/09/long-time-no-see-hello-chrome/#comment-31210 mxatone Wed, 10 Sep 2008 16:25:51 +0000 http://larholm.com/?p=29#comment-31210 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. 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.

]]>