locked
Patch Tuesday breaks Out of browser NavigateUri and PopupWindow RRS feed

  • Question

  • Several Users have installed our application out of browser. In the application there are various links that will download a file or open another browser window.  To do this we use HtmlPage.PopupWindow() and HyperlinkButton.NavigateUri().  All has worked well for many years.

    On Patch Tuesday, May 12, 2015, things stopped working.  When a link is clicked to download a file HyperlinkButton.NavigateUri() does nothing and HtmlPage.IsPopupWindowAllowed() returns false.

    When running the application in a browser all is well.  This issue only happens when running out of browser.

    I believe it has something to do with one or more of the following:
    - The release of Silverlight 5.1.40416.0
    - The release of KB3049563
    - The release of KB3023215

    Anyone else having similar issues?  Is there a fix?
    Thursday, May 14, 2015 12:16 AM

Answers

  • Thanks for reporting this issue. As a workaround, I suggest that you rebuild your appllcation as an elevated Out of Browser app. (In VS, open project properties, Silverlight tab > "Out of Browser Settings..." >  "Require elevated trust when running outside the browser". This should get NavigateUri to work again.

    One of the security fixes in Silverlight 5.1.40416.0 is to have normal unelevated OOB apps run as low-integrity processes in Windows (KB3058985). Some features may be broken because of this.

    • Marked as answer by Tim H. _ Friday, May 29, 2015 7:27 PM
    Friday, May 22, 2015 8:54 PM

All replies

  • I have a similar problem; The program starts but does not show a video when it is called; I know the video is installed but it will not play
    Thursday, May 14, 2015 10:53 PM
  • We are seeing the same issue in our Silverlight Out of Browser application. Are there any security settings we can change to enable this to work again?
    Friday, May 15, 2015 2:47 PM
  • Our Silverlight OOB app was also working fine for 3 years (win7 and 8) until the patches; it accesses user/appdata folder to store data; now it can't get to the data ( a video ) on Win 7 ; it just comes up blank;

    I tried doing a restore to an earlier restore point before the recent patches and that is broken also. 

    User in the middle of doing major research project with kids using app isn't happy

    Saturday, May 16, 2015 11:17 AM
  • @Chet01 - Yes that was my experience with the restore points.  

    On one machine I installed 
    - The release of Silverlight 5.1.40416.0
    - The release of KB3049563
    - The release of KB3023215

    I then rolled back and only installed Silverlight 5.1.40416.0 and the links did not work

    On another machine I only installed the Silverlight 5.1.40416.0 and all works fine still.  

    It would appear that KB3049563 and/or KB3023215 cannot be restored back for some reason.

    /*Update*/  On the machine where I only installed Silverlight 5.1.40416.0, it was the Silverlight Developer runtime and I am running as admin on the machine so perhaps that is why it works.


    Tim H




    • Edited by Tim H. _ Wednesday, May 27, 2015 6:55 PM
    Monday, May 18, 2015 3:59 PM
  • Having the same issue as well.
    Tuesday, May 19, 2015 1:14 AM
  • Amazingly OOB app does work on my Windows Server 2008 R2 box with all patches applied. I copied all IE browser and security settings to the Windows 7 box but this did not work.

    On the Windows 7 boxes when I try to uninstall KB3049563 , the pc hangs after uninstall and restarting

    Tuesday, May 19, 2015 5:13 PM
  • I also have an out of browser app that has been working for years using a Hyperlink button under a menu item to open a new browser window and pass Sign On credentials to that site.  Now clicking the menu item triggers no response from the application and no window is opened.

    I am not certain that the patch has been applied to my PC but the behavior is the same.

    Wednesday, May 20, 2015 11:02 PM
  • Exactly the same issue here, hyperlinks not working from OOB since last week. This is affecting increasing numbers of our customers as they apply patches, and it renders our application useless. This is a massive issue for us, we are investigating further to isolate but we can't tell customers not to patch their machines. I will report if we find any work around but I wanted to add my extremely angry and frustrated voice to this thread.

    Danny

    Thursday, May 21, 2015 9:14 AM
  • We have the same problem... After Silverlight update (5.1.40416.0) the HyperlinkButton doesn't work in OOB...

    Thursday, May 21, 2015 1:39 PM
  • We have the same issue with HyperLinkButton in OOB application. We have 300 users affected. We need a solution, because at this time the application is not useful.
    Thursday, May 21, 2015 1:41 PM
  • We have the same issue: links to external URLs failed to load when you execute SL app on OOB. Everything started since Tuesday, May 14.
    We first notice this issue when a user that already had that app in OOB, changed it's default browser using Windows options (Default Programs). Once changed, user was unable to navigate to external URL.

    Is there any official response from MS??

    Thursday, May 21, 2015 1:46 PM
  • Hi guys!

    Same issue here. Production OOB app started failing to open/navigate to URLs. Seems that all HyperLinkButtons are failing.

    In our case we have similar SL version as @Tim H. For the moment only some users are reporting issues, but we supose that will be receive more complaints as soon as user machines get updated!

    Thursday, May 21, 2015 1:55 PM
  • I confirmed that I do have the latest update installed.  Was it Vulnerability in Silverlight Could Allow Elevation of Privilege (3058985) that caused this change?
    Thursday, May 21, 2015 2:04 PM
  • Which out of these 3 cause the problem? I suppose Silverlight 5.1.40416.0
    Thursday, May 21, 2015 8:12 PM
  • it seems we are the first one reporting it, until now no other information to be found in internet about this issue :-(
    Thursday, May 21, 2015 8:14 PM
  • @dozunu - If you have updated just Silverlight 5.1.40416.0 then you should be OK.   I have several machines where this is the only thing I updated.  The issue happens when you install KB3049563 and/or KB3023215.  Once installed there is no going back.   Uninstalling the update does not correct it.  

    Tim H

    Thursday, May 21, 2015 10:08 PM
  • @David J Cohen - I didn't install KB3058985.  I go the issue after I installed KB3049563 and  KB3023215.  Did you you install either one of these?  If not, that could mean that KB3058985 can cause it as well.

    Tim H

    Thursday, May 21, 2015 10:19 PM
  • Thanks, I'm trying to figure out which patch(es) cause(es) the problem to be able to communicate this to end user and try to block in IT the patch(es).

    Some feedback from Microsoft? Some workaround?

    Friday, May 22, 2015 7:28 AM
  • For the moment, the only workaround seems to be working without OOB... :-(
    • Proposed as answer by dozunu Friday, May 22, 2015 8:41 AM
    • Unproposed as answer by Tim H. _ Friday, May 22, 2015 2:52 PM
    Friday, May 22, 2015 7:42 AM
  • @DavidJuan - Yes that is what we have been telling our users. This is all very frustrating because a few weeks ago we had been encouraging customers to go out of Browser when Chrome stopped allowing Silverlight by default.  Now we have been basically saying:

    If Chrome is your favorite browser you can still keep it as your favorite browser but create a shortcut to the application by:

    - Open IE and enter the URL to the application
    - Drag the URL icon from IE down to the Windows Task Bar.  A tool top appears that says "Pin to Task Bar"
    - Drop the URL icon ontop the task bar
    - Now whenever you wish to launch the application, click the pinned task bar icon and the application will open in IE


    Tim H



    • Edited by Tim H. _ Wednesday, May 27, 2015 11:22 PM
    Friday, May 22, 2015 3:05 PM
  • Thanks for reporting this issue. As a workaround, I suggest that you rebuild your appllcation as an elevated Out of Browser app. (In VS, open project properties, Silverlight tab > "Out of Browser Settings..." >  "Require elevated trust when running outside the browser". This should get NavigateUri to work again.

    One of the security fixes in Silverlight 5.1.40416.0 is to have normal unelevated OOB apps run as low-integrity processes in Windows (KB3058985). Some features may be broken because of this.

    • Marked as answer by Tim H. _ Friday, May 29, 2015 7:27 PM
    Friday, May 22, 2015 8:54 PM
  • Thanks for reporting this issue. As a workaround, I suggest that you rebuild your appllcation as an elevated Out of Browser app. (In VS, open project properties, Silverlight tab > "Out of Browser Settings..." >  "Require elevated trust when running outside the browser". This should get NavigateUri to work again.

    One of the security fixes in Silverlight 5.1.40416.0 is to have normal unelevated OOB apps run as low-integrity processes in Windows (KB3058985). Some features may be broken because of this.

    Greg, thanks for your input.

    The workaround works, but we are going to have a major issue persuading customers to install a full trust version. Our app is installed on trader's desktops, full trust means access to users files, they will not allow it.

    Based on your knowledge of the issue, would you anticipate that a full fix will be released in due course, or does this effectively mean the end of Silverlight OOB apps without elevated trust?

    Regards

    Danny


    Saturday, May 23, 2015 9:43 AM
  • no fix for OOB apps? this will kill suddenly all SL apps running OOB
    Monday, May 25, 2015 12:15 PM
  • This was an intentional security fix.  From my Microsoft rep on a service ticket:

    HI David,

    I tried calling you but you could not be reached on phone. It seems the security update has changed ‘EnableNavigation’ property to ‘none’ from ‘all ‘ (previously default). There is no way to updated this property via managed code as per MSDN.

    Reference:

    https://msdn.microsoft.com/en-us/library/system.windows.controls.hyperlinkbutton%28v=vs.95%29.aspx

    https://msdn.microsoft.com/en-us/library/dd833071%28v=vs.95%29.aspx

    I have requested Silverlight team on the details of  changes they had made in this update based  upon this incident. It may take 2-3 days before I get an update from the Silverlight team.

    Meanwhile I also got a comment that if we make this application a trusted application, this issue might get resolved. You could verify this by creating self-signed certificates and adding the Certification Authority to Trusted Root in your development computer.

    I will update once I get more information from the Silverlight team. Please  let me know if you need any more help related to this incident in meantime.

    Regards,

    Deepu--

    It would appear that the only way we are going to get this to function properly is by signing our apps.

    Tuesday, May 26, 2015 4:05 PM
  • Danny,

    I am afraid this isn't broken from their perspective.  This was changed intentionally.

    Tuesday, May 26, 2015 4:14 PM
  • Thanks for reporting this issue. As a workaround, I suggest that you rebuild your appllcation as an elevated Out of Browser app. (In VS, open project properties, Silverlight tab > "Out of Browser Settings..." >  "Require elevated trust when running outside the browser". This should get NavigateUri to work again.

    One of the security fixes in Silverlight 5.1.40416.0 is to have normal unelevated OOB apps run as low-integrity processes in Windows (KB3058985). Some features may be broken because of this.

     @Greg - Thanks for this.  I can confirm this works.  I also signed my xap with my Code Signing certificate from Go Daddy.

    I have always avoided this setting for years for concern that if I set the "Require elevated trust..", most of my users would not be able to install the application if they were not administrators.  From what I can tell by testing several of my low level accounts is that the only differences will be:
    - The install dialog is different (ie. more scary)
    - Most users will be able to install. 
    - Users will not be able to install if there are "Policy Restrictions for Elevated Trust"

    This link proved useful: https://msdn.microsoft.com/en-us/library/ee721083(v=vs.95).aspx



    Tim H


    • Edited by Tim H. _ Wednesday, May 27, 2015 6:45 PM
    Wednesday, May 27, 2015 6:43 PM
  • @dozunu - See my reply I just did on Greg's post above.  Checking the box to require elevated trust and code signing the xap solves the issue for most users.


    Tim H

    Wednesday, May 27, 2015 6:52 PM
  • Hi

    please try uninstalling the ms silver light from ur pc if using a Google chrome which is the latests one either 42 or above as u may not need it.

    see this page FOund while googleing

    hope this helps

    as i am now able to use paypal sign in page in google chrome with out a opps error message.

    Thursday, May 28, 2015 5:07 PM
  • Hi

    please try uninstalling the ms silver light from ur pc if using a Google chrome which is the latests one either 42 or above as u may not need it.

    see this page FOund while googleing

    hope this helps

    as i am now able to use paypal sign in page in google chrome with out a opps error message.

    That is a different issue.  See this post.  That refers to Chrome no longer allowing Silverlight to run in the browser.  This thread has to do with the ability to open URLs or popup windows when running out of browser.

    Tim H


    • Edited by Tim H. _ Friday, May 29, 2015 7:29 PM
    Friday, May 29, 2015 7:26 PM
  • Danny,

    I am afraid this isn't broken from their perspective.  This was changed intentionally.

    I don't yet accept that interpretation. As I understand it, some security vulnerabilities had to be addressed requiring the Silverlight app to run at a lower level. The result included the loss of the ability to open a new browser window - that is not the same as intentionally removing that ability. 

    It is a very basic and low risk action to have a link in the silverlight OOB app that opens say a help page in a web browser. That is not the same level of risk as being able to read and write to the user's file system, and yet the solution being proposed (elevated trust) would allow the app to do exactly that. So in order to open a web page, I have to ask my customers to trust my application to a much greater level. That is not an acceptable solution. It means more applications are going to have to request full trust for simple things, opening up much greater security risks than being allowed to open a browser when the user clicks a link.

    Furthermore, if the action of clicking a link is acceptable from a non-OOB app, I don't see why it is considered a greater risk from an OOB app. 

    For these reasons David I do not yet accept that this was changed intentionally.

    I would like to hear from Microsoft a definitive statement as to whether the browser launching facility was removed intentionally, or this was an accidental consequence of a rapidly deployed security fix that will very quickly be resolved. I do not want to invest in moving off the Silverlight platform only to find out in 3 weeks that it has been fixed.

    One more point. If you are deploying your application to professional financial services desktops, elevated permission deployments will be blocked, whether signed or not. And rightly so.

    Saturday, May 30, 2015 7:48 AM
  • DannyAxius 

    If Silverlight in browser can open new windows so should OOB version. That, however probably requires a Silverlight 5x hotfix.

    They found a vulnerability so they hit the plug hard and made a breaking change to all SL OOB applications.

    Since OOB apps rely on that functionality and opening new windows is such a core function of any reasonable Silverlight APP I think we should fight (if we have to) for the fix for this.

    Asking elevated trust can work as a bad workaround in some cases, but it's not an acceptable solution from any reasonable perspective except that it doesn't require any work for the MS Silverlight support team.

    Maybe they should do a better hotfix for windows which would block the vulnerability itself, not the entire range of functions which included that vulnerability.

    An official word from MS could be very nice. Their attitude towards Silverlight developers is pretty awful and frankly, after investing in Silverlight a lot of time, money and effort and seeing how they treat me, I feel that if I ever have any choice in future I'd be rarely making a choice in favor of MS technology stacks.



    • Edited by ValentinKu Saturday, May 30, 2015 11:23 PM
    Saturday, May 30, 2015 11:21 PM
  • This does not work for my clients, either.  For years they have been installing the application without any elevated privileges. In an enterprise environment, installing a trusted application requires elevated privileges.  Many of my clients work in enterprise environments with limited workstation privileges.  In order to install a trusted application, it would require IT staff, extra expenses, etc.

    This security fix is a bust.  It should not be necessary to have a trusted application in order to open a new browser window. For example, in windows, users can open a browser window from a desktop shortcut with the most basic desktop privileges. They can add desktop icons with web site URLs at will. No elevated privileges needed.

    As a developer community we are simply asking for consistency across the platform.  We are simply asking that a feature that has worked for 10 years on a platform continue to be supported.  This is impacting us, our business models, and our clients.  It should be addressed and fixed.  No more excuses about "this is an intentional security fix."

    Thank you.

     
    Wednesday, June 3, 2015 4:42 PM
  • totally agree with M Snuffer!!! Same situation for me!
    Wednesday, June 3, 2015 7:50 PM
  • I totally agree with M Snuffer. We are in the same situation.
    Thursday, June 4, 2015 10:17 AM
  • It would appear that I was making an assumption Danny,

    I received word on the ticket I opened that they have indeed identified this as a bug and may plan a fix for the next release, but there is no short term hotfix planned.  So it would seem they did not do this intentionally.  Too late for me.  I have to get my users working so I have procured a cert and set our app to elevated trust.

    As you describe, this will cause plenty of headaches for users with limited access to install software.

    Just for the record I wasn't making excuses for Microsoft.  I was just under the impression that they had done this intentionally and we weren't going to get any help.  I completely agree with you and M Snuffer.


    Wednesday, June 10, 2015 3:41 PM
  • Thanks for the update David.

    That's good news. I wonder if you could point me at where this bug / ticket is recorded, and who we might contact to follow up perhaps via a support incident etc? I really want to be able to refer to this bug/ticket in correspondence with MS to put pressure on them to resolve this quickly.

    I cannot stress strongly enough that this bug is about to put us out of business.

    Many thanks

    Danny.

    Sunday, June 14, 2015 8:58 AM
  • so they do a change that forces authors to serve their apps as full-trust ones and thus may cause more damage

    Microsoft MVP J# 2004-2010, Borland Spirit of Delphi 2001

    Sunday, June 14, 2015 5:23 PM
  • can you please point us to this bug / ticket such that we can express our concern also there? my LOB app with SL OOB makes a lot of waves inside my company and they already start thinking moving away from SL in the near future. But what do we do until the new front end will be ready? the app is unusuable ...
    Monday, June 15, 2015 12:57 PM
  • My case number was 115052112759135.  I have asked but I was not yet told a bug/ticket that the silverlight team is working on.

    "Subject:RE: [REG:115052112759135] PRO\Silverlight for Windows AL\Hyperlink button control no longer navigate URI after Silverlight 5.1 was installed

    Hi David,

    I got update from Silverlight team confirming this to be a bug . They may provide a resolution for this in next release ,but there won’t be any hot fix for this.

    Do you need any additional information on this incident?.

    Please let me know if this case can be closed."

    Tuesday, June 16, 2015 2:31 PM
  • I appreciate your help David. I'd be grateful if you would post any update so I and others can continue to chase this.

    Best Regards

    Danny


    Wednesday, June 17, 2015 3:58 PM
  • Hi David,

    Thank-you for this, please also let me know if you get any news or I can help chase. This is a significant problem for us, the hyperlink button is a fairly basic control and has to work.

    Tuesday, July 14, 2015 1:32 PM
  • Greg.

    There has now been a further release of Silverlight 5.1.40728.0 however this STILL DOES NOT FIX THIS BUG!

    Microsoft found time in this release to include "Make Bing your favourite Search Engine" options in the installer, but not to address this breaking change.

    Please can someone who has Microsoft's ear make them aware of this issue, since it obviously hasn't been properly reported.

    Once again - elevated privileges are not an option in many corporate environments, since this would give full access to user file system. Opening a browser window from a Silverlight OOB should not require elevated privilege. Please restore this long standing functionality. It was not removed due to a security risk, it was removed accidentally. 

    Danny.

     

    Saturday, August 29, 2015 5:31 PM
  • So typical of Microsoft.   I have to uncheck the Bing box every time I have to install it on one of our users computers.  It is the most worthless search engine that I have ever used.  Also, even though I install the Silverlight, the install Silverlight message still pops up on the bottom of the display.  Very annoying and the users call about that too.
    Tuesday, September 15, 2015 2:19 PM
  • Does anyone know if this has been fixed in latest Silverlight release; doesn't look like it for me.

    Thanks

    Monday, December 14, 2015 6:58 PM