From david.curran at gmail.com Thu Dec 8 08:49:45 2005 From: david.curran at gmail.com (David Curran) Date: Thu, 8 Dec 2005 13:49:45 +0000 Subject: mouse hole as a temporary patcher? Message-ID: <6ec73d4a0512080549q5aa6a664g@mail.gmail.com> Hello. Can mousehole prevent particular JavaScript from ever being loaded by the browser? On Windows the POC code given on http://packetstormsecurity.org/0512-exploits/firefox-1.5-buffer-overflow.txt will fill up your history.dat file making firefox unusable. Greasemonkey cannot be used to plug this hole because all JavaScript is loaded before it monkeys around with it. Is it possible to replace any document.title with length greater then say 200 using mousehole? Sorry if this question is idiotic, I just fell into mouse hole through a hole in greasemonkey. Regards David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mousehole-scripters/attachments/20051208/659ea241/attachment.htm From zimba.tm at gmail.com Thu Dec 8 09:01:40 2005 From: zimba.tm at gmail.com (zimba-tm) Date: Thu, 8 Dec 2005 15:01:40 +0100 Subject: mouse hole as a temporary patcher? In-Reply-To: <6ec73d4a0512080549q5aa6a664g@mail.gmail.com> References: <6ec73d4a0512080549q5aa6a664g@mail.gmail.com> Message-ID: <3ff63f9b0512080601n51e8cd5cq@mail.gmail.com> Hi David, mouseHole allows you to filter any incoming html data. So yes it's possible.But you'll have to make sure that every javascript expression fordocument.title is filtered. I guess making a simple check for document.title is good enough, butyour script won't work in other cases. By assigning document to a dvariable for example, or hiding the nasty javascript in abase64-encoded-string. At last, the more secure alternative is to allow javascript only onwebsites you know. On 08/12/05, David Curran wrote:> Hello.> Can mousehole prevent particular JavaScript from ever being loaded by the> browser?> On Windows the POC code given on> http://packetstormsecurity.org/0512-exploits/firefox-1.5-buffer-overflow.txt> will fill up your history.dat file making firefox unusable.> Greasemonkey cannot be used to plug this hole because all JavaScript is> loaded before it monkeys around with it.> Is it possible to replace any document.title with length greater then say> 200 using mousehole?> Sorry if this question is idiotic, I just fell into mouse hole through a> hole in greasemonkey.> Regards> David>>>>> _______________________________________________> Mousehole-scripters mailing list> Mousehole-scripters at rubyforge.org> http://rubyforge.org/mailman/listinfo/mousehole-scripters>>> --Cheers, zimba http://zimba.oree.ch From james at grayproductions.net Thu Dec 8 14:57:58 2005 From: james at grayproductions.net (James Edward Gray II) Date: Thu, 8 Dec 2005 13:57:58 -0600 Subject: Help -- I broke the hole! Message-ID: I've been doing some browser clean-up over here and one thing I wanted to do was restore hoodwink.d to working order. I haven't had it since the IP address change. I decided just to grab the latest MouseHole svn, figuring the new address would be in there. Now, when I try to visit any pages, I get errors: Internal Server Error getaddrinfo: No address associated with nodename WEBrick/1.3.1 (Ruby/1.8.2/2004-12-25) at www.edmondsun.com:80 I CAN visit the MouseHole doorway, MouseWiki, and MouseCommand, just not the web is general. Can someone through me a tip or two about where to start debugging this? Thanks. James Edward Gray II From mental at rydia.net Fri Dec 9 02:05:18 2005 From: mental at rydia.net (MenTaLguY) Date: Fri, 09 Dec 2005 02:05:18 -0500 Subject: Using an HTTP proxy to record web traffic In-Reply-To: <20051209043412.0532DB6DD@mx1.delmonte-phil.com> References: <20051209043412.0532DB6DD@mx1.delmonte-phil.com> Message-ID: <1134111918.30512.293.camel@localhost.localdomain> On Fri, 2005-12-09 at 13:34 +0900, Pe?a, Botp wrote: > why the lucky stiff [mailto:ruby-talk at whytheluckystiff.net] : > > #MouseHole is a scriptable proxy. > > i have problems chaining mousehole to a proxy; like this: > > client-->mousehole_proxy -->squid_proxy1-->squid_proxy2--->internet > > do i need to hack the mousehole code or is there a setting i obviously missed? tips pls. In theory it should just work, as any conforming HTTP proxy should be chainable. Could be a bug. Shall we take this to the mouseHole list? -mental -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://rubyforge.org/pipermail/mousehole-scripters/attachments/20051209/d20256cf/attachment.bin From why at hobix.com Tue Dec 13 02:15:43 2005 From: why at hobix.com (why the lucky stiff) Date: Tue, 13 Dec 2005 00:15:43 -0700 Subject: ! MouseHole 1.3 on its way -- let's talk about it Message-ID: <439E751F.8090806@hobix.com> Okay, I've just checked in the new user script code, which uses a little bit of mettyklass spongery to clean things up. Please try it out with yer user scripts and tell me if it breaks things bad. There is one incompatibility with the Writeboards user script which couldn't be helped and that's okay. It's minor. The hardest thing to get used to is that the scripts now act much more like class definitions since they are evaluated in the scope of a mediklasss. So, for example, if you're trying to do something like this in the definition: @link = "Click!" That won't work any more. You're going to want to set those up in `initialize'. = TODO!! = I really need help with a few items IF ANYONE CAN SPARE A MOMENT! There are basically two things I'd really like to wrap up and I am desperate for your unique talents and grace!! 1. The Net::HTTPIO class is slow and blame awful. It needs a recode. It's only ninety-eight lines long, so it's not too much work really. But I really need another approach. This is the lynchpin on MouseHole's success. If we speed this up and keep it from blockin threads, then we're basically fast. 2. I need some kind of a way for scripts to call each other. For example, what if the Hoodwink'd script could store little commands in MouseCommand?? That would be nifty and let's spoil me! Maybe we could expose methods to other scripts like: export :add_mouse_command do |cmd| end Anyway, yank from Subversion. I am on travels right now, so I'm not around much, but sometime tomorrow for sure. _why From mental at rydia.net Tue Dec 13 11:46:57 2005 From: mental at rydia.net (mental@rydia.net) Date: Tue, 13 Dec 2005 11:46:57 -0500 Subject: ! MouseHole 1.3 on its way -- let's talk about it In-Reply-To: <439E751F.8090806@hobix.com> References: <439E751F.8090806@hobix.com> Message-ID: <1134492417.439efb019c47a@www.rydia.net> Quoting why the lucky stiff : > 1. The Net::HTTPIO class is slow and blame awful. It needs a > recode. It's only ninety-eight lines long, so it's not too much > work really. But I really need another approach. This is the > lynchpin on MouseHole's success. If we speed this up and keep it > from blockin threads, then we're basically fast. Hmm, do you have an idea where the blocking is currently happening? Is it the IO#read/IO#readlines? I thought those were non-blocking with respect to Ruby threads, though... -mental From why at hobix.com Mon Dec 19 03:00:53 2005 From: why at hobix.com (why the lucky stiff) Date: Mon, 19 Dec 2005 03:00:53 -0500 Subject: ! MouseHole 1.3 on its way -- let's talk about it In-Reply-To: <1134492417.439efb019c47a@www.rydia.net> References: <439E751F.8090806@hobix.com> <1134492417.439efb019c47a@www.rydia.net> Message-ID: <20051219080053.GA46198@hobix.com> mental at rydia.net (mental at rydia.net) wrote: > Hmm, do you have an idea where the blocking is currently happening? > Is it the IO#read/IO#readlines? I thought those were non-blocking > with respect to Ruby threads, though... Well, now I am positive that Net::HTTPIO isn't the problem, since I rewrote it from scratch using NaHi's http-access2 library. To no avail. It was slightly slower and suffered the same problem. In addition, reverting back to Net::HTTP was overall worse as well. Mmnnn, if only some kind soul would donate a new WEBrick that's got the innards of lighttpd, coded as a cross-platform extension. _why From mental at rydia.net Mon Dec 19 11:57:12 2005 From: mental at rydia.net (mental@rydia.net) Date: Mon, 19 Dec 2005 11:57:12 -0500 Subject: ! MouseHole 1.3 on its way -- let's talk about it In-Reply-To: <20051219080053.GA46198@hobix.com> References: <439E751F.8090806@hobix.com> <1134492417.439efb019c47a@www.rydia.net> <20051219080053.GA46198@hobix.com> Message-ID: <1135011432.43a6e668480d1@www.rydia.net> Quoting why the lucky stiff : > Well, now I am positive that Net::HTTPIO isn't the problem, since > I rewrote it from scratch using NaHi's http-access2 library. To > no avail. It was slightly slower and suffered the same problem. > > In addition, reverting back to Net::HTTP was overall worse as > well. I'm pretty sure this is mostly a thing with Ruby IO, and the recent discussions on ruby-talk are underscoring this feeling for me. It would be nice to have event-driven IO facility in Ruby like is available in TCL or glib. I've written some pretty decent proxies/servers (tho I never tried this sort of HTTP hackery) using those, and it tends to work out a lot better performance-wise than a bunch of blocking threads. -mental From rcoder at gmail.com Mon Dec 19 12:20:07 2005 From: rcoder at gmail.com (Lennon Day-Reynolds) Date: Mon, 19 Dec 2005 09:20:07 -0800 Subject: ! MouseHole 1.3 on its way -- let's talk about it In-Reply-To: <1135011432.43a6e668480d1@www.rydia.net> References: <439E751F.8090806@hobix.com> <1134492417.439efb019c47a@www.rydia.net> <20051219080053.GA46198@hobix.com> <1135011432.43a6e668480d1@www.rydia.net> Message-ID: <5d4c61240512190920ld148957p8a5dec49bf555bc@mail.gmail.com> On 12/19/05, mental at rydia.net wrote: > I'm pretty sure this is mostly a thing with Ruby IO, and the recent > discussions on ruby-talk are underscoring this feeling for me. > > It would be nice to have event-driven IO facility in Ruby like is > available in TCL or glib. I've written some pretty decent > proxies/servers (tho I never tried this sort of HTTP hackery) using > those, and it tends to work out a lot better performance-wise than a > bunch of blocking threads. It's not exactly a high-level event-driven architecture, but we do have Kernel#select, which makes the same sort of non-blocking, callback-driven event model possible. The Medusa library adopted by the Python/Zope folks might not be a bad place to start for a simple example of using the select() call as a sort of "event kernel". There's also Twisted, and on the Perl side, POE, to mine for design ideas. I also recall some discussion on ruby-talk of someone trying to write a Ruby extension to wrap libevent, but IIRC, the Ruby threading model blocked (pun indended) the whole deal. -- Lennon rcoder.net From why at hobix.com Tue Dec 20 02:22:19 2005 From: why at hobix.com (why the lucky stiff) Date: Tue, 20 Dec 2005 00:22:19 -0700 Subject: ! Hoodwink.d 1.7 Message-ID: <43A7B12B.5060308@hobix.com> Okay, the latest Hoodwink.d script is available for MouseHole. You'll need the latest MH from CVS. I also added some in-memory caching based on Dan's code he posted earlier this month. Much better! Thanks to this Dan legend. _why From why at hobix.com Tue Dec 20 16:11:42 2005 From: why at hobix.com (why the lucky stiff) Date: Tue, 20 Dec 2005 14:11:42 -0700 Subject: MH hoodwink'd fixes Message-ID: <43A8738E.2050604@hobix.com> I know there have been quite a few messages in here about problems with hoodwink'd and problems getting lighttpd working. Some fixes from last night help fix 'getaddrinfo: unknown host' DNS errors and 'if-none-match' header not found errors. _why