full-disclosure - shell:windows command question

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

From: keith at mccanless.us (Keith )
Subject: shell:windows command question

I am the one that reported
http://bugzilla.mozilla.org/show_bug.cgi?id=167475.  Since, I saw the debug
team marked the report public, I will comment on it.  I agree with Andreas
that it is a very serious security flaw.  When I was playing around with it
I found some of the suffixes it responded to are 

mov

grp

its

mp3

txt

ppt

doc

xls

xsl

avi

psd

ai

js attempts to run with wscript

vbs attempts to run with wscript

reg

zip

sql opens in notepad.exe

mdb

shs (scrap)

chm

config opens in visual studio

aspx opens in visual studio

dbs opens in visual studio

eml

The most obviously dangerous extensions being .vbs, .js, .reg.  I am sure
there are many more.    This is dangerous as any program called by the
command runs with local zone privileges.  So until the patch is applied any
script or program can be called from the address bar by shell:pathtofile.
Also, Andreas is right about the potential of a buffer overflow.  Along with
the .mp3 and .grp extensions he mentioned, .eml files also seem to be
susceptible to this.  Hopefully the patch will be available soon and it will
stop more then just the extensions named in previous posts. 

As a side note, I was very impressed with the Mozilla team's response.  They
were very fast and Bugzilla keeps the reporter in the loop.  On the other
hand, when I reported a similar use of the shell command to MS and explained
how it could be used to escalated privileges their replay was "Thank you for
your note. While a remote server can get local data to display in the client
browser window by using these protocol handlers, it is not able to read the
data itself."  As we have seen, Jelmer and http-equiv have shown that this
certainly is the case.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040708/7473a46f/attachment.html