Livebook quarantined/removed by Window Defender

[dpreston]

Just a quick warning that Defender has started quarantining the LivebookLauncher.exe executable as of Oct 18.
It matches as Backdoor:Win32/Bladabindi!ml and advises that it provides remote access.

Not sure if you have anyway of getting this flagged/re-categorized.

[jonatanklosko]

Hey, thanks for the heads up! There's probably not much we can do, as in #1324 (comment).

cc @wojtekmach

[wojtekmach]

thank you!

Would it help if we compiled the launcher with c# (csc.exe) or it would be basically the same situation?

We have actually started with a .vbs script and converted to an .exe because, ironically, the security dialog was less scary, it talked about LivebookLauncher.exe as opposed to win32host.exe (or however the vbs interpreter was called) which seemed less confusing.

Of course if by using scripts we remove the false positive security alert, that’s a good enough trade off.

Do you know if we can code sign the executable or something to remove the false positives too?

[mardukbp]

Would it help if we compiled the launcher with c# (csc.exe) or it would be basically the same situation?

I have experience with .NET 5 and 6, which no longer include csc.exe but dotnet build calls csc.dll, and the .exe files I have generated have not been flagged as a threat by antivirus programs. So maybe that would work, but I think that PowerShell is the right tool for a launcher script. Starting processes is what shells are designed for and PowerShell has access to most, if not all, .NET APIs and one can even load the Win32 DLLs and use the low-level C APIs. It is a very powerful language. Moreover, PowerShell scripts can be signed. On my machine I set the execution policy to Restricted, which does not allow executing scripts, and my solution still works. So it should be robust. But testing it in other machines would be better :)

Do you know if we can code sign the executable or something to remove the false positives too?

Before coming up with the solution above I did some research (there are lots of GitHub projects dealing with the same problem) and apparently the only thing one can do is contact Microsoft and all Antivirus companies and hope that they add your executable to the list of non-dangerous programs. That is not an Enum.map away ;) I think it is very hard to know what an .exe does, so Antivirus software relies on some heuristics in order to flag an .exe as dangerous or not. My guess is that all executables generated with vsc have some binary code in common and that is why if some of them were found to be dangerous then all are considered dangerous. Maybe it is possible to modify this common binary code without negatively affecting the execution of the program, but I think that for an .exe that only starts a process it is overkill.

[wojtekmach]

Good to know, thank you. I'll look into your .ps1 based solution soon. FWIW we were planning to do dotnet build (or the mono equivalent) as it would allow us to cross-compile from macOS.

[tymoor]

Not sure if you're building on Intel Macs - but have you looked at https://github.com/burrito-elixir/burrito as an option for cross compilation? Linux builds work well also, as long as there aren't NIFs? Not sure how the AI pieces are integrated currently...

[wojtekmach]

Burrito is great but it unfortunately doesn't help here. We are now building GUIs using native APIs and with Burrito (or Zig or similar) we don't have easy access to target GUI SDKs like AppKit on Mac, WinForms (or others) on Windows, etc. We'll have a build server per OS but that's ok.

[mardukbp]

PowerShell 7 is cross-platform. You can test the script (minus the message window) on macOS. Am 6. November 2022 18:33:56 MEZ schrieb Wojtek Mach ***@***.***>:

…

Good to know, thank you. I'll look into your .ps1 based solution soon. FWIW we were planning to do `dotnet build` (or the mono equivalent) as it would allow us to cross-compile from macOS. -- Reply to this email directly or view it on GitHub: #1503 (reply in thread) You are receiving this because you commented. Message ID: ***@***.***>

[wojtekmach]

@mardukbp I was playing with PowerShell in a Windows VM and noticed:

After some googling it was easy enough to change the policy via command line but I'm not sure if it is acceptable. (Of course being mistaken for malware isn't either.) Do you have any feedback?

[wojtekmach]

It didn't work for me:

[mardukbp]

You are right. I don't know why it worked last time when I set the ExecutionPolicy to Restricted. But anyway, PowerShell is not that strict. The following should work:

powershell -ExecutionPolicy Bypass -file "hello.ps1" 

[wojtekmach]

Yup, this worked, thanks!

[mardukbp]

For completeness, here is the explanation of the Execution Policies.

Regarding Bypass:

This execution policy is designed for configurations in which a PowerShell script is built in to a larger application or for configurations in which PowerShell is the foundation for a program that has its own security model.

I think the above applies to Livebook. But you might consider using RemoteSigned instead:

• The default execution policy for Windows server computers.
• Scripts can run.
• Requires a digital signature from a trusted publisher on scripts and configuration files that are downloaded from the internet which includes email and instant messaging programs.
• Doesn't require digital signatures on scripts that are written on the local computer and not downloaded from the internet.

I think a script created by the installer counts as written on the local computer and not as downloaded from the internet. So, it should work.

[tymoor]

powershell.exe is the pre-v6 program, included with Windows. Later (and Mac compatible versions) are pwsh(.exe) and must be explicitly installed on all platforms.

[wojtekmach]

Hey everyone, we have new nightly builds at https://github.com/livebook-dev/livebook#desktop-app that should fix the issue. If anyone is still running into this problem, please let us know!

[mardukbp]

Awesome! Thank you so much @wojtekmach.