[wix-devs] #5658 - Burn problem with AV

[Sean Hall]

I sent a pull request to v4 <https://github.com/wixtoolset/wix4/pull/262>
and v3 <https://github.com/wixtoolset/wix3/pull/477>. I tested it with a
Win10 Azure VM and Avast (free edition). I ended up going with
E_SUSPECTED_AV_INTERFERENCE, but happy to switch back to MEDDLING.

Blair, there is no timeout involved here, at least with Avast. The AV ends
up killing the original process before the unelevated process gets to any
timeout when it completes it scan.

On Mon, Dec 17, 2018 at 9:36 PM Blair Murri via wix-devs <
wix-devs at lists.wixtoolset.org> wrote:

> I'm not a big fan of custom error codes, but I don't care enough to say no
> to this one, either.
>
> I don't have any boxes with the AV's mentioned, nor do I have enough free
> disk space to spin a new VM up for testing purposes. I'm willing to code up
> what Sean is describing, but I'll just be throwing it over the fence.
>
> My only remaining question is: what should the timeout value be (to give
> the human user time to respond to the AV and for the AV to then disengage
> it's suppression of communication). Off the top of my head I'd recommend 30
> seconds, but I'm not a UX expert.
>
> Thoughts?
>
> Get Outlook for Android<https://aka.ms/ghei36>
>
> ________________________________
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> on behalf of Bob
> Arnson via wix-devs <wix-devs at lists.wixtoolset.org>
> Sent: Monday, December 17, 2018 7:29:25 PM
> To: WiX Toolset Developer Mailing List
> Cc: Bob Arnson
> Subject: Re: [wix-devs] #5658 - Burn problem with AV
>
> I have no context, haven't reviewed the issue/PR, etc., but I
> wholeheartedly endorse E_SUSPECTED_AV_MEDDLING solely for its name.
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean
> Hall via wix-devs
> Sent: Monday, 17 December, 2018 10:14
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Sean Hall <r.sean.hall at gmail.com>
> Subject: Re: [wix-devs] #5658 - Burn problem with AV
>
> So it sounds like we want to try adding a retry first and see how it goes?
>
> The pull request right now is calling itself before cleaning up, which is
> bad. My current idea is to make that elevate function return a custom error
> code, something like E_SUSPECTED_AV_MEDDLING. Then make Apply auto retry
> once.
>
> On Mon, Dec 17, 2018 at 1:36 AM Blair Murri <osito at live.com> wrote:
>
> > I think the point was that the AVs are blocking the second hop while
> > asking the user how to proceed. Once the user responds granting
> > access, the code with the retry logic works, if I'm reading the
> > responses to the issue correctly.
> >
> > We've never released any version containing the retry logic. We
> > haven't added the retry logic to any branch. No one has even critiqued
> > pull request containing the proposed retry logic (which includes me,
> > as it's not clear to me that the proposed solution is optimal, but I
> > truly haven't stopped to think about it, either).
> >
> > I don't think disabling the clean room is the right solution, unless
> > someone with something based on the proposed solution isn't working or
> > a good argument is made that the user can't work with an AV's dialog
> > asking to allow a program they launched to proceed.
> >
> > Get Outlook for Android <https://aka.ms/ghei36>
> >
> > ------------------------------
> > *From:* wix-devs <wix-devs-bounces at lists.wixtoolset.org> on behalf of
> > Sean Hall via wix-devs <wix-devs at lists.wixtoolset.org>
> > *Sent:* Thursday, December 13, 2018 10:28:08 AM
> > *To:* WiX Toolset Developer Mailing List
> > *Cc:* Sean Hall
> > *Subject:* Re: [wix-devs] #5658 - Burn problem with AV
> >
> > The whole thing - because one person said their bundle built with v3.9
> > worked fine, and another implying that the issues started when using
> v3.11.
> > It's possible the companies are allowing one hop
> > (unelevated->elevated) but not two (unelevated->clean room->elevated).
> >
> > On Thu, Dec 13, 2018 at 12:20 PM Rob Mensching <rob at firegiant.com>
> wrote:
> >
> > > The initial report in that issue is about the elevated Burn not
> > > about the clean room. What part of the issue would be helped by not
> > > doing clean
> > room?
> > >
> > > -----Original Message-----
> > > From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of
> > > Sean Hall via wix-devs
> > > Sent: Sunday, December 9, 2018 3:02 PM
> > > To: WiX Toolset Developer Mailing List
> > > <wix-devs at lists.wixtoolset.org>
> > > Cc: Sean Hall <r.sean.hall at gmail.com>
> > > Subject: [wix-devs] #5658 - Burn problem with AV
> > >
> > > For https://github.com/wixtoolset/issues/issues/5658, I'm not
> > > convinced that we are going to be able to find a foolproof
> > > workaround for these problematic AV's. Would it be acceptable to add
> > > a /disablecleanroom
> > switch,
> > > disable clean room if running in a specially name folder, or
> > > something
> > else
> > > like that instead? I would think that would be ok security-wise
> > > since if
> > a
> > > malicious entity can run our bundle with that switch they already
> > > have
> > code
> > > execution.
> > >
> > > Also, have we submitted the latest v3.11 to each of the vendors in
> > > the issue - Avast, AVG, PC Matic SuperShield?
> > > ____________________________________________________________________
> > > WiX Toolset Developer Mailing List provided by FireGiant
> > > http://www.firegiant.com/
> > >
> > ____________________________________________________________________
> > WiX Toolset Developer Mailing List provided by FireGiant
> > http://www.firegiant.com/
> >
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>