Date: | February 25, 2004 / year-entry #75 |
Tags: | history |
Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20040225-00/?p=40483 |
Comments: | 34 |
Summary: | The short answer: "Because there is no NIF_PARSELINKS flag." The long answer: When balloon tips were first developed, there was no ability to embed links. Consequently, programs were free to put insecure text in balloon tips, since there was no risk that they would become "live". So, for example, a virus scanner might say "The... |
The short answer: "Because there is no NIF_PARSELINKS flag." The long answer: When balloon tips were first developed, there was no ability to embed links. Consequently, programs were free to put insecure text in balloon tips, since there was no risk that they would become "live". So, for example, a virus scanner might say "The document 'XYZ' has been scanned and found to be free of viruses." Now suppose hotlinks were supported in balloon tips. Look at how this can be exploited: I can write a web page that goes <TITLE><A HREF="file:C:\Windows\system32\format.com?C:"> Party plans</A></TITLE> I then rename the file to "Party plans.html", attach it to some email, and send it to you. You download the message and since you are a cautious person, you ask your virus scanner to check it out. The balloon appears:
"Oh, how convenient," you say to yourself. "The virus scanner even included a hotlink to the document so I can read it." And then you click on it and your hard drive gets reformatted. "So why don't you add a NIF_PARSELINKS flag, so people who want to enable hotlinks in their balloon tips can do so, and still remain compatible with people who wrote to the old API?" (I've heard of one person trying to pass a TTF_PARSELINKS flag in the NOTIFYICONDATA.uFlags member and wondering why it wasn't working. I hope it's obvious to everybody why this had no chance of working.) Because that would just be passing the buck. Anybody who used this proposed flag would then have to be extra-careful not to put untrusted links in their balloon tips. Most people would just say, "Wow! A new flag! That's awesome!" and start using it without considering the serious security implications. Then somebody can trick the program into putting untrusted text into a balloon tip and thereby exploit the security hole. "Aw, come on, who would be so stupid as to write code without considering all the security implications?" I hope that was a joke question. The best way to make sure things are secure is to make it impossible to be insecure. |
Comments (34)
Comments are closed. |
I would change your last sentence to read "The ONLY way to make sure things are secure is (for you) to make it impossible to be insecure." Don’t rely on other people, do it yourself. Excellent points.
Of course, would this stop someone from creating their own "balloon notification window" that did contain what looked like a clickable link? Probably not. OTOH, if someone were smart enough to break security in that fashion, they probably wouldn’t NEED to…
Little offtopic here.
Raymond, do you know how to enable new XP-styled selection rectangle in list view (like the one in Explorer)? My MSDN doesn’t show any appropriate flag. :(
Erbo: True, but at least it won’t be Explorer doing the insecure thing at the unwitting bidding of another program.
Oleksiy: Did you remember to specify in your manifest that you wanted the XP version of the common controls?
Clickable titles? Isn’t that a huge problem in itself that opens up potential holes all over the place?
Just for fun, i put the URL you used as the title URL for this page.
Does this mean your blkog has now become a very dangerous weapon?
My point: If it is not secure to allow a URL in a baloon tip, then it is also not secure to allow it on a web page or any other place.
Ok the super smart bloggers script has reformatted the URL, turned it into a http thing…
But you know what i mean.
IE already has safeguards to prevent you from running unsafe links. But people who put links in balloon tips typically want to link to something fancier than just a web page.
> If it is not secure to allow a URL in a balloon tip, then it is also not secure to allow it on a web page or any other place.
Correct, it would not be secure. That is why the IE and script teams worked together to develop a security system that mitigates this threat.
Therefore, the balloon developers would need to develop a security model for balloon tips.
It took me seven — seven! — blog entries to describe just a _couple_ aspects of the way that JScript interacts with the IE security system. Developing security systems is EXTREMELY expensive and introduces a whole new attack surface.
Is being able to have "live" balloons really worth that expense? That’s a judgment call; obviously the people who implemented balloon tips thought not!
Yes, I have manifest there. I can even "select" column to show the column I sort by. So, themes work just fine. But the selection isn’t there. :(
I use MFC 7, if this does matter.
Oleksiy, LVS_EX_DOUBLEBUFFER is your friend.
I just don’t understand this.
What would be the idea behind putting links in the balloon?
Should that be html-like hyperlinks that open a URL? Then the ballon would launch the default browser with that url and that would be not that much of a hole?
Until recently it was possible that a webpage sends you over to c:ProgrammeCompanywellknown.html
Or is this all about having links to folders or files?
Is that a problem? If a programm can launch explorer, why shouldn’t it also be able to open a baloon tip that opens a folder when clicked on.
Or why not have a callback from the link back to the app so that the application can open a dialog.
Somehow I don’t understand what’s this all about. :-(
The point is that the program is being *tricked* into launching a command line.
I still don’t understand the reasoning very well.
Nowadays every email client, text editor, instant messenger, etc, in other words almost every application supports hyperlinks.
Windows makes this very easy: Just call ShellExecuteEx and you’re donet, IE is invoked.
What you seem to say is that invoking IE is not secure, and that every application has to implement its own security when invoking IE.
The solution would not be to implement security in the baloons.
The solution would be to to implement security in the invokation of IE, once and for all, not just for baloons but for any application that hyperlinks.
If IE is secure, then there is no problem.
If IE is not secure, wether baloons can hyperlink or not, fix IE instead.
This assumes that the only thing a program might put into a balloon link is a web page. You may have noticed that many programs are using link-like UI for things that aren’t actually links. It’s just a cute way to say "click here to do something".
Programs that use the balloon link feature on purpose usually want to do things that IE won’t allow. For example, maybe they want the link to be "Click here to run a virus scanner".
The point is that Explorer doesn’t know whether the caller wants IE security enforced or not.
Well then don’t implement links like that. Make it so links can only be indexed and come back with a number rather than a string, so that it’s up to the program to actually _execute_ the link. There are plenty of solutions to make it hard for programs to mess it up.
Yes a complicated notification system could have been developed where each balloon gets a code assigned to it and when the clicks the notification program is told "link 3 in balloon 6 was clicked". Of course the notification program would then have to keep track of all the balloons that it has requested and the links in them so it would know how to react. And since balloons can be delayed for hours after the notification program requests them the notification program would have to retain that information for what could be quite a long time.
It could be done, but it would be a lot of work for comparatively little benefit.
Or a very simple notification system.
If the hyperlink is really just a string, then why not just send the string back in the notification?
Because the raw string doesn’t necessarily help the caller know what the user clicked on.
In the above example, suppose the string "Party plans" got returned. That doesn’t contain the full path or extension, so the caller won’t know which file to launch.
You can also imagine where multiple strings are called "click here" but do different things.
Plus of course there’s the localization problem.
One thing I’m having difficulty figuring out is why the link-click would be handled by the shell in the first place. It makes much more sense to just send a message back to the app which created the balloon, and let it handle the results of the click.
Similar to the way notification icons work, in fact.
Right, and one of the tricky parts is trying to pack all the information about what got clicked into a single lParam.
I’m not saying it can’t be done. It’s just a lot of work for something of limited value. (Especially since users tend to ignore balloons anyway!)
What i mean is the full string. Not just the text that is displayed, but including the <a> tag. The application could put anything in the tag then that could be useful to recognize it
Sure, that could be done. Now try to squeeze it into an lParam in a way that doesn’t leak memory if the program forgets to respond to the message.
I guess what chafes most people is really that it’s hard to recreate the existing control in a fashion that doesn’t look wrong (especially if the UI theme changes), behaves in the same way, and also allows you to use rich text.
After all, if you really want to do it right, you want to be using Uniscribe, and then you’re going down the path of completely re-implementing RichEdit. I guess you could hook RichEdit, but that might be messy.
What it comes down to is that developers want rich output in their presentation layer, I guess. And that’s tricky to do by yourself unless you spend a lot of effort, embed mshtml or embed richedit.
BTW Raymond; I understand the design tradeoffs which led to the links not be included in the balloon tips… I’m just kind of thinking aloud.
Well not even the balloon control uses rich text. It’s just plain text (with some underlining if you enable links). No selective boldface or any of that stuff.
Hopefully WinFX will make it easier to combine multiple controls.
Yeah, but I think that’s what people are griping about; they’re asking for links, when what they really want is more control over formatting and feedback. They don’t want a hyperlink control in there – they want a richer model for display.
Call it Office/Encarta/Money UI Envy ;-)
My own personal jury is still out on WinFX and Avalon. I’m holding judgement until I see some later builds.
Pocket PC 2002 and later offer notification balloons with links in them, and the links result in a call to IShellNotificationCallback::OnCommandSelected or IShellNotificationCallback::OnLinkSelected depending on what sort of link was clicked.
Another case of independent development of a similar feature.
Thanks Sven, LVS_EX_DOUBLEBUFFER helped!
It’s in headers, but not documented yet. :((
Balloons aside, the fact that you can execute format.com via a file:// URL is mind-boggling. That’s a very odd security model, if the words "security model" can even be used to describe it.
The example URL doesn’t format, though, I tried it. :-)
Instead of a file:// URL, you could use something like http://some.hacker.site/trojan.exe
(In fact the format.com example doesn’t work. I intentionally picked something that doesn’t work so people wouldn’t get ideas. But the principle is there: Just stick in something that would be bad to pass to ShellExecute.)
Ok, then I don’t get it. Why could the URLs not simply be forced through whatever mechanism the user has selected for handling things of that type and so have the appropriate security?
Again, because most of the time the thing you want to hotlink is not an URL. For example, look at Help and Support — all those things that look like hotlinks and not a single one of them is an URL.
A non-admin user shouldn’t be able to format their own hard drive. A typical user (the type who’d get fooled by something like this) should not be logged in as an admin.
Stuff like this is just compensation for a broken security model.
Right, a formatting attack is meaningful only against people who have permission to format the computer. But you can see other attacks that do not require admin privs (e.g., delete all your files).