Slashdot Mirror
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"
Jimmy writes "Secunia is reported about a new vulnerability"
And in other news, Slashdot is reported all about a new grammatical error in the headlines.
Reporting anyone?
Indy Media Watch-Proctologist of the Internet
I opened Secunia, Then open another browser window to Citibank via Ctrl+N, and click on Citybank's Consumer Alert button, nothing happened.
But if I used the link from Secunia to access Citybank, the Popup is then hijacked.
So it seems like you need to access (click on a link to) your trusted site via an untrusted site to get hijacked?
Rock that crushes, Paper & Scissors that don't matter.
mac os x 10.3.6... running safari 1.2.4 (the latest build.)
I tried the test in Safari 1.2.4 under Mac OS X 10.3.6. I had pop-ups blocked, the normal way I set my browser. Doing the test, I saw the Citibank site fine. When I clicked on the "Consumer Alert" button, it looked like the regular Citibank content. No problem there. I refreshed and clicked on the other "try this test" link, and there still was no problem.
When I turned off the pop-up blocking feature, then when I tried the test, I did see a pop-up from the Secunia site instead of the Citibank text. Now that's a problem.
Clearly, this is just another reason to block pop-up windows.
Insert simplistic political, ideological, or personal proselytization here.
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.
I reproduced this successfully on Firefox 1.0 under Linux.
Now we can move from the myth that free software is impervious to exploits
Uh, who was saying that?
Indy Media Watch-Proctologist of the Internet
I just don't believe it. Anything -- even an exploit -- working in all browsers would be unprecedented!
It's a vulnerability, but it's the correct behaviour. Browsers should open the window in the target pop-up window, even if the page opening the page does not own that window, as I recall. As they say, that's no bug...
Since when has this country used intellectual elite as a pejorative term?
The exploit worked for me on Firefox 1.0 on Windows 98 SE with pop-up blocking turned off, but the exploit didn't work for me when pop-up blocking was turned on.
i did it using safari, got citibank, i have no account but was able to transfer $100 million into an offshore account. That was some test
Anyone seen my jagged little pill?
What are you talking about? Firefox has always had bugs, why do you think we get security updates? The difference, as we will soon see, is that the Firefox will have a patch weeks, or perhaps months before IE.
The fact that everyone is confused is an indication that their instructions suck. "Step one" is click on a link in the citibank site that you haven't visited yet. "Step two" is actually visiting the citibank site. And then "step three" is a no-op; the space for that step is instead used to discuss whether you are vulnerable. (Presumably, step five is "profit!!!"). Who came up with this and what planet are they from where this is a logical sequence of instructions?
I'd rather be lucky than good.
The first since 1.0 maybe, but certainly not the first outright.
As far as I can tell the problem is fixed in the latest Opera beta so they might be able to get it into a proper release pretty soon too.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
No, it's still impervious, the exploit didn't work on my system. Sorry, OSS still has a 100% perfect, virignal, like freshly-fallen snow track record. /sarcasm
No one ever said any of those things, and I doubt that anyone believes them, so get off your high-horse.
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
"If you're not confused by quantum mechanics, you really don't understand it." - Niels Bohr
Funny, I've tried this in Internet Explorer 6.0 and Mozilla 1.7, but I could only get it to "work" in Mozilla.
In Internet Explorer I pressed "With popup-blocker" (Google Toolbar) and up came Citibank, then I pressed the Fraudulent E-Mail button, and up came CitiBanks popupwindow, first when I closed the popupwindow the "This was hijacked" window appeared (as if triggered by the window.onclose function) but that does not strike me as a gigantic security-hole.
Of course the issue in itself is scary, but I'm confident the Mozilla team will have a patch out in no time.
This should probably serve as a reminder to webmasters out there, that if you want users to trust content you provide in popup-windows eg. for creditcard payments, you should provide the address-bar, and if the creditcard processing takes place on another server, explain to the customer before he clicks "pay by creditcard" why the window will load from another server.
My <1000 UID is with a hot chick
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.
Vino, gyno, and techno -Bruce Sterling
FF 1.0 on Win2K.
Middle-click to open citibank page in new tab YOU WILL NOT BE VULNERABLE.
Left click and allow citibank page to open in new window YOU WILL BE VULNERABLE.
At least, that's the behaviour I see on this box.
This all boils down to a Javascript vulnerability.
If web masters would stop NEEDLESSLY using Javascript to do things like open new windows, and would use it ONLY when there is no way using HTML to accomplish the same goal, then people would not need to have Javascript active all the time, and the impact of exploits like this would be greatly reduced.
If, instead of using <a href="#" onclick="foo"> or <a href="javascript(foo)"> type constructs, web designers would use <a target="_blank" href="something.html" onclick="javascript(stuff)"> type constructs, then if the user HAS Javascript active, then the web master can micromanage the newly created window. If not, then the user STILL gets a new window, just not one that the web master can remove all the chrome from.
Seriously - when was the last time you heard of an exploit that used straight HTML? All of the recent exploits in ALL browsers, IE included, have been in either Javascript or Active-X, not in the core HTML rendering.
There is a REASON for that.
www.eFax.com are spammers
I just don't believe it. Anything -- even an exploit -- working in all browsers would be unprecedented!
Lynx appears to be unaffected.
Comment removed based on user account deletion
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.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
The spoof worked for me on FF 1.0 on W2K. One more reason to use the Spoofstick browser plugin for FF or IE. It clearly showed the popup originated from secunia.com and not Citibank.
Bad boys rape our young girls but Violet gives willingly.
Comment removed based on user account deletion
I hope this helps the vast masses of smart
Comment removed based on user account deletion
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.
[alk]
Example: Sites that pop up their "main" window from their "entry tunnel." Exactly what justification do you have for thinking I still need to view your entry tunnel?
Example: (as mentioned,) sites that use Javascript to open windows. Granted, this practice came around before Opera/Mozilla introduced us to the wonders of tabbed browsing, but what's the point of pulling up a "diversionary" window and forcing the user to close it? Afraid they might not understand the concept of the "back" button?
Example: using flash/java/shockwave/etc to perform functions that could be handled in HTML, especially now that we have DHTML. I have trouble with understanding the argument "we will be more successful if we deny access to some percentage of the population."
etc etc etc.IMHO, this is a symptom of the problem where people assume "everyone else thinks / acts / behaves in the same way I do."
Well since the target attribute of the anchor link is not part of the XHTML 1.1 Strict standard, web developers who *are* actually concerned about standards are required to use Javascript to perform the pop-up behavior. By using standards-based design and manipulating the DOM via Javascript, we can accomplish anything. No need for clunky the "onclick" or even the outdated "target" attributes.
... useless as blink tags.
I disagree. I think they have their moments. Such as displaying incidental information without interrupting the flow of something you're already doing (say, a help link in a wizard-style sequence of pages)
like everything else, popups are a tool which can be used or misused. Unfortunately they're mostly misused.
Screw you all! I'm off to the pub
Except that it would be easy to exploit this. Here's an example:
1) Send out a phishing expedition, asking people to log into their BofA account to update their account information. Make it look real official, and include a link that goes to "https://www.bankofamerica.com". The new window takes them to the real site, encrypted and everything.
2) Customers login and check their mailing address, or whatever.
3) Some percentage of them will leave their windows open for more than 10 minutes, at which point BofA sends their standard pop-up window warning about account inactivity and logout.
4) Hijack the pop-up window and do Something Nefarious, like initiate a funds transfer.
Now, this isn't a perfect example. But there are an untold number of different sites out there who use pop-ups for perfectly reasonable applications, and it would be trivial for some phisher to get people to go to those sites using his link.
The best thing to do is, for those sites who use pop-ups to communicate with their visitors, use some nonstandard form for naming those windows. Use the person's username, a random string, a DES hash with the first two characters of the day of the week as the salt and the time the page is first loaded as the string, whatever (no, don't use "whatever", that's just a figure of speech)'
God invented whiskey so the Irish would not rule the world.
That's why I use iFrame popup instead of window popups. With popup blockers already appearing built into browsers, I'm assuming that they will be standard everywhere soon.
With scripting, you can make iFrames draggable, closeable and behave and look just like regular windows but they are, in essence, windows within a window and are tied closely to the current browser.
There are reasons to have popups like, for example, color or date pickers (with a calendar). It is actually much easier to build a draggable DIV than a draggable iFrame but the draggable DIV doesn't show up on top of certain HTML elements and hence becomes useless (even with an infinitely high z-index).
By the way, you can get draggable iFrames to work in both MSIE and Mozilla. I just bought my iMac for testing but I'm pretty sure I can get it to work in the mac versions too as they all have the necessary language and DHTML components. All I can say though is that JavaScript and DHTML are definitely vendor dependant, and I don't care if you are mozilla or Apple or Microsoft, they ALL have quirks and bugs that go outside of the specifications. In many ways, my high speed photoshop-style image scripting program (for use on web servers) was easier to write in C# than trying to figure out how to make things work across every browser out there!
Anyways, programmer alert. I wouldn't depend on popups working in the future if your app depends on it. Make sure to use iFrames or have a non popup dependant way of doing the same thing!
Sunny
Be my Friend
when it takes Slashdotters 5 minutes and other people's help to activate it...
Just an interesting note - if I left click on secunia's test page, and secunia opens citibank in a new tab, the exploit works.
If I middleclick on the test page and *force* firefox to open the site in a new tab, the exploit fails.
I don't know enough to now if this is a limitation in the exploit or in how they've written the exploit, but it's odd and interesting
An Invisible Entity of Vast Power whose existence must be taken on faith alone: Liberal Media
My fix is a little easier (in my opinion, only because I hate having another toolbar taking up desktop real estate)...
under about:config, I have dom.disable_window_open_feature.location set to true. So every window must show the location (and because of it, I immediately could see the webpage I was at was not citibank.com).
Sig!
You've got to think about accessability when making links, imagine Javascript turned off. Does it still work? Imagine using a screen reader, can it follow the link? The HREF should be a valid URL to the page you are trying to display, if Javascript is turned on, you override the behavior by attaching an event to the anchor in question.
This excellent article on ALA should answer any pending questions on the issue.
BTW, the target attribute of anchors was dropped between XHTML 1.1 Transitional and XHTML 1.1 Strict.
I think there is an easy fix for this. Basically the exploit is based on the fact that you can use javascript to open a window with the target the same as another window and overwrite the other ones content.
Well, why not make a new rule in javascript that would disallow any javascript code to access any popups that aren't a direct child of the current instance of the browser.
Basically what i mean is to have each window in it's own namespace and have the child window share said namespace. (I think one would have to not allow grandparents to access it either though).
so basically if two seperate windows open a window with target="name" then 2 windows are opened one for each instance and they have nothing to do with each other.
proxy
"Firefox has prevented this site from opening 1632 pop-up windows. Click here for options..."
...And now 2000... persistent little bugger...
And this is a version of Firefox I installed approximately two weeks ago.
The Penguin Producer
1. 'target' is certainly part of standard html.
http://www.w3.org/TR/html4/present/frames.html#ad
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-
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.
If opportunity came disguised as temptation, one knock would be enough.
3^2 * 67^1 * 977^1
All browsers? Can someone tell me how to get this to work on Lynx?
LedgerSMB: Open source Accounting/ERP
Rumor has it, patches to support this exploit in Lynx will be available by the end of the week. ;)
It is vulnerable, but not when you open the link in a new tab, only when you open a new window. So when you enable Single Window mode, you should be pretty safe.
Yup. Check out Ian Hickson's "Sending XHTML as text/html Considered Harmful" for a quick primer on what most sites that do XHTML are doing wrong. Check out Evan Goer's list of "X-Philes" for a list of the very few sites which get it right, and his purge of sites from that list for an indication of how easy it is to go wrong even after you've initially gotten it right.
As for HTML generally not producing good markup and being "too loose", I hate to break it to you but XHTML 1.0 and HTML 4.01 are element-for-element identical; the only difference between the two is that one is an SGML application and one is an XML application. And when you serve XHTML 1.0 as "text/html" (e.g., when you do XHTML the way ESPN and others do) you don't gain any of the strictness benefits of XML. And the only thing XHTML 1.1 does on top of that is deprecate a couple more things and add modularization and ruby support, so I'm really not sure where all the "good markup" would come from in a transition to XHTML. Plus there's no reason to believe that serving XHTML 1.1 as "text/html" is conformant, so if you use 1.1 you either break the spec or you shut out IE. Likewise, switching to an XHTML DOCTYPE and using XML syntax doesn't magically confer accessibility on a page; it's just as easy to write a horrid, bloated, table-based images-for-everything page in XHTML as it is in HTML 4.01.
I suspect that you're making a common mistake among people who've just discovered web standards: you're confusing XHTML with good markup and best practices (check out Molly Holzschlag on what standards are and aren't). Anyway, it's quite possible to write beautiful, clean, accessible, semantically rich HTML 4.01 with separation of content from presentation; after all, it's got the same set of tags and attributes as XHTML 1.0, so if you can do it in one you can do it in the other just as easily. And when you consider that serving valid, well-formed XHTML according to the spec can be a nightmare at times, it's no surprise that even "gurus" of the standards world (e.g., Mark Pilgrim, Anne van Kesteren) have gone back to or recommended sticking with HTML 4.01 unless you really need one of the features gained by an XML-based HTML.
And lest you continue to think I'm some sort of skeptic or enemey of web standards, well, every site I've built in the past three years (basically, since I discovered there was such a thing as a "web standard") has been valid, accessible, and CSS-based. I just know from experience that valid markup and stylesheets are one part of the equation, and there are an awful lot of those "best practices" that aren't ever published in a spec from the W3C or anyone else.
The exploit did work on my FireFox 1.0, and I have always had all those checkboxes except "Change Images" disabled.
I would like to disable JavaScript entirely, but unfortunately that breaks too many pages.
Malicious site? All you need is to compromise or hijack (DNS etc) the relevant banner ad site or partner site.
Has happened before.
Users may still have to click something, but they could easily be tricked into doing that. Most users aren't constantly vigilant and observant. If the compromised banner ad opened another window that looked like Citibank's site whilst you were using Citibank's site, you could fall for it - especially since Citibank does use pop-ups.
I tried this, and it didn't work. Then I realised what they were actually wanting. Open the citbank window, then click on the genuine link in the citibank window (pictured in the site) and if the window opens and shows citibank stuff you're ok, if it opens and then immediatly written over with their data, you're vunerable.
I did this, and Firefox 1.0 (linux) was vunerable. The site wasn't clear that the first site wasn't the vunerability, but links from a genuine site can be made vunerable.
Of course, you have to visit one of thse sites, and then go to the other.. so you have to be fooled by the malware site into it first.
Safari appears to be OK, as long as 'block pop-up Windows' is selected in preferences. ... So it is vulnerable by default, sadly.
Client-side verification This includes validating that all the fields in a form are filled in, as well as checking that the user entered the correct password. Naturally, this is the silliest reason to require Javascript, as the validation step still has to be done on the server side anyway, making the client-side validation a redundant convenience at best, and an addle-brained sign of utter incompetence at worst.
Just what I want.. a user posting 300 times before realizing that, yes, they must fill out the form. Think about something like Yahoo mail. I can go into a new message and if I forget to put in a To:, it will still post to the server and come back and say that I'm a moron. With JS verification, I would know instantly.
Obviously client-side verification shouldn't be used for passwords, but checking that a form is at least completely filled out is very helpful, both as a designer and a web user. Client side verification is practically instant and does not burden the server with incomplete requests. Of course, client side verification does not exempt you from having to perform server side verification.
BTW Javascript has nothing to do with Java except the name.