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
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...
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
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
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.
--
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 ?
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
-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
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 -
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,
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
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
... 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
]
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
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
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
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
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
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
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
- 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
- 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.
- 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
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
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
.
-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
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
[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?
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
- 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
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
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
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
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
- 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
35 matches
Mail list logo
