Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
KJK::Hyperion ha scritto:
ShellExecute is not called ExecuteUri [...]
This function isn't, either, but it should be close enough:
/* --- 8 -- 8 -SNIP- 8 -- 8 -- 8 -SNIP- 8 --- */
/*
* Helper functions to unambiguously execute URLs with ShellExecute(Ex).
* Author: KJK::Hyperion [EMAIL PROTECTED]
*/
/*
* Copyright (c) 2007 KJK::Hyperion
*
* Permission is hereby granted, free of charge, to any person obtaining
* a copy of this software and associated documentation files (the
* Software), to deal in the Software without restriction, including
* without limitation the rights to use, copy, modify, merge, publish,
* distribute, sublicense, and/or sell copies of the Software, and to
* permit persons to whom the Software is furnished to do so, subject to
* the following conditions:
*
* The above copyright notice and this permission notice shall be
* included in all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
#define WIN32_LEAN_AND_MEAN
#include windows.h
#include shellapi.h
#include shlwapi.h
#include wininet.h
#include strsafe.h
BOOL ShellExecuteURLExInternal(LPSHELLEXECUTEINFO lpExecInfo)
{
BOOL bRet;
DWORD dwErr;
HRESULT hr;
PARSEDURL pu;
TCHAR szSchemeBuffer[INTERNET_MAX_SCHEME_LENGTH + 1];
HKEY hkeyClass;
/* Default error codes */
bRet = FALSE;
dwErr = ERROR_INVALID_PARAMETER;
hr = S_OK;
lpExecInfo-hInstApp =
(HINSTANCE)UlongToHandle(SE_ERR_ACCESSDENIED);
/* Validate parameters */
if
(
lpExecInfo-cbSize == sizeof(*lpExecInfo)
lpExecInfo-lpFile != NULL
(lpExecInfo-fMask SEE_MASK_INVOKEIDLIST) == 0
(lpExecInfo-fMask SEE_MASK_CLASSNAME) == 0
(lpExecInfo-fMask 0x0040) == 0 /* SEE_MASK_FILEANDURL */
)
{
/* Extract the scheme out of the URL */
pu.cbSize = sizeof(pu);
hr = ParseURL(lpExecInfo-lpFile, pu);
/* Is the URL really, unambiguously an URL? */
if
(
SUCCEEDED(hr)
pu.pszProtocol == lpExecInfo-lpFile
pu.pszProtocol[pu.cchProtocol] == TEXT(':')
)
{
/* We need the scheme name NUL-terminated, so we copy it */
hr = StringCbCopyN
(
szSchemeBuffer,
sizeof(szSchemeBuffer),
pu.pszProtocol,
pu.cchProtocol * sizeof(TCHAR)
);
if(SUCCEEDED(hr))
{
/* Is the URL scheme a registered ProgId? */
hr = AssocQueryKey
(
ASSOCF_INIT_IGNOREUNKNOWN,
ASSOCKEY_CLASS,
szSchemeBuffer,
NULL,
hkeyClass
);
if(SUCCEEDED(hr))
{
/* Is the ProgId really an URL scheme? */
dwErr = RegQueryValueEx
(
hkeyClass,
TEXT(URL Protocol),
NULL,
NULL,
NULL,
NULL
);
/* All clear! */
if(dwErr == NO_ERROR || dwErr == ERROR_MORE_DATA)
{
/* Don't let ShellExecuteEx guess */
lpExecInfo-fMask |= SEE_MASK_CLASSKEY;
lpExecInfo-lpClass = NULL;
lpExecInfo-hkeyClass = hkeyClass;
/* Finally, execute the damn URL */
bRet = ShellExecuteEx(lpExecInfo);
/* To preserve ShellExecuteEx's last error */
dwErr = NO_ERROR;
}
RegCloseKey(hkeyClass);
}
}
}
}
/* Last error was a HRESULT */
if(FAILED(hr))
{
/* Try to dissect it */
if(HRESULT_FACILITY(hr) == FACILITY_WIN32)
dwErr = HRESULT_CODE(hr);
else
dwErr = hr;
}
/* We have a last error to set */
if(dwErr)
SetLastError(dwErr);
return bRet;
}
BOOL ShellExecuteURLEx(LPSHELLEXECUTEINFO lpExecInfo)
{
BOOL bRet;
SHELLEXECUTEINFO ExecInfo;
/* We use a copy of the parameters, because you never know */
CopyMemory(ExecInfo, lpExecInfo, sizeof(ExecInfo));
/* Do the magic */
bRet =
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
On Sun, 7 Oct 2007, KJK::Hyperion wrote: You cannot compare them, Windows doesn't have argc/argv, it passes around a flat string command line. and Strings are the root of all evil. Whenever you pass structured data around in a string, you are passing around _communism_. Cough, cough... --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] Resistance is futile. Open your source code and prepare for assimilation. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
Microsoft acknowledged that it was their problem all along: Microsoft Security Advisory (943521) URL Handling Vulnerability in Windows XP and Windows Server 2003 with Windows Internet Explorer 7 Could Allow Remote Code Execution http://www.microsoft.com/technet/security/advisory/943521.mspx MSRC Blog: Additional Details and Background on Security Advisory 943521 http://blogs.technet.com/msrc/archive/2007/10/10/msrc-blog-additional-details-and-background-on-security-advisory-943521.aspx I wonder what made them realize their mistake. Cheers, Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
Dear All, Hi everyone. This is Jonathan from the SWI team in the MSRC. Weve just released Security Advisory 943521 regarding a vulnerability affecting Windows Server 2003 and Windows XP with Internet Explorer 7 installed. As you have probably noted theres been a fair amount of discussion on this issue. One of the reasons we are releasing this Advisory is due to increased risk given recent discussions about how this vulnerability could be used in attacks. Another reason is to clear up the confusion we see between the URI issue covered in todays Advisory and the protocol handler issue we documented in July in this IE Blog. The final reason is we actually contributed to some of the confusion by providing an incorrect set of talking points to Heise. Because these issues look very similar were going to have some deep discussion on how Windows handles URIs. To help explain the difference in detail, my co-workers Dave and Chen have helped me put together some information... http://blogs.technet.com/msrc/archive/2007/10/10/msrc-blog-additional-details-and-background-on-security-advisory-943521.aspx -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
Juergen Schmidt wrote: the URI handling problem on Windows XP systems with IE 7 installed hits a lot of applications, not only Firefox (and mIRC) -- namely Skype, Acrobat Reader, Miranda, Netscape. Testing shows that the mailto: thingy in Acrobat also works on Windows 2003 Server, SP2. -- Mit freundlichen Gruessen Andreas Lindenblatt Solution - The Computer People e.K. Apoldaer Weg 7, 68309 Mannheim Amtsgericht Mannheim, HRA 4576 -- Some people have twenty years of experience, some people have one year of experience twenty times over. -- Anonymous http://www.solution.de fon: +49 621 715112 / fax: +49 621 7140721 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
Dear Pappa Bär, 3 What URL is is defined by RFC 1738, what mailto: is is defined by RFC 3 2368. String in question is definetly _not_ URL because of %xx and . Thank you for clarifying, though I must tell you I never claimed this was a URL. Did I ? So why are you trying to tell me it's not ? [snipped very obvious stuff] -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
Dear KJK, KH I repeat. Nowhere is said that ShellExecute (the default run stuff KH function) takes URLs. Nowehere is determined that it does NOT take URLS. You forget a consideration, an Important one in my opinion. This is not straight forward ShellExecute(), it's a shellexecute call to a Handler. This makes a world of difference because you cannot tell what the handler does (at least you are not supposed to). I mean for example this one, the mailto: handler is defined on my box I am writing from as : [HKEY_CLASSES_ROOT\mailto\shell\open\command] @=C:\\Programme\\The Bat!\\thebat.exe\ %1 As a thid party developer I am not supposed to know what that application does as a third party developer I am not supposed to collect every possible application on earth and test what stuff I have to filter out to protect THAT application. Still with me ? *I* think, normalistaion _in this particular case_ has to be done by the function. Sorry my opinion. -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://support.microsoft.com/kb/224816 = Use ShellExecute to launch the default Web browser I agree that we need sanity checking on the applications accepting the input, but the fact remains that ShellExecute is doing dangerous things based on bad input. Both application developers and Microsoft should work on fixing this. Greg Rubin [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) - WinPT 1.2.0 iD8DBQFHC+de5KDU23nQpRcRAoNKAJ9TvOiL16hKjTV2oYsDJtOazcZEMwCfYv/C +g7WwL6VKCyRc9a5doKbdAg= =UdN+ -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
Since this issue is a great big rats nest, I promise a third-party patch for it by tomorrow. Deal? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
Dear Thierry Zoller, --Saturday, October 6, 2007, 9:06:51 PM, you wrote to [EMAIL PROTECTED]: TZ Dear Geo., G If the application is what exposes the URI handling routine to untrusted G code from the internet, TZ Sorry, Untrusted code from the internet ? TZ The user clicks on a mailto link, is that untrusted code? TZ Or the mailto link is clicked for him. What URL is is defined by RFC 1738, what mailto: is is defined by RFC 2368. String in question is definetly _not_ URL because of %xx and . Double quote is URL delimiter and is not a part of URL, in this case application incorrectly parses and highlights URL (it should stop before ). %xx is invalid character encoding. And altogether it's, for sure, not mailto: URL. Passing unchecked user input to function called ShellExecute(), where URL is expected, is a bug. So, while there is a security vulnerability in Windows, there is also security vulnerability in mIRC, Acrobat Reader, Netscape, Miranda, Skype, because ShellExecute() behaviour is not defined for the case non-URL data is passed to URL processor. -- ~/ZARAZA http://securityvulns.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
there have always been these vluns On 10/6/07, Geo. [EMAIL PROTECTED] wrote: - Original Message - From: Thierry Zoller [EMAIL PROTECTED] The user clicks on a mailto link, is that untrusted code? Depends on where the link comes from. If it's a shortcut on the users desktop no it's not untrusted, if it's in a PDF file you received in your email then yes it's untrusted. Anyways, the mailto link POST IE7 has a flaw/threat/vulnerablity it hasn't had PRE IE7. The problem here is the root cause, the root cause is that IE7 Ok I'm game, so then show me this exploit without having Acrobat on your system. IE7 handles mailto links in untrusted web pages. Put the mailto link in an untrusted html page and make it work with IE7. Geo. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- http://www.goldwatches.com/mens/cufflinks.html http://www.jewelerslounge.com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
I appreciate everyone's replies. Thanks for the replies and the explanations. I'm not a Microsoft developer, I'm just a security consultant. I didn't understand the nature of the central issue, at first, but now I do. Thanks again. Roger * *Roger A. Grimes, InfoWorld, Security Columnist *CPA, CISSP, CISA, MCSE: Security (2000/2003), CEH, yada...yada... *email: [EMAIL PROTECTED] or [EMAIL PROTECTED] *Author of Windows Vista Security: Securing Vista Against Malicious Attacks (Wiley) *http://www.amazon.com/Windows-Vista-Security-Securing-Malicious/dp/0470 101555 * -Original Message- From: Thierry Zoller [mailto:[EMAIL PROTECTED] Sent: Saturday, October 06, 2007 12:13 PM To: Juergen Schmidt; [EMAIL PROTECTED]; full-disclosure@lists.grok.org.uk Subject: Re[2]: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype Dear Roger, RAG The applications in question are accepting abitrary input and not validating correctly. Please define correctly in case of an Uri handler. I am not aware of special attack vectors or injections that I should be filtering in case of mailto: calls, are there any? If yes, where are they documented and where can I find them ? As a developer I have no control over what Windows does with this handler, I have to trust it. Are all Application developers now required to work around obvious bugs in the way Windows handles the mailto: handler ? What you call for is in essence - mitigation, yes it's fine to mitigate a vulnerability. But shouldn't we be concentrating on finding and fixing the root cause instead of trying to mitigate the problem in (hundrets) of third-party applications ? RAG How is that a Microsoft or Windows problem? How is that _not_ a Windows Problem ? RAG Don't get me wrong, I want to protect end-users as much as the next RAG person (as does MS), but if it is the application not validating RAG correctly, could there not be hundreds of potential characters and RAG strings that cause input validation problems in particular RAG circumstances, which will vary according to the application? We are speaking of the mailto: handler here that _seems_ to be broken POST IE7 installation. (Again IMHO) Could you explain me why POST Ie7: mailto:test%../../../../windows/system32/calc.exe.cmd Executes calc mailto:test%../../../../windows/system32/calc.exe.txt executes notepad trying to open calc mailto:test%../../../../windows/system32/calc.exe.doc Now the surprise : OFFICE (Winword) opens, SHELLS the mailto handler BUT replaces % with %25 and with %22 and surprise it does NOT execute calc but your mail client. Yes! Winword mitigated the problem/vulnerability. Try it, open Winword, add hyperlink with mailto:test%../../../../windows/system32/calc.exe.cmd click on it, and check process explorer to see the result winword replaced the % prior to shelling mailto. Now this is some serious voodoo. I think some persons were aware of the problem but couldn't get the responsible parties to fix it, becuase of arguments like yours. This is a assumption, not a fact. I have not been there and heard that... RAG If Microsoft scrubs out every potential malicious character, it's RAG bound to break lots of legitimate applications. What genuine application uses this [1] way to call a mailto: handler ? [1] mailto:test%../../../../windows/system32/calc.exe.cmd RAG At what point should Microsoft scrub URIs so that it hands off only RAG legitmate characters most of the time? How could Microsoft RAG determine ahead of time what is and isn't legitimate characters to RAG pass to applications they don't own? It's not that they should decide what and what to pass or not to pass on, the problem in the example Juergen sent is - what they pass INTERNALY not to third party applications. RAG If they block RAG characters that affect certain applications, it might cause RAG problems in other applications that have no problem with the character(s) in question? RAG What is the solution? The easy answer is to block the % character RAG in this particular instance...but that's just a whack-a-mole fix. The Solution might be : - Determine the root cause - Determine the attack vectors - Determine whether it's wise to fix it at the root or try to mitigate around it. RAG I'm asking, with genuine interest and a listening ear, what is the RAG best long term solution you envision, to solve the larger problem? Certainly it's not mitigating through hundrets of third party applications. -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
... ciao: : on 10-6-2007 Kurt Dillard writ: : In my opinion, every application should handle incoming data as bad data. finally. : Its poor programming to assume that incoming data is properly formatted and : safe to process as is, even if the data is supposed to come from a process : you own. actually, i think it's shoddy programming. : Why so extreme? or perhaps more properly, why would considerate programming be considered extreme ... -- ... i'm a man, but i can change, if i have to , i guess ... ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
I keep thinking of that wonderful saying that to assume is to make an ass out of you and me. Certainly is true when programming. Geoff Sent from my BlackBerry wireless handheld. -Original Message- From: terry white [EMAIL PROTECTED] Date: Sun, 7 Oct 2007 00:57:02 To:[EMAIL PROTECTED] Cc:full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype ... ciao: : on 10-6-2007 Kurt Dillard writ: : In my opinion, every application should handle incoming data as bad data. finally. : Its poor programming to assume that incoming data is properly formatted and : safe to process as is, even if the data is supposed to come from a process : you own. actually, i think it's shoddy programming. : Why so extreme? or perhaps more properly, why would considerate programming be considered extreme ... -- ... i'm a man, but i can change, if i have to , i guess ... ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
On Sat, 06 Oct 2007 12:43:16 EDT, Geo. said: If the application is what exposes the URI handling routine to untrusted code from the internet, then it's the application's job to make sure that code is trusted before exposing system components to it's commands, no? I think that given a system service that says I will handle a mailto: URI, that a programmer can *reasonably* expect the following: 1) That it will be handed to a program that actually does e-mail, and not a calculator. calc.exe hasn't *yet* followed the programming aphorism that every program grows until it can read e-mail. 2) That said program can protect itself against overtly malicious input. When people pcp a chocky in their mouth, they don't expect steel bolts to string out and pierce their cheeks -- Monty Python. pgp0omixJD1mc.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
Dear Geo, Thank you for the challenge, Geo. Your trying to get the discussion in a direction that doesn't serve the purpose of the finding, nor would it proof anything. I welcome your task though I'd like you to know that I don't think I have to proof anything to you. However if you pay enough I might invest some time ;) Again Geo, NOBODY has said that this is a vulnerability OF IE7 ITSELF we said the handler that IE7 installs is broken. I honestly think we have discussed the problem itself enough, it's up to Microsoft now to either rethink their position or just hold on to their position. PS [1] : http:%xx../../../../../../../../../windows/system32/calc.exe.cmd [1] http://www.heise.de/security/news/meldung/96921/URI-Problem-zieht-weitere-Kreise-Acrobat-Reader-und-Netscape-anfaellig-2-Update -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
What I see as root cause, is ... Windows ... may parse and re-parse a command an unspecified number of times. Compared to Unix, it confuses system(3) with execl(3). ... A number of similar issues would be solved if Windows would respect the command with one argument setting, parsing the registry key just once. You cannot compare them, Windows [has] ShellExecute and CreateProcess ... In this particular case, I have to reluctantly agree with Microsoft, due to my output side bears the burden of validation doctrine. ... ... you should perform normalization or validation before passing a command string to a function that is designed and documented to invoke arbitrary programs in arbitrary ways, *not* safely execute an URI ... Windows already does special %-decoding to URL protocol handlers as per http://msdn2.microsoft.com/en-us/library/aa767914.aspx (whereas I do not think it does that to most other application launch registry keys). It should also protect blanks and quote characters, and anything else that could upset or confuse later processing. Cheers, Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
Paul Szabo ha scritto: Windows already does special %-decoding to URL protocol handlers as per http://msdn2.microsoft.com/en-us/library/aa767914.aspx (whereas I do not think it does that to most other application launch registry keys). It should also protect blanks and quote characters, and anything else that could upset or confuse later processing. I will look into the matter. Now I'm curious where, exactly, the shit happens. We're bound to learn something from the experience ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
Kurt Dillard wrote: In my opinion, every application should handle incoming data as bad data. Its poor programming to assume that incoming data is properly formatted and safe to process as is, even if the data is supposed to come from a process you own. Why so extreme? Because the bad guys are going to figure out how to get bad data to your code using pathways you didn't consider. In other words, I agree with Geo that each of the applications should inspect the URI before processing it. The OS components that are involved should too, but the 3rd party apps should never assume that IE or whatever has done so. URIs are open-ended. There are dozens of existing schemes, and new schemes are being added all of the time. It is unreasonable to expect every program which handles URIs to validate them against such a complex and unstable specification, particularly when it's merely passing them through, and not actually *processing* them. A web browser should be expected to validate URIs which it is processing itself (e.g. http: and https: URIs), as well as validating against generic URI syntax (to which the example URI conforms). For URIs which it passes to an external handler (e.g. mailto:), it only needs to identify the scheme (to select the correct handler); it is the handler's responsibility to validate its own URIs (i.e. mail programs need to validate mailto: URIs). The fundamental flaw here is that Windows' built-in URI handler doesn't invoke external programs correctly, resulting in a shell-injection attack. This is no different to the hundreds or even thousands of other shell-injection attacks which have been reported on BugTraq and FD over the years. Modifying individual programs to protect against a shell-injection bug in Windows' URI handler is a workaround (mitigation strategy), not a fix. -- Glynn Clements [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
Glynn Clements ha scritto: Modifying individual programs to protect against a shell-injection bug in Windows' URI handler is a workaround (mitigation strategy), not a fix. I repeat. Nowhere is said that ShellExecute (the default run stuff function) takes URLs. It takes strings. A desktop shortcut called www.google.com can hijack execution of www.google.com (without a http://; prefix), and many other similar issues. If you pass a path to it, it damn better had to be an absolute path. If you pass an URL, it damn better had to be normalized. If your application handles documents that can include URLs, you *must* implement normalization, goddamn it (stop pasting strings together, fuckers, the sorry state of security is entirely your goddamn fault! Skype.exe is 22 MB, surely there is room in there for a normalization routine) This is an issue of ambiguous strings that could be URLs or could be not. It does suck that older applications will remain vulnerable until a fix (if you want to lobby, lobby right. Work that angle), but I still maintain that, in principle, this is the fault of sloppy third party developers ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
- Original Message - From: [EMAIL PROTECTED] 2) That said program can protect itself against overtly malicious input. Ok then, I can mark you down as one who believes that all the php exploits blamed on bad code writing are actually the fault of php and not the application coded using it's powerful functionality? Geo. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
- Original Message - From: Thierry Zoller [EMAIL PROTECTED] Again Geo, NOBODY has said that this is a vulnerability OF IE7 ITSELF we said the handler that IE7 installs is broken. I'm not disagreeing with that statement. I'm saying this input should never get that far. Geo. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
- Original Message - From: Glynn Clements [EMAIL PROTECTED] URIs which it passes to an external handler (e.g. mailto:), it only needs to identify the scheme (to select the correct handler); it is the handler's responsibility to validate its own URIs (i.e. mail programs need to validate mailto: URIs). I don't agree. Whatever program takes input from an untrusted source, it's that programs duty to sanitize the input before passing it on to internal components. It's like a firewall, you filter before it gets inside the system. Example, an ftp server has to sanitize filenames to prevent useage of streams on NTFS, you don't blame the filesystem that the input gets passed to, it's the job of the ftp server to do the sanitizing of untrusted input. Geo. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
Geo. ha scritto: 2) That said program can protect itself against overtly malicious input. Ok then, I can mark you down as one who believes that all the php exploits blamed on bad code writing are actually the fault of php and not the application coded using it's powerful functionality? No no, mark *me*. PHP is the language... ... that didn't support prepared SQL statements until *revision 5* ... whose syntax can be changed arbitrarily by configuration ... whose applications can, by default, have their code arbitrarily overwritten by environment variables and user input ... that doesn't have a text string data type, despite being expected to output text by default ... whose faux text string type is counted and NUL-terminated at the same time, inspiring the misguided belief that they can be safely passed by pointer to external libraries written in C. Never mind the embedded NULs, what about encoding issues? ... where the 0 string counts as false ... meant for web application development, but without any shape, form or sort of security model, outside of global policies. Even Netscape's server side Javascript had data tainting, god damn it ... that makes auditing impossible by allowing three or four different semantics for any dangerous operation (file I/O, process creation...), some of which overloads of generic functions ... without structured error handling ... without a library model PHP promotes piecemeal development of shoddy throw-away applications pretty much by design, and it does so proudly. No coincidence that it was mated to MySQL, of all databases. They're like the Britney Spears and K-Fed of web applications I mean, have you ever seen an ASP, ASP.NET or Java EE application mangle your single quotes and backslashes? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
why don't you guys agree to disagree and STUF? On 10/8/07, Geo. [EMAIL PROTECTED] wrote: - Original Message - From: Glynn Clements [EMAIL PROTECTED] URIs which it passes to an external handler (e.g. mailto:), it only needs to identify the scheme (to select the correct handler); it is the handler's responsibility to validate its own URIs (i.e. mail programs need to validate mailto: URIs). I don't agree. Whatever program takes input from an untrusted source, it's that programs duty to sanitize the input before passing it on to internal components. It's like a firewall, you filter before it gets inside the system. Example, an ftp server has to sanitize filenames to prevent useage of streams on NTFS, you don't blame the filesystem that the input gets passed to, it's the job of the ftp server to do the sanitizing of untrusted input. Geo. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
I think that you're both right, but the only solution is the same old, same old: speed, code size, and maintainability/complexity versus the padding and added IO checking of a very secure app. Nothing new, nothing different. It's the same problem that has existed since the dawn of programming. Invariably the answer to the question will be a proposal for yet another secure programming language or framework. So far all attempts at either have seemed to have failed miserably or never really gained traction (anyone else here remember plan 9 and its more secure brother inferno?). Now the industry trend du jour is moving more towards protecting the rest of the system from unforeseeable vulnerabilities and their exploitation (selinux, dep, etc) when things blow up rather than demand that code is 100% bulletproof. Bad idea? I'm not so sure. The bigger the system, invariably, the harder to debug to absolute stability in a timely fashion, but source code analysis tools can help lighten the load a bit. However, no amount of auditing of your own product can prevent the problem of a buggy third party that, even if you pass it input in the exact fashion as specified by the manufacture, is still vulnerable. The point of this rambling? No amount of hyperventalating over the security of your own code will ever make it absolutely secure as long as you're placing a reliance on the security of a 3rd party library (in which case I hope you're planning to write everything from the bios of the computer up to the app). Point? Mitigating the threat posed by unknown attack vectors is something that may start at the program level, but I'm highly doubtful that it can completely be accomplished at just the program level alone. A secure operating system or security framework will pretty much always be a necessity for guaranteeing a completely secure platform. If there's a silver lining here it's that even the most novice computer user knows that security is a problem with computers as opposed to security? What's that? (followed by a deer in the headlights look). That widespread knowledge is what drives budgets to spend on security oriented products rather than the old philosophy that those are optional products. Hopefully, that will eventually materialize in the form of better, cheaper source code auditing products that can help fix the problem at where it all starts: insecure code created by innocent oversight of the programmer who creates it through either it being abolutely complex, a rushed development cycle, or maybe just the infamous (that looks right). Geoff Sent from my BlackBerry wireless handheld. -Original Message- From: Geo. [EMAIL PROTECTED] Date: Sun, 7 Oct 2007 22:26:21 To:[EMAIL PROTECTED],full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype - Original Message - From: [EMAIL PROTECTED] 2) That said program can protect itself against overtly malicious input. Ok then, I can mark you down as one who believes that all the php exploits blamed on bad code writing are actually the fault of php and not the application coded using it's powerful functionality? Geo. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
Geo. ha scritto: I don't agree. Whatever program takes input from an untrusted source, it's that programs duty to sanitize the input before passing it on to internal components. It's like a firewall, you filter before it gets inside the system. NO! wrong! stop the input sanitization fallacy! Input is perfectly fine. Input goes into a parser, an abstract form comes out. You operate internally on the abstract form, which is (hopefully!) designed to avoid all the ambiguities of the text form you get from input. You take UTF-8 in? you'd better operate on its UTF-16 or UTF-32 equivalent then. You take XML? deserialize into the corresponding object from your data model. And so on. The interesting issue is handing out your abstract form to an outside component. Think about it. SQL injections? outputting to a database engine. XSS? outputting to a DOM engine. Path traversal? outputting to an I/O model's path parser. This is not something you can just shoehorn in your application at any later time. You need to know beforehand if you have any problematic external components, which e.g. won't take Unicode input, and devise strategies that don't cause loss of fidelty: store the password's SHA-1 in hex maybe? or pass the sort key (see http://blogs.msdn.com/michkap/archive/2007/09/24/5085893.aspx) in the invariant locale instead of the actual string, if the component only needs to be able to compare strings for equality/collation order. No excuses. Information is sacred and irreplaceable, and input filtering an unacceptable blasphemy. If you filter input, you haven't thought hard enough Example, an ftp server has to sanitize filenames to prevent useage of streams on NTFS, you don't blame the filesystem that the input gets passed to, it's the job of the ftp server to do the sanitizing of untrusted input. See what I mean? The server needs to deserialize the input (converting it from whatever implied charset into an internal representation), and then serialize it again into the native form of the target component it's outputting to (UTF-16 Unicode in NT path syntax, in this case). If the format is a delimited or otherwise marked-up string (as paths are), special characters must be quoted. If a character cannot be quoted (as the NTFS colon can't), you raise an error. The error bubbles up to the client. That's the way you do it. Not any other way. You are getting it right only by chance, you are messing up the hierarchy of components and their responsibilities. You are forcing the layer that is the furthest from the external component to deal with its subtleties ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
[Disclosure: I work for Microsoft. But this is my opinion, not Microsoft's] If I click on the test link in IE 7, by itself, it does not have the vulnerability. The applications in question are accepting abitrary input and not validating correctly. How is that a Microsoft or Windows problem? Don't get me wrong, I want to protect end-users as much as the next person (as does MS), but if it is the application not validating correctly, could there not be hundreds of potential characters and strings that cause input validation problems in particular circumstances, which will vary according to the application? If Microsoft scrubs out every potential malicious character, it's bound to break lots of legitimate applications. That would make plenty of users and developers mad. At what point should Microsoft scrub URIs so that it hands off only legitmate characters most of the time? How could Microsoft determine ahead of time what is and isn't legitimate characters to pass to applications they don't own? If they block characters that affect certain applications, it might cause problems in other applications that have no problem with the character(s) in question? What is the solution? The easy answer is to block the % character in this particular instance...but that's just a whack-a-mole fix. I'm asking, with genuine interest and a listening ear, what is the best long term solution you envision, to solve the larger problem? Roger * *Roger A. Grimes, InfoWorld, Security Columnist *CPA, CISSP, CISA, MCSE: Security (2000/2003), CEH, yada...yada... *email: [EMAIL PROTECTED] or [EMAIL PROTECTED] *Author of Windows Vista Security: Securing Vista Against Malicious Attacks (Wiley) *http://www.amazon.com/Windows-Vista-Security-Securing-Malicious/dp/0470101555 * -Original Message- From: Juergen Schmidt [mailto:[EMAIL PROTECTED] Sent: Friday, October 05, 2007 8:59 AM To: [EMAIL PROTECTED]; full-disclosure@lists.grok.org.uk Subject: URI handling woes in Acrobat Reader, Netscape, Miranda, Skype Hello, the URI handling problem on Windows XP systems with IE 7 installed hits a lot of applications, not only Firefox (and mIRC) -- namely Skype, Acrobat Reader, Miranda, Netscape. To recap: with the installation of IE 7 Microsoft changes the handling of URLs that are passed to the operating system on Windows XP. After this, URLs that contain an invalid % encoding can launch abitrary programms. One example is: mailto:test%../../../../windows/system32/calc.exe.cmd that launches the calculator when activated in affected applications. Firefox fixed this problem in 2.0.6. After being notified by heise Security, Skype fixed the problem in 3.5.0.239. Still vulnerable (as of 4th of October) are: Adobe Acrobat Reader 8.1: If a user clicks on such a link in a PDF, calc.exe is executed. Miranda v0.7: If a user klicks on this link in a chat window, calc.exe is executed Netscape 7.1: mailto is handled by Netscape itself, but similar telnet:-links start the calculator. This list can propably be extended with little effort. On a question to MSRC if Microsoft is planning to react on this, we recieved the following response: After its thorough investigation, Microsoft has revealed that this is not a vulnerability in a Microsoft product. For further information see: http://www.heise-security.co.uk/news/96982 bye, ju -- Juergen Schmidt editor-in-chief heise Security www.heisec.de Heise Zeitschriften Verlag,Helstorferstr. 7, D-30625 Hannover Tel. +49 511 5352 300 FAX +49 511 5352 417 EMail [EMAIL PROTECTED] GPG-Key: 0x38EA4970, 5D7B 476D 84D5 94FF E7C5 67BE F895 0A18 38EA 4970 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
Dear Roger, RAG The applications in question are accepting abitrary input and not validating correctly. Please define correctly in case of an Uri handler. I am not aware of special attack vectors or injections that I should be filtering in case of mailto: calls, are there any? If yes, where are they documented and where can I find them ? As a developer I have no control over what Windows does with this handler, I have to trust it. Are all Application developers now required to work around obvious bugs in the way Windows handles the mailto: handler ? What you call for is in essence - mitigation, yes it's fine to mitigate a vulnerability. But shouldn't we be concentrating on finding and fixing the root cause instead of trying to mitigate the problem in (hundrets) of third-party applications ? RAG How is that a Microsoft or Windows problem? How is that _not_ a Windows Problem ? RAG Don't get me wrong, I want to protect end-users as much as the RAG next person (as does MS), but if it is the application not RAG validating correctly, could there not be hundreds of potential RAG characters and strings that cause input validation problems in RAG particular circumstances, which will vary according to the application? We are speaking of the mailto: handler here that _seems_ to be broken POST IE7 installation. (Again IMHO) Could you explain me why POST Ie7: mailto:test%../../../../windows/system32/calc.exe.cmd Executes calc mailto:test%../../../../windows/system32/calc.exe.txt executes notepad trying to open calc mailto:test%../../../../windows/system32/calc.exe.doc Now the surprise : OFFICE (Winword) opens, SHELLS the mailto handler BUT replaces % with %25 and with %22 and surprise it does NOT execute calc but your mail client. Yes! Winword mitigated the problem/vulnerability. Try it, open Winword, add hyperlink with mailto:test%../../../../windows/system32/calc.exe.cmd click on it, and check process explorer to see the result winword replaced the % prior to shelling mailto. Now this is some serious voodoo. I think some persons were aware of the problem but couldn't get the responsible parties to fix it, becuase of arguments like yours. This is a assumption, not a fact. I have not been there and heard that... RAG If Microsoft scrubs out every potential malicious character, RAG it's bound to break lots of legitimate applications. What genuine application uses this [1] way to call a mailto: handler ? [1] mailto:test%../../../../windows/system32/calc.exe.cmd RAG At what point should Microsoft scrub URIs so that it hands off RAG only legitmate characters most of the time? How could RAG Microsoft determine ahead of time what is and isn't legitimate RAG characters to pass to applications they don't own? It's not that they should decide what and what to pass or not to pass on, the problem in the example Juergen sent is - what they pass INTERNALY not to third party applications. RAG If they block RAG characters that affect certain applications, it might cause RAG problems in other applications that have no problem with the character(s) in question? RAG What is the solution? The easy answer is to block the % RAG character in this particular instance...but that's just a whack-a-mole fix. The Solution might be : - Determine the root cause - Determine the attack vectors - Determine whether it's wise to fix it at the root or try to mitigate around it. RAG I'm asking, with genuine interest and a listening ear, what is RAG the best long term solution you envision, to solve the larger problem? Certainly it's not mitigating through hundrets of third party applications. -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
- Original Message - From: Thierry Zoller [EMAIL PROTECTED] What you call for is in essence - mitigation, yes it's fine to mitigate a vulnerability. But shouldn't we be concentrating on finding and fixing the root cause instead of trying to mitigate the problem in (hundrets) of third-party applications ? If the application is what exposes the URI handling routine to untrusted code from the internet, then it's the application's job to make sure that code is trusted before exposing system components to it's commands, no? In this case how is acrobat reader any different than telnetd? If telnetd exposes system functions to untrusted users (no password required) who is supposed to enforce security? In the case of acrobat reader, it's acrobat exposing the system to untrusted sources and it should be that application that is responsible for mitigation of attacks via those exposed interfaces. Geo. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
Dear Geo., G If the application is what exposes the URI handling routine to untrusted G code from the internet, Sorry, Untrusted code from the internet ? The user clicks on a mailto link, is that untrusted code? Or the mailto link is clicked for him. Anyways, the mailto link POST IE7 has a flaw/threat/vulnerablity it hasn't had PRE IE7. G then it's the application's job to make sure that G code is trusted before exposing system components to it's commands, no? Yes to a certain degree it is, like I said mitigation is fine, though it shouldn't be the final word here, _if_ my assumptions I derive from the things I know and just tested are correct. I might be wrong, but I dont' think so =) The problem here is the root cause, the root cause is that IE7 introduced a problem, you can call it vulnerability or Threat or whatever floats your boat, I don't care, my point is, in my opinion the handler itself is broken. -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
In my opinion, every application should handle incoming data as bad data. Its poor programming to assume that incoming data is properly formatted and safe to process as is, even if the data is supposed to come from a process you own. Why so extreme? Because the bad guys are going to figure out how to get bad data to your code using pathways you didn't consider. In other words, I agree with Geo that each of the applications should inspect the URI before processing it. The OS components that are involved should too, but the 3rd party apps should never assume that IE or whatever has done so. -- From: Thierry Zoller [EMAIL PROTECTED] Sent: Saturday, October 06, 2007 1:06 PM To: [EMAIL PROTECTED]; full-disclosure@lists.grok.org.uk Subject: Re[2]: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape,Miranda, Skype Dear Geo., G If the application is what exposes the URI handling routine to untrusted G code from the internet, Sorry, Untrusted code from the internet ? The user clicks on a mailto link, is that untrusted code? Or the mailto link is clicked for him. Anyways, the mailto link POST IE7 has a flaw/threat/vulnerablity it hasn't had PRE IE7. G then it's the application's job to make sure that G code is trusted before exposing system components to it's commands, no? Yes to a certain degree it is, like I said mitigation is fine, though it shouldn't be the final word here, _if_ my assumptions I derive from the things I know and just tested are correct. I might be wrong, but I dont' think so =) The problem here is the root cause, the root cause is that IE7 introduced a problem, you can call it vulnerability or Threat or whatever floats your boat, I don't care, my point is, in my opinion the handler itself is broken. -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
What I see as root cause, is not what IE7 has changed. Windows was always confused about quoting, may parse and re-parse a command an unspecified number of times. Compared to Unix, it confuses system(3) with execl(3). In the registry there are shell\open\command keys, set to 'prog %1'. It should be clear to Windows that there is a command with one argument; but it will normally mis-parse blanks within %1 and have many arguments. Some registry keys are set to 'prog %1' to protect against blanks, but those are vulnerable to embedded quotes. I only guess that things are generally unsafe against embedded % characters (though maybe not the URL protocol handlers we are specifically worried about here). A number of similar issues would be solved if Windows would respect the command with one argument setting, parsing the registry key just once. Cheers, Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
Paul Szabo ha scritto:
What I see as root cause, is not what IE7 has changed. Windows was
always confused about quoting, may parse and re-parse a command an
unspecified number of times. Compared to Unix, it confuses system(3)
with execl(3).
You cannot compare them, Windows doesn't have argc/argv, it passes
around a flat string command line. There is no confusion either, system
is ShellExecute and CreateProcess is exec - and programs are most likely
going to use ShellExecute to run external programs or URLs (ShellExecute
always invokes a single program - it's designed to launch documents - so
there is no shell metacharacter kind of vulnerability). That said,
another issue is that there is no standard algorithm to turn a Win32
command line into a C argc/argv. Visual C++'s libraries use this
(inferred from source code, not actually documented anywhere):
- a command line is a list of arguments alternating with whitespace
- each argument goes into an argv element
- the count of arguments goes in argc
- an argument is a list of tokens
- a token is either:
- a list of characters that aren't space, tab or double quote
- the contents of a quoted string. The syntax:
- a double quote begins a quoted string
- 2N backslashes + double quote = N backslashes + end of string
- 2N + 1 backslashes + double quote = N backslashes + double quote
- N backslashes + any other character = N backslashes + character
- any other character = the character
(an interesting consequence being: 'command argument' parses as {
command, argument })
Not all compiler writers are that careful, though. I know for a fact
that Borland libraries have no way to handle double quotes embedded in
arguments (or, at least, not last time I checked). Oh, and Visual C++
libraries cannot handle a double quote in argv[0], by design. Thought
you'd like to know
In this particular case, I have to reluctantly agree with Microsoft, due
to my output side bears the burden of validation doctrine. We have a
by-the-books command injection issue here, not unlike a SQL injection or
an XSS. ShellExecute is not called ExecuteUri: like you presumably
filter out dangerous or unknown schemas (... you do, right?), you should
perform normalization or validation before passing a command string to a
function that is designed and documented to invoke arbitrary programs in
arbitrary ways, *not* safely execute an URI (if you use OLE's internet
support, on the other hand, you get to enjoy the same scheme/zone
policies as Internet Explorer. And naturally, it's a pain to use. The
Internet Explorer team must have a collective liver mass the size of Texas)
A number of similar issues would be solved if Windows would respect the
command with one argument setting, parsing the registry key just once.
Strings are the root of all evil. Whenever you pass structured data
around in a string, you are passing around _communism_. *Especially* if
the string is in some human-readable form. Think about it (incidentally,
it is precisely the reason why Internet Explorer 7 - specifically, OLE's
internet support - started passing URLs around as IUri objects, rather
than strings. Er, so that they are parsed only once, not the communism
thing)
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
- Original Message - From: Thierry Zoller [EMAIL PROTECTED] The user clicks on a mailto link, is that untrusted code? Depends on where the link comes from. If it's a shortcut on the users desktop no it's not untrusted, if it's in a PDF file you received in your email then yes it's untrusted. Anyways, the mailto link POST IE7 has a flaw/threat/vulnerablity it hasn't had PRE IE7. The problem here is the root cause, the root cause is that IE7 Ok I'm game, so then show me this exploit without having Acrobat on your system. IE7 handles mailto links in untrusted web pages. Put the mailto link in an untrusted html page and make it work with IE7. Geo. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
