Big Day For Browser Vulnerabilities
An anonymous reader writes "All browsers have been reported vulnerable to different vulnerabilities today. Starting with: Internet Explorer on XP SP1/SP2, which suffers a new system compromise (of course) vulnerability. Continuing with: Opera, Mozilla / Mozilla Firefox / Camino, Safari, Netscape, Konqueror, Avant Browser and Maxthon, which all suffers some new spoofing vulnerabilitities. Demonstrations of the spoofing vulnerabilities are available here and here."
it's just that IE is so tied to the OS that when it goes down so does the whole 'puter
-Nb
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
The advisories list the IE problems as much highly critical, whereas the others are only medium critical.
As I understand it, problem with IE vulns are that its SO tied to the OS, that even the most trivial of problems can cause much greater problems.
Join the Free Software Foundation
I just tried the exploit demonstration for Safari, but it did not work. The active tab switched back to the one providing the pop-up, not the target site. Did anyone else try it and have it work?
For Windows Firefox users: Tools -> Options... -> Advanced icon (left side) -> Software update section -> Check Now button
Speak truth to power.
Using Safari 1.2, the tab where the JavaScript dialog is coming from is activated when the dialog shows up. Nothing unsecure there. I can _see_ that this is not a CitiBank pop-up.
Anybody care to explain to me?
--
kTag
For Apple's Safari browser
g _box_sp oofing_test/
Description:
Secunia Research has discovered a vulnerability in Safari, which can be exploited by malicious web sites to spoof dialog boxes.
Inactive windows can launch dialog boxes so they appear to be displayed by a web site in another window. This can be exploited by a malicious web site to show a dialog box, which seems to originate from a trusted web site.
Successful exploitation would normally require that a user is tricked into opening a link from a malicious web site to a trusted web site in a new window.
A test is available here:
http://secunia.com/multiple_browsers_dialo
The vulnerability has been confirmed in Safari 1.2.3 (v125.9). Other versions may also be affected.
Solution:
Don't visit trusted web sites while visiting untrusted web sites or disable JavaScript.
And for IE
Description:
http-equiv has discovered two vulnerabilities in Internet Explorer, which can be exploited by malicious people to compromise a user's system, link to local resources, and bypass a security feature in Microsoft Windows XP SP2.
1) Insufficient validation of drag and drop events from the "Internet" zone to local resources for valid images or media files with embedded HTML code. This can be exploited by e.g. a malicious web site to plant arbitrary HTML documents on a user's system, which may allow execution of arbitrary script code in the "Local Computer" zone.
This vulnerability is related to:
SA12321
NOTE: Microsoft Windows XP SP2 does not allow Active Scripting in the "Local Computer" zone.
2) A security zone restriction error, where an embedded HTML Help control on e.g. a malicious web site references a specially crafted index (.hhk) file, can execute local HTML documents.
NOTE: This will also bypass the "Local Computer" zone lockdown security feature in SP2.
The two vulnerabilities in combination with an inappropriate behaviour where the ActiveX Data Object (ADO) model can write arbitrary files can be exploited to compromise a user's system. This has been confirmed on a fully patched system with Internet Explorer 6.0 and Microsoft Windows XP SP2.
Solution:
Disable Active Scripting or use another product.
Join the Free Software Foundation
Inactive windows can launch dialog boxes so they appear to be displayed by a web site in another window.
When I tried this in Safari 1.2.3, the browser switched back to the test page as it gave me the phony dialog box. The Citibank page was only visible for a second or two before Safari switched back to the exploit test page.
Doesn't seem to be a problem here... ?
Although they list Mozilla*.* vulnerabilities as not very serious, they must be acknowledged anyway. One is fairly trivial, I've seen it many times: typing in a text box in a tab may send keypresses to a text box in another tab. It happens when I open many tabs at once; the last tab to load usually steals the focus. It's a minor annoyance, though, and can be easily noticed looking at the screen, since typing doesn't appear where it should. However, spoofing dialog boxes can be more serious. Although suspending script execution in inactive tabs could solve this problem, it can break other things.
At any rate, I'm fairly confident this will be solved in a sensible way by Mozilla*.* developers.
My neighbor's
Bug seems to be fixed in Firefox already.
Gentlemen (and Ladies), start your check for updates! (Tools, Options, Advanced, Check Now button)
Join the Free Software Foundation
> Make the website launching any JavaScript event appear in the foreground
That's indeed how Konqueror has fixed this in KDE 3.3.1.
As I can't link bugzilla form Slashdot... go to http://bugzilla.mozilla.org/ and type in there the bug number. (None: it's not marked there as FIXED, but you should look at the "fixed-aviary1.0" keyword, which is what matters for Firefox 1.0)
A quick, easy, and usually painless solution to this is just to bring the tab with the active javascript into focus.
You'd of course only want this for certain events (alerts being chiefest among them...).
Lose Weight and Feel Great with Isagenix
This is an excellent example of two facts:
Here's what the vulnerabilities are:
In all the non-IE browsers, there's a potential issue with how tabbed browsing works. Basically, the problem is that stuff on tabs other than the active tab can still (a) pop dialogs and (b) have the keyboard focus. It's pretty clear that (b) is just a problem that should be fixed, because although it's possible to concieve of a circumstance where a user would want to look at one tab while typing into a box on another, it's clearly way too surprising and not nearly useful enough to be allowed. But (a) is more interesting. It's a side effect of the fact that pages continue functioning in all ways even when they're not the active tab. This includes running Javascript/Java/Flash programs, loading, rendering, etc. And that's a good and useful thing. But when a background tab pops a dialog, it may appear to the user that the dialog was created by the active page. If the user trusts one page more than the other, that can lead to problems.
The solution to this dialog-popping problem isn't obvious. Perhaps dialogs need to be labeled with the name of the site that created them. Perhaps some other solution. But it will be worked on, even though the risk is fairly small.
The IE vulnerability is very different in that it's a system compromise flaw. It's similar in one way, though: it's caused by a subtle interaction of features. In this case, dragging and dropping of image or media files with embedded HTML code, which may be malicious. This malicious code isn't a problem, really, because IE is security-conscious and won't execute it -- except that Microsoft has that terrible "security zones" design feature. Once the malicious code is moved from the "Internet" zone to the "Local Computer" zone, the code will be executed. What makes it especially funny is that Microsoft fixed this problem in SP2 by changing the Local Computer zone so tht it will no longer execute Active Scripts. But yet another bug in the security zones can be exploited to bypass that "problem" so SP2 is vulnerable as well.
Security flaws are everywhere, but what really kills Microsoft is their rash of bad design decisions in the past, turning little holes into remote root exploits. They're getting better, I believe, but it's going to be a long hard road for them to patch all of the problems that are created by their bad design decisions. It's too late, of course, to change the design. Too much depends on it.
I note the vulnerability Secunia found in Mozilla et. al. is easy enough to block. It depends on onMouseOver triggers and the launchTimedPrompt() function. Block either of those via the capability.policy.* settings and the problem ceases. I'm tempted to add launchTimedPrompt() blocking across the board simply because no Web site has any business launching a delayed dialog box.
More like "wihich Tab/User_action" combo executed the script code.
Just generalizing further.
errera hunamum ets
The Mozilla etc problem seems equally serious.
Mozilla etc... "If the user explicitly opens a page in a background tab, it may not be possible to tell what webpage a dialog box is associated with". Note that the exploit can not open a page in a background tab, it can only take advantage of that if it happens.
Exposure: If the user can first be tricked into opening a page in another tab, and the exploiter can guess whether the user has "open tabs in background" (or the equivalent option) selected or not, then they may be able to trick them into entering confidential information a little easier. There are other ways to get similar results without having to trick the user twice, using frames or with multi-stage popups.
Internet explorer: The exploit can be used to launch web pages in the local security zone. The hole here is really the fact that there is such a thing as a "local security zone" at all. For seven years now, exploit after exploit has used this design flaw in the HTML control to run arbitary code as the local user. Spyware, viruses, worms, spam bots, over and over again, malicious software has gained its initial foothold through variants of this attack.
Exposure: Visiting a web page can allow an attacker to take over your computer, without any further action on your part.
And you say "The Mozilla etc problem seems equally serious."?
Jesus.
After typing in some text (it won't appear, at least with 0.10.1) go back to the Securia page. The textbox there will have all that you typed in. The exploit works, sadly.
Christopher S. 'coldacid' Charabaruk -- coldacid.net
Open each character in a new window. The multiple pages for each character in tabs. That way you keep them organized.
Essentially it makes use of the fact that dialog boxes are attached to windows, not tabs, so if you have two tabs open, and a dialog box comes up, you don't know if it's from the page you're viewing, or a different tab.
It took me a while of trying out the demo to work out what it was they were saying was a vulnerability - perhaps I'm used to the issue, I browse with confirmation of sites that want to show cookies and thus dialogs are popping up all the time for tabs I've opened in the background (and it's usually frickin' annoying...)
This is, for the most part, a user education issue (if that), not a vulnerability, though the Mozilla foundation could in general make their systems way more friendly by hiding dialogs that do not relate to the current tab until that tab is showing.
You are not alone. This is not normal. None of this is normal.
Demonstrations of vulnerabilities: here and here
The "while" here means "at the same time that", not "whereas"."
You're allowed to grab focus on assorted events (like onload, or on a timer) and assign it to a specific text input box. Many sites like google and dictionary.reference.com use this for legitimate purposes.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I left Javascript enabled in Konqueror, but set "open new windows" to "ask" in preferences and set the other JS policies to "ignore." Site displayed normally, and the spoofed text entry box didn't launch.
This is my post. There are many others like it. If you don't like what you read here, go try one of the others.
Nope. I'm running 1.0 preview version and no updates available but the exploit is still working.
Konqueror is not integrated the way you might think. In kde konqueror is a kpart launcher that uses io slaves to grab information. So when you type a url into konqueror which can be any recognized url it then uses an io slave to grab that information and when it gets that information back it hands it to the appropriate kpart for that kind of information.
If you want add an html file on a server and use sftp://server:/path/to/file and it will still run khtml (the html rendering kpart). That is also why you can embed khtml in stuff like kmail and knode without much in the way of security issues since you can just have khtml render the html but not hook up any io slaves to it. That way it can't retrieve any outside resources.
KDE overall is fairly well layered. I would like to see more security work done on it but it is pretty decent at least. For example I would like khtml to run with no privelages at all. It doesn't really need any to begin with so why have it run with them. The services it accesses need to be secured but at least that would make it far harder for things to go wrong.
Most of the security work should probably happen in things like the io slaves, kjs (javascript) etc services since those can be used by any application (you can use http, sftp, webdav, imap etc from any kde file dialog box if you want) and get those more secured.
Computer modeling for biotech drug manufacturing is HARD!
The Last Measure link contains stuff you really don't want to be seeing. Don't click on it if you're just looking for a demo of the popup style.
"I would give my right hand to be ambidextrous."
Where these op-ups generated by shockwave/flash? If not could you add the sites where you got pop-ups to https://bugzilla.mozilla.org/show_bug.cgi?id=25383 1 (copy and paste or disable referers)
In fact, I'd like to see a list of options that will allow me to set exactly what JS can and can't do.
As an Opera user, I like to answer these.
* Ability to open up a new window when I request it (onclick)
Block unwanted pop-ups
* Ability to do useful DOM stuff
Well, this I really can't answer, since I don't know your useful. But most of the sites I see work just fine when I have enabled Javascript
Out:-
* Scrolling text in status bar
Allow changing of status field
* Anti-Right Click
Allow script to receive right clicks This option unfortunately doesn't stop the script from receiving middle clicks. Very annoying when trying to auto scroll around the page.
* onload/onexit
Can't ve stopped in Opera. (To my knowledge at least)
* resize window
Allow resizing of windows
* tell me that i can't have a URL box or status bar on a popup
This depends entirely on how you have customized your toolbars. My status bar and url box are in non-window specific toolbars, so in a way none of my windows have status bars and url boxes, but they get updated depending on which window I have last clicked.
* stupid 'effects'
Again, depends on your definition of stupid.
The window from an unactive tab coming to the front in Firefox does not really seem like that big of a deal. I kind of like the fact that it does this. At work, the server needs to resart to load a new java war file so I usually browse on other tabs while the server is restarting. when it starts, the notification window pops to the top. Perhaps there should be an option to turn this on or off (the option could default to off)...I don't really see that many people putting really important information into a javascript notification window anyway.
SIGFAULT
chroot for a browser seems a bit extreme... It's a lot of effort and I think the following offers similiar protection for a lot less work.
Create a disposable unprivledged account "luser".
From your primary user account enter at the shell prompt:
$ xhost + local:
$ su luser
(enter password)
$ mozilla &
You can keep a publicly readable download directory in that account to retreive files you downloaded. Otherwise "luser" should have no access to other user files anywhere else, and that account can be easily deleted and recreated if problems arise.
I set this up in about two minutes. I know chroot would have taken me a lot longer.
--Aaron Greenberg
Actually, according to MozillaZine the fix has been fixed in the 1.0 code tree, but hasn't been merged into the existing builds yet. I would expect a fix before 1.0 goes gold.