Work-around for Mozilla
|
| Author | Content |
|---|---|
| Corriher Sep 21, 2005 5:40 AM EDT |
I found this work-around for mozilla: You can disable the IDN support by opening the "about:config" page in the browser and manually toggling the "network.IDN" property to "false". |
| TxtEdMacs Sep 21, 2005 7:00 AM EDT |
Quoting: ...disable the IDN support by opening the "about:config" page in the browser and manually toggling the "network.IDN" property to "false". Did that last week or I think even the weekend prior to that. Are you sure this is the fix for the latest flaw? The current problem I think differs in allowing an exploit in the supposed url to contain code within that executes within the command line. (They sound very similar, is this just another duplicate or do they really differ?) |
| TxtEdMacs Sep 21, 2005 7:13 AM EDT |
Starting from the latest report: http://www.mozillazine.org/talkback.html?article=7388 I found the earlier citation of the flaw in the IDN, which uses the fix you noted http://www.mozillazine.org/talkback.html?article=7307 . Do the fix, if you have not already closed that problem. However, be prepared to take further action to close this new hole, perhaps by using the code changes in the testing version 1.0.7. This just is not a good option for me, I am running the beta of what is to be the 1.5 version of Firefox. |
| Corriher Sep 21, 2005 8:36 AM EDT |
You know... to be honest with you, I didn't know about this problem(s) until today, and all the time I have spent online today has been consumed trying to get the news out: since rapid alerts are critical concerning exposure. I'm so exhausted today that helping piece it all together as to what happened, when it happened, and exactly why; that offering advice concerning the multiple security issues may be beyond my intellect today. Honestly, until I am better rested and have taken the time to carefully review the information, I really do not trust myself to offer advice on something so important as this. However... here's my general impressions.... I have discovered this from my browsing of other discussions: The hyphen / script issue which effects malformed URLs apparently should not be a serious risk provided that you don't run the browser as root -- if you do, then you should get beaten with a rubber hose. Just in case something like this does strike from a user application, it is important to remember good proceedures... such as routinely creating back-up archives which are accessible only to root. The so-called Korean "virus" should not spread from the browser if the system's executables (ie.. /bin, /sbin ... etc.) are not writable for regular users, and again, you don't run the browser as root. If you made your /bin files writable to users; then you should get beaten by rubber hoses AND and your own keyboard. Again, I felt quickness was in order for even these non-critical issues, because a clever attacker may discover a method to exploit a weakness in a manner not yet known to the rest of us. For instance, if he could make code execute as the user, then he might manage to produce a script (ie. "echo 'blah blah' >> $HaX0R.sh") which executes something like "nc" ("netcat") to give himself the equivalent of a remote shell account, so he can begin the process of "upgrading" from a user account. So, while I would not worry terribly from what I have read so far, it is nevertheless wise to be paranoid where computer security is concerned. |
| Corriher Sep 21, 2005 8:49 AM EDT |
If you are worried, you can further sandbox your browser by. 1. xhost +127.0.0.1 (in .xinitrc or in x-terminal) 2. Run browser as a new user called "dummy" Of course, then a misbehaving application might... if designed to... screw with the running X-Window system -- but a quick CTRL+ALT+BACKSPACE solves that unlikely problem. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!