New Vulnerability Affects All Browsers

Jimmy writes "Secunia is reported about a new vulnerability, which affects all browsers. It allows a malicious web site to "hi-jack" pop-up windows, which could have been opened by e.g. a your bank or an online shop. Here is a demonstration of the vulnerability"

Comments

Re:I don't get it

[Caine]

Did you actually follow the instructions? That is: Did you click on the image on the citibank-page, thereby giving you a third window? It doesn't sound like it from your comment.

And the exploit worked just 'fine' on my firefox 1.0.

Re:Sniff, our little browser's all grown up...

[Indy Media Watch]

Now we can move from the myth that free software is impervious to exploits

Uh, who was saying that?

Re:It doesn't affect Safari

[narratorDan]

Actually it does effect Safari, but you have to jump through hoops to get it to work.
After you have clicked on the link, you have to refresh the Secunia page, then it will work. It's kinda strange, but I guess it is a vulnerability. Kinda like walking back and forth through a bad neighborhood while counting your cash.

NarratorDan

Here's how it works

[sbszine]

The links to Citibank from the Secunia site are actually handled by JavaScript. The script sets a timer, then opens citibank. Every second or so, Secunia's script then checks whether you've opened Citibank's pop-up. If you have, it opens a window with the same name (i.e. variable name) as Citibank's window, thus overwriting their content.

So the attacker doesn't need you to click on anything, they just need you to have their site open -- with the timer going -- in another window. Also, the attacker needs to know in advance what name the victim site's pop-up is referenced by. A dynamically generated name could possibly defeat this attack, though the attacker could always crawl the DOM for a handle to the pop-up.

Re:All browsers?!?

[El Cubano]

I just don't believe it. Anything -- even an exploit -- working in all browsers would be unprecedented!

Lynx appears to be unaffected.

Of course it's a bug

[Chuck Chunder]

Target names should only exist within the namespace of the site that created them.

Site A should be able to create and interact with a window named "popup".
Site B should be able to create and interact with a window named "popup".
This should happen without either site interfering, blocking or overwriting the other. They should simply be invisible to each other, existing in completely seperate little worlds.

Re:Of course it's a bug

[Anonymous Coward]

OF course that seems sensible. But when you say "should" do you mean "should" because you think so, or because some W3C or other standard says so?

Re:I don't get it

[Jehlon]

No kidding their instructions sucked. Here's a step-by-step:

0. If you have not tried the test already, skip steps 1-3.
1. Copy these instructions to Notepad.
2. Close all browser windows.
3. Open a new browser window to
http://secunia.com/multiple_browsers_window_injec tion_vulnerability_test/
4. Skip down to "Step 2" and click the link appropriate for your system. The vast majority of users will click on the link "Test Now - With Pop-up Blocker - Left Click On This Link".
5. Click on the "Consumer Alert" image on the right of Citibank's page.

If the exploit was successful, the pop-up window from Citibank will attempt to open a site from secunia.com. I don't know what that page looks like, only that their webserver didn't respond when I tried going there.

I hope this helps the vast masses of smart /.'ers who don't care to take 10 minutes to decompile secunia's instructions.

Re:no problem here...

[undertow3886]

No problem on Konqueror 3.3.1. On their site though, they said the Konqueror version they found the problem in was a 3.2 version.

Mozilla/Firefox Workaround

[loconet]

According to MozillaNews the following work around can be applied to Mozilla/Firefox:

1. Enter about:config in the Location Bar.
2. Enter dom.disable_window_open_feature.location in the filter field.
3. Right-click (Ctrl+click on Mac OS) the preference option and choose Toggle (the value should change to true).

This issue is already being worked on bug 273699 (copy link location, paste) filed a few hours ago.

As a side note, being able to see the bug fixing progress unfold is one of the many reasons why i love open source. I am able to learn so much from just seeing the process take place from start to finish, how it is reported, test cases created, problems that arise, insights into other parts of the system, who the people involved are, reviews, patches, etc.

Re:Mozilla/Firefox Workaround

[thomkt]

This doesn't prevent the pop-up hijacking from happening; it forces the address bar to display, so you can see the location of the pop-up.

From the page:

"Note that, although the attack site can inject its own content, it cannot change the URL appearing in the Location Bar. Firefox and Mozilla have the ability to deny access to the Location Bar so all pop-up windows always have it."

Re:Once again, why needless use of Javascript is B

[http]

Nice try.

1. 'target' is certainly part of standard html.
http://www.w3.org/TR/html4/present/frames.html#ade f-target
Just because it isn't defined initially by the A tag doesn't mean the A tag can't use it.

2. From http://www.w3.org/TR/html4/types.html#type-frame-t arget:

The following target names are reserved and have special meanings.
_blank
The user agent should load the designated document in a new, unnamed window.

PS. Hey mods, if you don't know about a subject, don't mark a post 'informative' just because there's a link in it.