[Full-disclosure] Insecure call to CreateProcess()/CreateProcessAsUser()
atarasco at gmail.com
Sun May 21 18:08:39 BST 2006
"My point is however that
the explorer program itself does not do this properly, and that anyone using
explorer or "Internet explorer",
is vulnerable to attack from the web through at least telnet:// links."
Well you are assuming that the user already has a backdoor application named
c:\telnet.exe that also means write access to c:\. You must be Administrator
to have write permissions to C:\ so i don't see the risk
I can see only one real attack scenario, unprivileged access to a Windows
with FAT file system or incorrect acls that allows you to store
c:\telnet.exe file. Anyway under that scenario , you should be able to
trigger better attacks ;-)
I agree with you that the the problem is due to bad coded applications but
that's not a Windows API flaw.
2006/5/21, Charles Morris <cmorris at cs.odu.edu>:
> I understand that this issue is known, however different applications run
> CreateProcess in different ways,
> some use the lpApplicationName variable and some use lpCommandLine
> properly. My point is however that
> the explorer program itself does not do this properly, and that anyone
> using explorer or "Internet explorer",
> is vulnerable to attack from the web through at least telnet:// links.
> (at least proven with Hyperterminal as coincidently
> C:\WINNT\SYSTEM32\telnet.exe has no spaces)
> Other telnet clients installed to different directories (with spaces) will
> also trigger the problem.
> It seems to me that I (speaking from a web programmers point of view)
> should not be able to ask your computer
> to run executables at (what seems to me, at least) arbitrary paths.
> This is also a major problem in multiuser environments, as you can trick
> some windows services into running your applications.
> I have been notifying vendors one by one of their problem, if it is in
> their code,
> as it seems that nobody wants to really talk about the huge implications
> of this;
> maybe I am exaggerating the problem. what do you think?
> On 5/21/06, Andres Tarasco <atarasco at gmail.com> wrote:
> > That's a well known issue and is documented at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp
> > Andres tarasco
> > 2006/5/21, Charles Morris <cmorris at cs.odu.edu >:
> > >
> > > Microsoft Explorer (iexplore.exe) calls CreateProcess() with
> > lpApplicationName = NULL. Instead, the lpCommandLine variable is used.
> > Unfortunateally, if the lpCommandLine variable is not quoted properly,
> > the
> > function will attempt to load&execute multiple other applications in
> > the following fashion:
> > lpCommandLine = C:\Program Files\Google\Google Talk\googletalk.exe
> > Will attempt to execute:
> > C:\Program.exe
> > C:\Program Files\Google\Google.exe
> > C:\Program Files\Google\Google Talk\googletalk.exe
> > If Microsoft Hyperterminal is set up to be your default telnet client,
> > this behavior is known to be triggered from the web with a telnet://
> > style link.
> > Microsoft was notified, they told me it was a "non issue", that they
> > coulden't reproduce it, and basically "dont worry about it". or
> > something. Unfortunateally although explorer.exe warns a user when the
> > file "C:\Program.exe" exists, it does not check any other paths,
> > therefore it is not nearly a sufficient workaround.
> > --
> > Charles Morris
> > cmorris at cs.odu.edu
> > Network Administrator
> > CS Systems Group Old Dominion University
> > http://15037760514/~cmorris <http://15037760514/%7Ecmorris>
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> > Hosted and sponsored by Secunia - http://secunia.com/
> > --
> > Loco de aTar
> Charles Morris
> cmorris at cs.odu.edu
> Network Administrator
> CS Systems Group Old Dominion University
> http://15037760514/~cmorris <http://15037760514/%7Ecmorris>
Loco de aTar
-------------- next part --------------
An HTML attachment was scrubbed...
Full-Disclosure is hosted and sponsored by Secunia.