New exploit code generating a remarkable large History.dat file when visiting with FF1.5 was published recently:
http://packetstormsecurity.org/0512-exploits/firefox-1.5-buffer-overflow.txt

When saving these code to a sample file and tested with KM it is affected without updated GREs. However, report says this is "done" for the newest Firefox 1.5 version.

It seems that generating a 'large topics' to History.dat (i.e. History.txt in KM) crashes the browser. FF's History.dat changed from tens of kilobytes to nine megabytes!

Juba,

Do you have an URL we can surf to to see if KM 0.9, updated to GRE 1.7.12, is vulnerable or not?

Tks,

N

I'm not even sure I'd WANT to test this... :-(.

Brian

This can happen only with javascript enabled.
Use the new NoScript Extension to only allow javascript
for trusted sites. It is safer anyhow.
Fred

Juha-Matti - thx for info.
Fred - did You try with You 6 version?

When I try to do that with a locally stored file containing
the script, the browser crashes and is terminated.
History text is not changed, and the browser restarts
without a problem. As far as the possibility should exist,
to let the buffer overflow make enter bad script into the system,
I have no idea, but such things demand usually high
capabilities by the attacker.
Firefox 1.0.7 might show the same reaction, plus
the growing history file (there history.dat), as
Juha-Matti has reported.

Fred

Do you have an URL we can surf to to see if KM 0.9, updated to GRE 1.7.12, is vulnerable or not?

Yes, I have:

(clicking the 'CLICK ME' is needed). Please try to open your profile folder in Details View first and check the size of History file. This is interesting for FF as well.)

http://www.findhard.com/firefox-1.5-buffer-overflow.html

It will be as with my local file : The browser crashes, but
history.txt remains empty.
Fred

A work-around for the bug has already been found :
Close the browser and add either to prefs.js or to user.js
in your profile folder the line :

user_pref("capability.policy.default.HTMLDocument.title.set","noAccess");

The page will stop for some seconds and than get back
to normal.

Fred

Juha,

Yes and yes. I created the html file and it crashed and I surfed to the URL and it crashed again. I gather that this bug is also in Mozilla 1.7.12 and FireFox 1.0.7. So, if there is a fix, it probably has to come from the GRE, no?

<sigh>

N

it is possibly in chrome or settings? - a Netscape 7.2 for that i made GRE update for
my daughter does not seem to crash = either setting or chrome.
Or some freak luck?

I was never much worried about the exploits (they did not work or were sudden death)
but this time k-m is slowly dying (that is political incorrect & gives time to attak).

The size of the files does not seem to increase unnaturally // with none i tried.

Since i test versions for SeaMonkey: i had a 94 kb history dat with a test browser from "normal" surfing the other week. That made the beast difficult to start.

Yes, Firefox and Suite were the first browsers reported. An instruction to change Visited pages history to 0 days doesn't prevent the generating a large history.dat. That 'user_pref' setting listed by Fred works.

I confirm, with Noscript, no problem.

I haven't tried with noscript allowing all sites.

@alain
- thx for You and the others working on blocking devices. I was not very intersted because i do not use such things - it seemed to be totally sufficiant to use our petite, obsure and secure k-m - but if they keep finding things i have to become
a daily user of additional security features.

@Juha-Matti
- though we are sometimes not effected by design - & less often then other Mozillas & Mozilla generally less often the IE this is far too often lately.

It did not matter whether it was versions with dat or txt. they all crashed but did not
greatly increase size of file.

The anoying thing about this new bug: it can be used by ppl for a laugh and many users would not get their browser going again because the problem is hidden in those hidden Profiles folders (i never liked the hidden profiles folder of other Mozilla - with k-m it is all more open for average user).

But still... even without hidden profile folders, most users aren't going to realize what happened. They'll just give up and uninstall, then reinstall (maybe) and hope it works.

Brian

It is already fixed in the new 0.9.5 - RC1 by
user_pref("capability.policy.default.HTMLDocument.title.set","noAccess");
in prefs.js .
Fred

Thanks Fred!!

Hmm... I wonder if I may have unknowingly been hit by that thing a while back. KM has been crashing occaisionally lately, and when I checked my history.dat file, it was 6+megs.
On the other hand, I set my history to virtually never expire (999 days). I wonder if my normal browsing for the past 4 months or so was enough to build up that large of a history file?

Fred,

About this history file bug and the fix:

user_pref("capability.policy.default.HTMLDocument.title.set","noAccess");

Can you tell me what this does?

Tks,

N

It appears that this bug causes some sort of buffer overflow by using javascript to change the title of the page to something enormous (it looks to be some sort of infinite loop, so that the title of the page becomes "0000000000000000..." ...on into infinity until the browser crashes). The user pref mentioned prevents javascript from changing the title of a page.

Drahken,

Thanks for the explanation. I did enable the new pref string and now when I test this using the URL from above, nothing happens...which is good...no more crashes!

<g>

N

It has been reported, that problems have appeared
using Google maps and GMail.
It seems, that the bugfix with the user_pref
user_pref("capability.policy.default.HTMLDocument.title.set","noAccess");
is to blame. The pref is unfortunately only in
prefs.js and does not appear in about:config, although
it could probably be changed there by adding it as
a new string with "allAccess".
Otherwise it would have to be changed after closing
the browser in prefs.js by hatching it out (#), and unhatched
again after using Google maps or G-Mail.
For those who can add a macro I have made one, which
can be found at the bottom of the KM0.9.5-RC1 thread at :

http://kmeleonbrowser.org/forum/read.php?f=1&i=33459&t=33459

But first make a copy of your Profiles folder, in case something should fail.

Fred

The crash is due to a stack overflow when kmeleon is trying to convert the title from unicode to the local charset. And it's not the only one. Setting a very long status bar text would do the same thing.

Well, is there, instead of some way of keeping it from changing the title, a way to make it simply limit the number of characters?

Brian