Thor Larholm ha scritto nel messaggio: > From: Drew Copley > > In fact, I don't think there has been a bug in about ten > > months (coincidentally) that does not rely on either Jelmer's > > adodb bug or your shell.application bug. > I'm sorry, but did everybody suddenly forget about codeBase command > execution? Use a non-existent GUID for your OBJECT's classid and point > the codeBase attribute to the executable you want launched. The codebase has been out of use since May 2003 at which time I noted it had been patched: http://cert.uni- stuttgart.de/archive/ntbugtraq/2003/05/msg00005.html Up until yesterday it still did not work, however after Microsoft's series of patches it seems to be back with mixed results. > Well technically, you also posted about it in 200 and gave proper credit > to Dildog. Technically I found and used the concept in June of 2000 at which time everyone got it wrong. It was the runner window object a piece of code designed to do just that, which allowed for a file in the same directory to execute without having to point to it. http://www.securityfocus.com/archive/1/66678 The entire concept of little 'Zones' was so alien to everyone back then that CERT even missed the point until I explained and demo'd it to them: http://www.cert.org/advisories/CA-2000-14.html I don't recall seeing your name around back in those 'good old days'. > codeBase has been the basis of most IE exploits before we started using > AD+ODB or Sh+ell No it hasn't. While the executing of files already on the machine proved to be nothing more than 'parlor tricks' the real 'trick' was to introduce arbitrary code to run. That was achieved only by encoding the executable in base64 and extracting it using mthml and referencing to the embedded executable that way. This is note the same as the code base pointing to a 'compiled' arbitrary executable introduced onto the machine which is next to impossible except for some rare bypassing of the Temporary Internet File. All methods via MHTML or CHM files are closed as well. The introduction or the ability to 'run' adobd in the Local Zone itself is sufficient to use any other measure to then execute the file it has written. No need to use codebase [which in that 'era' didn't work anyway] to run it. Shell has never been used with any measure of success 'in the wild' owing to its limited [at the time] capabilities. Only very recently was it demonstrated to enjoy even more powerful capabilities by combining a number of different techniques: http://msgs.securepoint.com/cgi-bin/get/bugtraq0407/32.html But this is a complete waste of time. It has been patched, as has the adobd.stream. Both of which do not work on Windows 95 or Windows 98 as they are not installed. > The codeBase attribute allows command execution from the My Computer > zone and you can mitigate against it by either completely disabling > ActiveX in that zone or setting it to only allow administrator approved > ActiveX controls. You don't need to do either. It has been sufficiently patched all this time except by all indications as of yesterday with the introduction of the 'mega patch' series from Microsoft. In any event to introduce the executable you intend to run is next to impossible and only digitally signed files can bypass whatever warnings or prompts remain today [as noted above in May 2003] >The latter will solve the functionality regression > problem that e.g. MMC and Norton Antivirus will have since both of these > rely on executional privileges given by the My Computer zone. This is > also the approach we took in Qwik-Fix ( http://qwik- fix.net/ ). Regrettably I cannot find any validity to this. For all the reasons already stated. By the way despite 'hiding' the download url of your little 'gimmick' a quick Google shows where it can be downloaded. Having now 'played' with it for a number of weeks I could not in good faith recommend it to anyone. Unraveling its code reveals nothing more than a series of registry entries that are freely available from Microsoft directly plus all the so- called 'killbit' registry entries everyone else has been recommending from day one. With a difference of a 'little' on/off switch. The entire thing can be accomplished with a .vbs file or any other number of scriptings. That plus an elaborate [and in my opinion unnecessary 'updating' scheme. The 'scheme' itself comprises the whole gadget]. While it certainly does 'killbit' what everyone has been discussing and how to do it for what seems like ages now, I am unable to see any effect whatsoever in regards to the 'import win32api, win32con name = "Zones fix" ' -- it simply does not work on my stock, fully patched test machine XP home. The little 'log file' you provides confirms it is enabled, but it does absolutely nothing here. All scripting works in the Local Zone, Jelmers very last demo with the Java .tmp file my demo of Paul's favorites tricked worked until shell and its path [which can still be defeated] was patched yesterday: - Info: IeZoneFix: Unable to query registry value "{F6406E36- 812A-4501-8C0C-3A6CAEF6DB84}" - Info: IeZoneFix: Unable to query registry value "{FD0AE533- 61C2-11D2-B980-00805FCDA1A3}" - Info: IeZoneFix: Enabled. Furthermore I caught it autoupdating without permission the other day as well. Despite there being no little 'checkmark' in that 'feature'. However despite it not working as advertised [which in itself is quite dangerous creating a complete false sense of security to the truly 'naive' as it were], the fact that it overwrites or deletes access to the 'My Computer' setting in Internet Explorer [having manually applied it] is simply not acceptable. That is Trojan type behavior. It does not have permission to effectively 'monkey about' with the computer owners private / custom settings. Finally a generous free 'tip' would to not have the entire 'thing' install in a predictable location particularly as you have a series text based files in there that may very well be leveraged down the road [since operations in the My Computer zone still function]. > You can circumvent the initial restrictions on codebase through a series > of Refresh's. By all accounts the latest patches from Microsoft have an effect on codebase which appear to allow it to work as before without any need of anything else. Though thorough testing at this time is incomplete. > Microsoft could blacklist the Sh+ell.App+lication object and still be no > better off. They could fix codeBase and I am sure we would find new > vulnerabilities in IE. This is all dated now as it is all fixed. As one who is 'in the trenches' I must admit that I am impressed with this comprehensive patching to date. Certainly has killed of many many possibilities [yet some still remain]. But overall I would give them 3 Gold Stars. Internet Explorer and its associated or embedded applications are only getting 'tougher' to defeat. Without a doubt in the very near future [certainly before the end of this year] it along with the Operating System should be sufficiently 'locked down' that all need for third-party gadgetry will be unnecessary and a waste of time and money. > Any privileges that you could ever need in the My Computer zone > can safely be used from an HTML Application by embedding MSHTA instead > of IEXPLORE. That is the only thing that is correct. We all await XP SP 2 and will certainly put it through its paces. But you should understand that all of these 'fun and game' vulnerability findings in IE are nothing more than a moment in time. So short a time it would be considered an utter gamble to invest time and money in such a fleeting moment. -- http://www.malware.com
