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

[Sean Hall]

Sorry, I guess I wasn't clear. What I meant was that instead
of ElevationElevate retrying itself, that whatever code in Apply that is
calling ElevationElevate would get a custom error code and then
retry ElevationElevate. I didn't mean loop the whole Apply.

On Mon, Dec 17, 2018 at 11:08 AM Blair Murri <osito at live.com> wrote:

> As I understand it, retrying the entire Apply would just repeat the same
> failure mode over and over again.
>
> The problem is that by the time the third process is launched, the AV is
> sandboxing. What needs to be retried is establishing communication, and
> that needs to be repeated until the user has had sufficient opportunity to
> manually respond to the AV's dialog.
>
> 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:* Monday, December 17, 2018 7:13:54 AM
> *To:* WiX Toolset Developer Mailing List
> *Cc:* Sean Hall
> *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/
>