** Security Notice **, Important security news for developers Options

[Brendan Bellina]

It would have been appropriate to add a new security preference in the Engine itself so that users could decide for themselves what level of security they want - Yahoo! only widgets, exclude widgets flagged by Yahoo! as potentially insecure, allow all widgets.

For developers you should include a way for them to tell in the debug window when their widget starts that it will be flagged as insecure and why so that they know when they upload it to the gallery that it will pass the security check.

Removing widgets from the gallery only encourages people to host them themselves elsewhere, which means you have lost all future leverage. You encouraged the use of unique identifiers, sold them to developers as a beneficial thing, and are now using them to blacklist widgets you didn't write.

The approach Yahoo! has chosen to take is counterproductive and will only result in people uploading widgets to alternative sites so that they wlll know that their work will not be yanked without their knowledge. Without the trust of the developers the gallery will be empty.

Fixing security holes is important, but the process chosen is flawed.

Personally I think you need someone in your group who thinks more strategically.

[Rob Marquardt]

Personally I think you need someone in your group who thinks more strategically.

I don't know that knowingly leaving users' computers at risk when there's something that can be done about it is a good strategic direction.

But I'm just speaking for myself there.

[Sarah]

But OTOH, I don't necessarily want to tell people what we're scanning for as then people might try to get creative in order to bypass the scan.

Security through secrecy? Seriously? Tell us your algorithm for finding the issues, and maybe we can help you make it better so you don't have to worry about people "bypassing" it. The fact that you're worried now about people bypassing it doesn't give me a lot of faith that widgets you approve in the future won't have this problem.

And this statement also implies that you don't trust the developers. There are 3 kinds of people (I'm probably over-generalizing, but oh well) that might want to do this.

1. People who feel that getting around your scan would be easier than implementing a fix. The fix is pretty darn easy and finding the event handlers is simple, as long as you have access to awk/grep or a decent text editor. Actually, I don't know why people need a tool, but that doesn't make your statement any less wrong.
2. Malicious people who want to do serious damage. Chances are, you would have noticed these tendencies already if you've been scanning widgets they've submitted.
3. People who want to prove they are smarter than you and can get around your scan. See my comment above about telling us your algorithm and letting us help you. There are probably more white hats than black hats in this community.

Please remember, this is not about malicious coders or trying to punish Widget developers. It's about normal, honest Widgets getting unexpected code injected into them from a 3rd party.

I want to stop running those widgets today, not on the 16th. Can you publish the list of affected widgets now? Also, I think all widget users, not just developers, have a right to this information. I assume one of the reasons you're waiting until August 16th is to give you time to get a new engine out that can stop certain widgets from running. But that leaves just under 2 weeks with an unplugged security hole. A security hole that is now public knowledge among developers, and some creative, evil person could hack a site and do some damage -- they know they problem, and they know the fix timeframe. But the general users know nothing, unless they read this forum.

I think you should publish the list of affected widgets somewhere -- your blog maybe? And put a message on the Widget Gallery page or the Y!WE home page telling people there's an issue. The users have the right to know as well, and many of them probably don't read this forum.

[wrlee]

As for your update test. Is there any special reason why it does not fail gracefully? While coding this function, did you really expect that the user always has a internet connection and that the gallery could never be unavailable for a moment?

Yup, I sure should have. Since I do this for free; and since I have a fulltime job that has kept me pretty busy lately; and the widget isn't useful if there is no internet connection; and, well, I sometimes have bugs, I hadnt rememebered to fix this problem til now.

Too bad Y! does this big change on Friday when developers' attempt to address the issues as soon as possible can't be satisfied very timely.

:-(
Bill...

[dindiface]

What about your slow respond, as useual it can take weeks before you check and republish updates I fixed my widget and submitted it, since you did not gave any tool to check if my fix is good enough, this can take few cycles.
each cycle is long (thats how it is,it takes time) so what will happen in 2 weeks, when you , because you are slow, and gave no tools, will disable widgets, not because people did not put the time to fix it, just because you did not ut the time to develop a toold, or checkit fast enough.

I completely agree with you, I submitted the widget immediately fixed, and sent mails, but I am not sure why it is not getting republished.

It would be very nice to have the script that checks, for me it does not matter if it is just command line and only runs on a UNIX-style shell (Linux/OSX/etc).

Or just a regular expression so we could sed it and awk it, but like this i kinda feel being in the dark.

cheers

Just a note : I am not _DEMANDING_ anything, I am just saying, that you could have left time (e.g. 3-5 days) after a notice, and then run the check on the resubmitted stuff.

And again, let us know the algo, or let us use the script, so we can avoid false positives, and cause you less work.

I also understand, if you do not want to give the script out, because I am sure some will look into it and write exploitable code on purpose, one the script does not detect.......

So here is an idea (so you see, that I am not just complaining here): So why not just create a sandbox, as easy as a file upload, and your script run on the script. After the upload the script would return:
main.js Line 114: vulnerable code detected. - openURL('bad'+way+'to call openURL');

[Ed Voas]

Removing widgets from the gallery only encourages people to host them themselves elsewhere, which means you have lost all future leverage. You encouraged the use of unique identifiers, sold them to developers as a beneficial thing, and are now using them to blacklist widgets you didn't write.

Yeah, um, it's not using the UUIDs. They are only used for updates, as we said. Stop your conspiracy theories right there.

This is about protecting users, btw. And your Widgets have been found to have security holes in them. If people are going to come to our Gallery with a certain level of trust, we need to ensure that there aren't any vulnerabilities. I think we're being very proactive about protecting the end user, which is what really matters. If you have issue with that, I'm sorry, but the safety of our users comes first above all else.

I want to stop running those widgets today, not on the 16th. Can you publish the list of affected widgets now? Also, I think all widget users, not just developers, have a right to this information. I assume one of the reasons you're waiting until August 16th is to give you time to get a new engine out that can stop certain widgets from running. But that leaves just under 2 weeks with an unplugged security hole. A security hole that is now public knowledge among developers, and some creative, evil person could hack a site and do some damage -- they know they problem, and they know the fix timeframe. But the general users know nothing, unless they read this forum.

I think you should publish the list of affected widgets somewhere -- your blog maybe? And put a message on the Widget Gallery page or the Y!WE home page telling people there's an issue. The users have the right to know as well, and many of them probably don't read this forum.

Really, the reason for the lag time was to give you all a chance to reupload so that when users get the notification that it's been disabled for security reasons, there's an update to direct them to.

But you definitely make a very good point and I'll see what the collective thinks about this. Let me tell you though... it's a large list.

[Michael's Programming]

The problem is most computer users really are not computer savvy; some of them are just downright stupid. (Not trying to be offensive to anyone) You have to almost baby some users, and that means doing something that they should be able to do themselves: namely, watch for bad widgets and accept the risks. Most wouldn't know of those types of risks, so you have to guard the users from them at the beginning.

EDIT: Some examples of stupidity.

This post has been edited by Michael's Programming: Aug 6 2007, 05:53 PM

[smoger]

Can anyone here help me out with a link to a simple widget that uses this new method? Unfortunately I'm shaky at best in Javascript and I seem to be having some trouble following the post which explains how to make the fixes. It's far easier to learn by example so if anyone has anything that might help me out it would be greatly appreciated.

Theres just *something* there that's going over my head..

Thanks in advance to anyone who can help

[Sarah]

Can anyone here help me out with a link to a simple widget that uses this new method? Unfortunately I'm shaky at best in Javascript and I seem to be having some trouble following the post which explains how to make the fixes. It's far easier to learn by example so if anyone has anything that might help me out it would be greatly appreciated.

Theres just *something* there that's going over my head..

Basically, you don't want any event handlers that use dynamically constructed strings when those strings are comprised of data that comes from a website, even if that website is your own and you *think* you have total control over the content. Search for ".on" (will pull up onClick, onMultiClick, onMouseOver, etc) in your code and review all your event handlers and fix them appropriately. The problem is with all event handlers that use strings, not with any particular event handler or the "openURL" function.

I got bored tonite and wanted to see how easy it was to take advantage of this security issue. I wrote a simple widget that:

1. retrieves a web page when a button (well, actually it's text) is clicked
2. displays the page content that was retrieved when another button/text is clicked or the appropriate context menu item is selected.

In order to simulate a website hack, I actually have two buttons - "Retrieve Standard Page" and "Retrieve Hacked Page" for #1. When you view the contents (#2) after the hacked page is retrieved, a file on your system -- which is chosen via the widget since I didn't want to do real damage to your system (or mine) -- will be moved the the recycle bin/trash. If you review the kon file, you will notice that there is no code to move that file to the recycle bin/trash; this action is a result of the contents of the hacked page being used in the event handlers.

If you want the widget, PM me with your email and I'll send you the file. The widget is pretty simple (imo) and includes the code to fix the security issue. The "fixed" code is currently commented out since the purpose of the widget was to demonstrate the problem, but you could comment out the insecure code and uncomment the "fixed code" to see how it should be.

[smoger]

Basically, you don't want any event handlers that use dynamically constructed strings when those strings are comprised of data that comes from a website, even if that website is your own and you *think* you have total control over the content. Search for ".on" (will pull up onClick, onMultiClick, onMouseOver, etc) in your code and review all your event handlers and fix them appropriately. The problem is with all event handlers that use strings, not with any particular event handler or the "openURL" function.

I got bored tonite and wanted to see how easy it was to take advantage of this security issue. I wrote a simple widget that:

1. retrieves a web page when a button (well, actually it's text) is clicked
2. displays the page content that was retrieved when another button/text is clicked or the appropriate context menu item is selected.

In order to simulate a website hack, I actually have two buttons - "Retrieve Standard Page" and "Retrieve Hacked Page" for #1. When you view the contents (#2) after the hacked page is retrieved, a file on your system -- which is chosen via the widget since I didn't want to do real damage to your system (or mine) -- will be moved the the recycle bin/trash. If you review the kon file, you will notice that there is no code to move that file to the recycle bin/trash; this action is a result of the contents of the hacked page being used in the event handlers.

If you want the widget, PM me with your email and I'll send you the file. The widget is pretty simple (imo) and includes the code to fix the security issue. The "fixed" code is currently commented out since the purpose of the widget was to demonstrate the problem, but you could comment out the insecure code and uncomment the "fixed code" to see how it should be.

Thanks Sarah, I appreciate the explanation. After I gave my brain some time to breathe I came back to the widget and was able to work through the steps in the original post.

Now, how exactly do we notify Yahoo of the updates? It seems they are not taking uploads at the moment(since yesterday evening)

[Brendan Bellina]

And your Widgets have been found to have security holes in them.

Actually my widgets have now been confirmed by Yahoo! to NOT have security holes in them. The algorithm being used resulted in 28 false positives.

Before publishing widgets on lists of "insecure" widgets, perhaps the algorithm should be improved first.

[Sarah]

Before publishing widgets on lists of "insecure" widgets, perhaps the algorithm should be improved first.

I disagree with your statement.

People have a right to know that there is a problem. And I, as a widget user, want the list, even if the list includes false positives.

You're taking affront because you don't want it public knowledge that you made an insecure widget when you didn't. Fair enough. But do you really believe people shouldn't get the list because of a few false positives? A widget could damage someone's computer because of this problem, and maybe if the list was public they wouldn't have been running the widget at all. A few false positives on the list is better than not including a few affected widgets. Yahoo should say something like "These widgets might have problems" and explain the potential for false positives and then release the list.

A few of my widgets have been found insecure, at least one of those was a false positive. I still want the list and the problem made public, but it looks like it's not going to happen.

IMO, the security problem is caused by:

1. the Widget Engine allowing strings to be assigned event handlers
2. the Widget Engine allowing the use of "eval"
3. a flaw in their old approval process that didn't thoroughly check strings used in (1) and (2). If they want a Gallery full of safe widgets, then it is their responsibility to make sure no shady code slips thru.
4. careless coding on the part of the widget developers

BTW, you (and this is directed at the Yahoo team) are checking 'eval' as well as the function handlers, right? Because it seems like any evals that are built using data retrieved from the web would be susceptible to this problem. I haven't seen any mention of eval in the email or this thread, so I thought I'd ask. Also, could you all add in a way to the engine that allows users to say "Only run widgets with a minimum version of 4.x or higher?" From a security standpoint, if a version of the engine has better security features that only widgets with a certain min version could take advantage of, then maybe users would only want to run those widgets.

[Ed Voas]

Yes, we are checking uses of eval(). Heck, one of us here wants to disable eval entirely.

I'll pass the idea of restricting Widgets by minimumVersion along.

[Drevor]

Yes, we are checking uses of eval(). Heck, one of us here wants to disable eval entirely.

I'll pass the idea of restricting Widgets by minimumVersion along.

When you do that make sure to kill the Function and your Script objects too. They are just as dangerous.

//edit

The minimum version idea. Maybe you could improve the security dialog by displaying more meta information (description, website, copyright, ...) and a notice whenever a widget was created for a lower major version that the user is currently running.

[Sarah]

Yes, we are checking uses of eval(). Heck, one of us here wants to disable eval entirely.

I'll pass the idea of restricting Widgets by minimumVersion along.

Cool, thanks. I'm all for disabling eval entirely. In fact, I thought it was forbidden until I added an 'eval' to a widget and watched stuff happen.

[jokabomo]

Yes, we are checking uses of eval(). Heck, one of us here wants to disable eval entirely.

I use eval() in one of my widgets and would be like it to remain. No sense in punishing everyone for the (possible) actions of a few.

I would suggest allowing users to set permissions on a per widget basis. When a widget first runs, ask, "Do you trust this widget?" If the user answers "yes" the widget runs with full permissions. If "no", then no eval(), strings in actions, and maybe even no filesystem functions except within the widget's data folder. You get the idea.

I believe this would shift liability from Y! to the user. Which is pretty much what this whole thread is about, right?

[BOINCer]

"If eval() is the answer, you're almost certainly asking the wrong question." -- Rasmus Lerdorf, BDFL of PHP

[g6auc]

Before deciding to ban system and language features at random, it would be a very good idea to have a security policy.

When it is clear what we are trying to do, it might just be possible to figure out how to do it.

[PBRILL2499]

As a widget developer, I have some questions to help me clarify some things. What exactly will happen if we cannot fix our Widget(s) by the 16th? What sort of behavior will the end user experience? Will they still be able to execute the widget without any access to content (i.e. will they still be able to view the About... dialog)? Will they be provided with a new warning dialog? Will they be provided with instructions on how to get more detailed information about the security hole? Lastly will the widget stop working for me (the author); if so then how can I make it work for me again (so that I can continue to work on it)?

Regards,

[wrlee]

I dont know what to do now. I submitted a support comment stating that my (NPR Addict) widget does not violate the issues of concern. That was over a week ago! I am getting ready to leave for vacation tormorrow and I wont be able to tend to issues during the Aug 16th cutoff. What else can I do?!!

And my widget is still featured in the list of widgets! It just cannot be downloaded.

Bill...