http://www.info-svc.com/news/11-21-2006/

This vulnerability affects K-meleon 1.02 as well as Firefox 2... I did the proof of concept test, and indeed, it sent the phony password to google.

I tried.

http://www. google.com/search?q=Chapin+Information+Services&loginuser=&loginpass=&x=427&y=517

and I had user name= ytll
and password = 1234567

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20060127 Netscape/8.1 that is = i use a German k-meleon1.02de-AT spoofing some older browser, to get my mail from Yahoo new Mail {they bar k-meleon as not supported :-()} during the same session. JavaScript activated which is normally off since
that makes faster and more secure browsing - Yahoo wants that JavaScript also.


Can You explain me, please, how I am supposed to do the proof of concept.
I understand that it worked with Your version / k-meleon1.02en-US i assume?

Another problem, we do not use FFox scripted password manager / it is c code.
Did You find out which module or dll is affected? It can only be that i guess.

thx for reporting Your find!

p. s. it is not nice - even if i did all right and does not work in all cases.



Edited 2 time(s). Last edit at 11/28/2006 01:39PM by guenter.

Even, I can't make the proof of concept either:

http://www.heise-security.co.uk/services/browsercheck/demos/moz/pass1.shtml
http://www.info-svc.com/news/11-21-2006/rcsr1/

I use Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060917 K-Meleon/1.02.

If you follow the link I cited, you will see a link to the bug in Mozilla.org's bugzilla, and some of the people there have reported that seamonkey did not reveal the password in the test case, and others said it did-- this seems to be what we are seeing in K-meleon. I definitely saw my test password and username in the URL in the test case. I will be happy to provide more info or do more tests if that will help.

Some people have suggested not using password manager, but apparently that will not totally solve it-- the same technique can be used to have the user enter their password manually (which they will be accustomed to doing if they do not use password manager) and have that data redirected to another site exactly as if the password manager did it.

The test case apparently hides the password entry form and uses the entire movie as a submit button... but it would work just as well if the user saw the password dialog and entered the password manually, expecting to log into the actual site.

I read through the comments on bugzilla on mozilla.org, and I have to admit that what they are talking about goes beyond my limited knowledge of how browsing and HTTP works. I am not sure if the solution that Mozilla.org reaches eventually will directly apply to K-meleon or not either.

By the way, I just did the test case as described in the article and it worked... nothing different. It is not a mozilla specific thing; IE is also affected, although it is a little different, as IE associates the whole url with a password, while mozilla (and KM, I think) associate a password with the whole domain.

@Ascaris, nobody here doubts that You have seen it.

We have seen similar before. In the past somtimes only k-m with certain settings had problems. That is why i asked about procedure ( i do not speak English well :-(.

You can be sure that the solution that Mozilla.org reaches eventually will likely be directly applied to K-meleon ( why i asked about dll? - k-meleon sits on their dll
if the dll are the reason it is likely ). We thank for Your info.

Saving passwords in the password manager seems not to be
advisable at present.
Passwords should be entered manually at the concerned site.
If javascript is enabled the password could be sent even
without pressing a submit button.
The remaining risk, when entering a password manually is
the same as with all phishing sites: if the password form
is faked, an even manually entered password could be sent
somewhere automatically.
Phishing sites have to be avoided by all means.
Important addresses should at least called up by entering
the URL manually or from a controlled bookmark address,
not from a link.
Websites with frames can call up faked frames within the
page to find out passwords.

Fred

Fred,

Are they external apps to handle bookmarks that do it differently. I'm thinking of something like Cookie Monster which I use with KM?

Tks

N

As long as you have control over your bookmarks,
you certainly can click them to go to sites in a
safe way. I do not know exactly, what Cookie Monster
does, but I presume that it's ok too.

Fred

Fred,

What about an external password manager to avoid the problem Secunia wrote about?

Tks,

N

This would probably be better than an an internal one.

Fred

P.S. about the long name of browser versions :
You can rename a K-Meleon folder to something
short without problems before the first start
and the creation of the profile.

That has been the way that I have been handling this. I use my personal links to sensitive sites, not ones linked from untrusted sites. That is good practice even without this particular vulnerability, of course.

I do not see how an external manager would be any different if it is not implemented differently in terms of matching passwords to URLs. This is not really a bug; the password managers in FF, K-M, and IE are all working as intended... the phishers just discovered a way use built-in user friendliness to steal data.

If the external manager matched the password to an entire URL (not just the domain) AND to the URL where the data is being sent, then it seems like this vulnerability would be totally eliminated. Of course, that would also make password dialogs without saved passwords a lot more common, as some sites legitimately change parts of the URL (but not the domain) and/or redirect the user/pass data to other sites under their control.

I would like to see a password manager match on domains as it does now, but pop up a warning if either of these things (the complete url or the url where the data is being redirected) change from how they originally were when the password was first saved, and give the user an option how to handle it (save that password permanently for the new domain/ target or decline to enter the password).

Something like that was suggested on mozilla.org's bugzilla, but some others disliked it as the average user will have no idea how to properly answer what to do, and will end up allowing it... but as another said, adding more security always makes things less user-friendly.

Perhaps such a solution would be more acceptable on K-M, which seems to be more of a browser for tech savvy individuals by virtue of the menu options and such (which I do not mind, by the way). And since the K-M password manager is different code than the FF manager, it seems to me that K-M's manager would have to be changed independently of whatever mozilla.org decides to do.

Fred,

Must have done something wrong, because I did rename it prior to a start and still had the LFN thing going on.

N

ndebord, done wwrong - just like me;-)
If specialists are discussing it & want to alter it, it is symtom of something general. At the momemnt there is some way to cross script to pippki.jar functions in FFox and to c code equivalent here - but it is still only demo and maybe not fail proof.

p. s. As far as i can understand: This vulnerability is existant but not of big use - it depends on the site owner giving his site to the exploit. It can be just done on site - even without the exploit - if the site owner wants.

Guenter,

Well, I worry about the password thing because if it is present on a website that I surf, it is impossible to tell if it is safe or hacked. What I'm not sure about is if the website can be hacked without the site owner's knowledge and thereby little old unsuspecting me wanders in and gets taken like a tourist in the big city by an experienced pickpocket!

<shrug>

N

Guess: We have to apply the same security messures as in real live.
Do not go to bank and then to certain areas downtown at the same ride.
<shrug 2> & <my 2 cents>

IMHO Unlikely to be hacked without the site owners knowledge, normally.
Possible theoretically but unlikely. The tourist industry in a big city will try to protect visitors against theves, muderers, ouright crooks, ... and does not recommend to go to back allies without proper protection. They depend on the visitors and their opinion for their income.

Professional sites are administered by ppl that do it as a job. It would be like You or me making a fault during work if permitt their site being highjacked and used for such things. We make mistakes at work but not intentionally nor often.

The only thing that seems possible. When they have a commercial link in a frame e. g. from a partner program and they have a crook for partner without knowing.

So it is unlikely on places that do not use frames or inframes object linked outside. Typcical place not linked to outside is e. g.: Our Forum or our Bank.
The are like an all inclusive hotel at the beach ;-)

In Theoroy places that outsource somehow: e. g. have ouside advertisements or content that are frames or inframes & can have external object with bad intentions without the site owner knowing. The are not like an all inclusive hotel at the beach ;-)

That is what i think because i know to construct websides
( if they are simple like my home page with Lake Applets ).

In Praxis ppl supplying foul objects via partner programs would be out of business soon. Web masters normally collect info before they make new partnerships, they will quit old partners starting to do that because it is against their own interests ... It just like in real live: Hotel manager calls police when guests are robed or does not recommend or work together with bargain neighbor restaurant when his guests were fleeced there.

Guenter,

You sure know a lot more than I do about webpage design. As for the password problem, I will just be vigilant and hope that is enough.

N

Guenter,

<<ndebord, done wwrong - just like me;-) >>

Hmmm. When I install this version of KM, it accepts my new name for the top folder,k but underneath it installs a subfolder with a very long filename of Fred's choice. If it were 8.3 naming convention, it would be easier to use.

N

Why bother to keep Fred's naming? Alter the folder name.

p.s. or folder structure also if it is totally in a subfolder - do not forget to delete the profiles folder (like i normally do) if You keep the profiles inside k-m folder, but i am certain that You knew :-).

Guenter,

Deleting the profile folder has caused me problems from time to time, usually related to small changes in pref files and similar. My solution has been to hex edit the registry.dat info so that I can more easily transfer info from one KM install to another. I use MY own 8 letter combo for the SLT and then just edit USER and PREF to reflect the change. When you have a 16 letter/number combo subfolder location, hex editing is a lot, lot harder. Deleting compreg and xpti is second nature to me at this point!

<wry grin>

N

@ ndebord

The subfolders inside the K-Meleon folder have the same
names as ever, there should be no longer ones.
This version creates by default a profiles folder
inside the K-Meleon main directory. If you want the profile
in the C:/Documents... folder, you would have to rename
profile.ini in the K-Meleon main folder to another name,
may be profile.ini-renamed.

Fred

Fred,

<<The subfolders inside the K-Meleon folder have the same
names as ever, there should be no longer ones.>>

When I installed this version using WinZip, I chose an 8.3 name, "KM-Linux." This is the tree structure that the install program created:

C:\Program Files\KM-Linux\K-Meleon-Linux-usable-1.8.1\

N



Edited 1 time(s). Last edit at 12/03/2006 06:00PM by ndebord.

You should simply unzip the .zip file without changing
the name at the beginning. You can do that with WinZip
or even the Windows native unzipper. When you get a folder
K-Meleon-Linux-usable-1.8.1, you have then got the real
K-Meleon main folder. Move it everywhere that you want, for
example to C:/programs/ as C:/programs/K-Meleon-Linux-usable-1.8.1
and rename this folder then to KM-Linux, this is the main
folder, namely C:/programs/KM-Linux, and its subfolders
should have the usual names then. WinZip will not change
the name of the K-Meleon folder, but asks for a place
to unzip it. If you give in "KM-Linux", it will create this
folder additionally as a higher folder, to unzip the
.zip file there.

Fred

Fred,

Would it not be simpler to use an 8.3 naming convention instead. This sounds like a really involved process when it should be much easier, as it used to be.

Having to move sub-folders, rename folders, etc., is not an intuitive method for installing software imo.

N

You are absolutely right, as long as it concerns
official versions. They should always have short names.
For unofficial versions, that have a special purpose,
I think it is necessary, to make this purpose, which
makes them different from official ones, easily
recognizable, because the normal user is mostly
better served by the official versions, except,
if he needs a special feature. This may be Active X Support
or features, that were present in older versions,
the capability, to be used from a CD, without
writing a profile somewhere, or, as in this case,
a simpler structure, suitable for use in Linux.
These versions, with a special purpose, must be
easily distinguishable from each other, to
facilitate the choice for people, who need exactly
this version with this special property.

Fred

Fred,

Now that I undersand the TRICK in how to move folders BEFORE running the browser, it is easy to do what is required to change the location of the browser files. I can't say I like the process, but I understand your reluctance to change how you do things with these special, experimental versions.

N