Embedded IE crashes Papercut

[changemakerstudios]

Embedded IE crashes Papercut

[jimbobmcgee]

I see the same if I run Papercut with IE Enhanced Security enabled (which it is by default on Windows Server).

@Jaben...
I think this might be fixable (or at least recoverable) by adding a try/catch around the call to htmlView.Source in the MessageDetailHtmlViewModel.OnViewLoaded method (approx line 144):

this.GetPropertyValues(p => p.HtmlFile)
    .Subscribe(file =>
    {
        try { typedView.htmlView.Source = new Uri(string.IsNullOrWhiteSpace(file) ? "about:blank" : file); }
        catch { /* Do something here to inform user of Trusted Sites requirement */ }
    });

You might also be able to change which address requires trusting by altering your MarkOfTheWeb string in the UIStrings.resx file. I haven't tried this explicitly, but the following might limit the trust scope, instead of requiring about:internet (which 'feels' too expansive for a 'trusted' zone):

<!-- saved from url=(0018)about:papercut_exe -->

Alternatively, setting it to the localhost string might coerce it to Local Intranet, instead of Trusted Sites, which might relax the requirement (although might be more dangerous, strictly speaking):

<!-- saved from url=(0016)http://localhost -->

Hope this helps...

Edit 1: can confirm setting the mark of the web string to something application-specific does do what I would expect on an IE Enhanced Security install (at least, in a hand-rolled HTML page). I haven't tried in a WebBrowser control, yet...

Edit 2: can confirm that find/replacing the about:internet string to about:papercut in the compiled Papercut.exe binary was sufficient to change the error message received (internet and papercut have the same length, so the executable is still valid). Patched executable still crashes on startup (if the default-selected mail file is HTML-based), but adding about:papercut to IE Trusted Sites resolves this. I would say using about:papercut and documenting the Trusted Sites requirement has fewer security implications that perceivably trusting any file that IE has saved locally (which about:internet may do).

[Jaben]

@jimbobmcgee Thanks for this research. I've been at a bit of a loss as to the best path for a fix for this issue. I'll look into integrating these suggestions in the next release.

[jimbobmcgee]

@Jaben - You're welcome.

I don't know if it is the best path, per se; I was never able to make the WebBrowser control crash in a quick sample app, even if I used a MOTW to define a 'zone' that wasn't trusted, regardless of whether I had a try/catch around setting the WebBrowser.Source, so my first suggestion of adding try/catch to the OnViewLoaded method might be a red-herring.

The second idea is really more around limiting the scope of the trust that has to be added to work around the functional issue. Adding about:internet to Trusted Sites has wider-reaching issues, that may serve to negate the security boundary that Trusted Sites is supposed to provide. It is probably better that mail content read by Papercut isn't trusted by default, just in case someone might be relaying real internet mail through it (although that assumes a use-case outside of Papercut's intent).

I can't build Papercut at the moment because of dependency issues on my dev machine, but if you can hook AppDomain.CurrentDomain.UnhandledException or AppDomain.CurrentDomain.FirstChanceException (very early on in the app startup) to log the full exception, inner exception chain and stack trace, in an interim/debug build, that might give us a better chance of finding the real bug.

In the meantime, a dedicated scope for trust (e.g. the about:papercut MOTW) and a documentation note regarding trusting that scope on servers with IE Enhanced Security mode enabled will probably suffice.

[stale]

Aloha! I'm ScissorBot ✂️ -- the bot in charge of keeping the issues tidy. It looks like this issue is stale due to lack of activity. Unfortunately, I'll be closing it if there is no further activity. 😞 Please contribute to the issue to keep it open. Thanks!