Michal Zalewski wrote:
> I can't really comment on whether
> this fixes the problem once and for all, because I haven't really examined
> the changes implemented for 364692, but yeah, my example no longer crashes
> the browser for me.
I think there are still underlying problems in the code as th
Resent as I realised I'm not subscribed here
Michal Zalewski wrote:
> I can't really comment on whether
> this fixes the problem once and for all, because I haven't really examined
> the changes implemented for 364692, but yeah, my example no longer crashes
> the browser for me.
I think there are
On Tue, 27 Feb 2007, Richard Moore wrote:
>
>
> http://slashdot.org/";>http://slashdot.org/
>
>
Yeah, and the other way round: http://lcamtuf.coredump.cx/ietrap/, when
used with FF 2.0.0.2, puts you on a page that:
1) Has URL bar data and favicon from the target site,
2) Views source of
On Sun, 25 Feb 2007, Stan Bubrouski wrote:
>>> http://lcamtuf.coredump.cx/ietrap/testme.html
>> This bug was fixed in 2.0.0.2, released Friday Feb 23.
> No it most certainly wasn't, do your homework next time.
Actually, the story is kinda funny, but yeah, it seems that it's fixed
now.
The stor
--On February 25, 2007 8:44:45 PM +0200 Ismail Dönmez
<[EMAIL PROTECTED]> wrote:
On Sunday 25 February 2007 20:27:19 Stan Bubrouski wrote:
The test on that page still puts my 2.0.0.2 in a completely unusable
state, try it yourself and let me know what happens.
Doesn't crash here on Linux, I
I can't say the same it shoots my CPU up to 100% and is completely
unresponsive on win2k sp4.
On 2/25/07, Ismail Dönmez <[EMAIL PROTECTED]> wrote:
> On Sunday 25 February 2007 20:27:19 Stan Bubrouski wrote:
> > The test on that page still puts my 2.0.0.2 in a completely unusable
> > state, try it
On Sunday 25 February 2007 20:47:22 Stan Bubrouski wrote:
> I can't say the same it shoots my CPU up to 100% and is completely
> unresponsive on win2k sp4.
If it doesn't crash the original vulnerability no longer exists, there are
many sites on the web that will freeze your Firefox and chew up al
On Sunday 25 February 2007 20:27:19 Stan Bubrouski wrote:
> The test on that page still puts my 2.0.0.2 in a completely unusable
> state, try it yourself and let me know what happens.
Doesn't crash here on Linux, I just see http://slashdot.org in URL bar and
empty page below, so I can confirm 2.0
The test on that page still puts my 2.0.0.2 in a completely unusable
state, try it yourself and let me know what happens.
-sb
On 2/25/07, Ismail Dönmez <[EMAIL PROTECTED]> wrote:
> On Sunday 25 February 2007 18:57:47 Stan Bubrouski wrote:
> > On 2/25/07, Daniel Veditz <[EMAIL PROTECTED]> wrote:
>
On Sunday 25 February 2007 18:57:47 Stan Bubrouski wrote:
> On 2/25/07, Daniel Veditz <[EMAIL PROTECTED]> wrote:
> > Michal Zalewski wrote:
> > > A quick test case that crashes while trying to follow partly
> > > user-dependent corrupted pointers near valid memory regions (can be
> > > forced to wr
On 2/25/07, Daniel Veditz <[EMAIL PROTECTED]> wrote:
> Michal Zalewski wrote:
> > A quick test case that crashes while trying to follow partly
> > user-dependent corrupted pointers near valid memory regions (can be forced
> > to write, too):
> >
> > http://lcamtuf.coredump.cx/ietrap/testme.html
>
Michal Zalewski wrote:
> A quick test case that crashes while trying to follow partly
> user-dependent corrupted pointers near valid memory regions (can be forced
> to write, too):
>
> http://lcamtuf.coredump.cx/ietrap/testme.html
>
> Firefox problem is being tracked here:
> https://bugzilla.
While researching my previous report on MSIE7 browser entrapment, I
noticed that Firefox is susceptible to a pretty nasty, and apparently
easily exploitable memory corruption vulnerability. When a location
transition occurs and the structure of a document is modified from within
onUnload event hand
13 matches
Mail list logo
