Coffeehouse Thread

33 posts

Has Microsoft opened a can of worms?

Back to Forum: Coffeehouse
  • wastingtime​withforums

    SL4 warning

     

    Silverlight 4's warning message for applications that run "out of browser". This OOB apps have basically full access to the system, since they can access COM+:

     

     

    http://justinangel.net/CuttingEdgeSilverlight4ComFeatures

     

     Write to C: using silverlight:

     

     

    Feature #1: Write files anywhere on the local machineUsing the FileSystemObject
    we have virtually unlimited access to the user’s file storage. 
    
    <Button x:Name="btnWriteFile" Content="Write file to C:\test.txt"
    Click="btnWriteFile_Click" />
    private void btnWriteFile_Click(object sender, RoutedEventArgs e)
    {
        using(dynamic fsoCom = 
    ComAutomationFactory.CreateObject("Scripting.FileSystemObject"))
        {
            dynamic file = fsoCom.CreateTextFile(@"c:\test.txt", true);
            file.WriteLine("Bloody Hell!");
            file.WriteLine("Silverlight is writing to C:\\");
            file.Close();
        }
    }
     
    

     

    Fun!

     

    And the fun doesn't stop here:

     

     

    <Button x:Name="btnAddOOBAppToStartup" 
    Content="Add out-of-browser application to Startup" 
    Click="btnAddOOBAppToStartup_Click" />
    private void btnAddOOBAppToStartup_Click(object sender, RoutedEventArgs e)
    {
        using (dynamic ShellApplication = 
    ComAutomationFactory.CreateObject("Shell.Application"))
        {
            dynamic commonPrograms = ShellApplication.NameSpace(11);
            string allUsersPath = commonPrograms.Self.Path;
     
            dynamic directory = ShellApplication.NameSpace(allUsersPath + @"\Programs");
            dynamic link = 
    directory.ParseName(Deployment.Current.OutOfBrowserSettings.ShortName + ".lnk");
            string OOBLink = link.Path;
     
            using (dynamic WShell = ComAutomationFactory.CreateObject("WScript.Shell"))
            {
               WShell.RegWrite(@"HKLM\Software\Microsoft\Windows\CurrentVersion\Run\"
                                            +
     Deployment.Current.OutOfBrowserSettings.ShortName,
                                            OOBLink);
                MessageBox.Show
    ("Please restart your machine and this application will load on startup.");
            }
        }
    }
    

     

    What's stopping someone from writing malicious silverlight applications now? The only barrier seems to be this toothless security warning, just a single click on "install", and your system can be rooted.

     

    Yes, it has a warning, but activeX controls had warnings too. No one reads them. People don't read, so make the security risk obvious:

     

    Microsoft should have made the security warning dialog much bigger, in RED, with a BIG exclaimation mark, and an even bigger warning shield (like the current one, just make it ten times bigger) and a loud flashing sound. And an additional checkmark box, that you have to tick, to activate the install button. (maybe two checkboxes, one for "I agree to install this", and another "I am aware of the security risks" . Then, maybe, this would be secure.

     

     

    As it stands now, it doesn't cut it.

  • turrican

    Unless you are missing something here, I can not disagree with you. What you just described actually creeps me out. Is Microsoft doing the same mistakes again regarding security?

     

    So odd.

  • contextfree

    How much worse is it than just being able to download and run executables/MSI installers from the web?

  • ManipUni

    Silverlight Warning Box

     

    This is what happens when an unverified remote host tries to install it. I would test a verified one (non-localhost) but I don't have a certificate kicking around that I can screenshot here.

  • wastingtime​withforums

    ManipUni said:

    Silverlight Warning Box

     

    This is what happens when an unverified remote host tries to install it. I would test a verified one (non-localhost) but I don't have a certificate kicking around that I can screenshot here.

    I guess with signed apps you get a standard UAC warning?

     

    Anyway, there were tons of malicious active x controls with valid signatures:

     

     

     

    So the SL4 warning should be scary, even for signed apps.

  • W3bbo

    wastingtimewithforums said:
    ManipUni said:
    *snip*

    I guess with signed apps you get a standard UAC warning?

     

    Anyway, there were tons of malicious active x controls with valid signatures:

     

     

     

    So the SL4 warning should be scary, even for signed apps.

    You get the same window, but without the "Stranger danger" messages and a message explaining why signed applications are somehow better than unsigned applications.

     

    ...because signed applications can always be trusted.

  • wastingtime​withforums

    contextfree said:

    How much worse is it than just being able to download and run executables/MSI installers from the web?

    "

    How much worse is it than just being able to download and run executables/MSI installers from the web?"

     

    So activeX was never a problem?

  • felix9

    i dont think that's the correct warning dialog, since only 'trusted' oob applications can access COM and you do have a 'trust it' checkbox to check before you can install it.

     

  • Minh

    Does it really work?

     

    I thought OOB Silverlight apps run under the browser restrictions... You can grant it full trust but that's another step...

     

    I couldn't test it cuz I got this dialog:

     

    Microsoft Silverlight

     

    This application was created for an expired beta release of Silverlight. Please contact the owner of this application and have them upgrade their application using an official release of Silverlight.

     

    [  OK  ]

     

  • soum

    I don't think it can be compared to the IE/ActiveX scenario. IIRC, SL4 OOB apps can only instantiate already installed COM objects, not install new ones, unlike IE. Around the time SL4 was first unveiled, a C9 video discussed this (sorry, don't remember which one though).

  • ManipUni

    soum said:

    I don't think it can be compared to the IE/ActiveX scenario. IIRC, SL4 OOB apps can only instantiate already installed COM objects, not install new ones, unlike IE. Around the time SL4 was first unveiled, a C9 video discussed this (sorry, don't remember which one though).

    They can do whatever they want. But they're designed to run at that privileged level so that isn't a surprise.

     

    Minh update the Manifest to RuntimeVersion="4.0.50401.0"

  • Ian2

    Maybe if we all write to our EU MPs we can get these Microsoft hooligans under control?

  • CSMR

    I'm glad that installers won't be able to put shortcuts on the desktop without the user's permission.

  • GoddersUK

    Ian2 said:

    Maybe if we all write to our EU MPs we can get these Microsoft hooligans under control?

    Given the average politicans track record on technology if you tried that you'd probably end up with the EU requiring an Apple-esque app store and approval policy as the only way to add programs to Windows.

     

    Think of the children, think of the children!

  • ZippyV

    If the app tries to write something to C:\ or change anything in the HKEY_LOCAL_MACHINE we should get a UAC prompt right?

  • Sven Groot

    ZippyV said:

    If the app tries to write something to C:\ or change anything in the HKEY_LOCAL_MACHINE we should get a UAC prompt right?

    No, it should fail. UAC doesn't work like that.

  • turrican

    ManipUni said:
    soum said:
    *snip*

    They can do whatever they want. But they're designed to run at that privileged level so that isn't a surprise.

     

    Minh update the Manifest to RuntimeVersion="4.0.50401.0"

    Hm, interesting. I didn't know that. Could you explain why it would fail? It is pretty good if it fails because users might still hit "OK" for the UAC.

  • Sven Groot

    turrican said:
    ManipUni said:
    *snip*

    Hm, interesting. I didn't know that. Could you explain why it would fail? It is pretty good if it fails because users might still hit "OK" for the UAC.

    UAC can only elevate a process when that process is started. If a non-elevated process wants to do something that requires elevated privileges, it must explicitly start another process that will be elevated. You can't just elevate in place.

     

    Doing something that requires additional access rights isn't going to magically throw up a UAC prompt. You have to modify your application to support that.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.