How do you verify a package is not malicious?

[Stagg54]

So we had a discussion during Virtual Coffee about malicious packages and vetting.

How do we verify that code is not malicious?

What might flag something as malicious?

We can use VI analyzer to check for certain things such as:

• PW protected VIs
• Removed BDs
• Call Library Node
• .NET nodes
• Network nodes (TCP, UDP, etc)
• File I/O nodes
• Shell commands
• Run on open
• Subvis with no icon or hidden under other objects

What should we add to that list?

Also we need to be careful with the fact that people can use #vian_ignore to ignore specific tests, so maybe we need to add some randomness to naming tests to avoid that.

We will also need

• A system for revoking or removing packages
• A way of notifying users if a malicious package is found.
• Flagging packages that depend on malicious packages

Any thoughts from the community about security and package management/distribution?

Edited September 8, 2020 by Stagg54

[LogMAN]

I have two responses to this. Let me start by contributing further suggestions.

15 hours ago, Stagg54 said:

What should we add to that list?

• No invisible code - that is hidden code inside structures that have auto-grow disabled.
• No PPLs
• No binaries (DLLs, executables, ZIP files, etc.) - except if the source code of the DLL is included or can be obtained via open source channels attributed in the package.
• No unlicensed packages - a reusable package without license is worthless.
• No broken/missing VIs - bad code is not reusable.
• No viruses, etc. - just use your average anti-virus protection to verify each package. We don't want to unpack a malicious ZIP file or worse...

16 hours ago, Stagg54 said:

Also we need to be careful with the fact that people can use #vian_ignore to ignore specific tests, so maybe we need to add some randomness to naming tests to avoid that.

Perhaps this can be done by a test that checks for #vian_ignore labels in all VIs.

[LogMAN]

Here is my second part including some doubts. Please note that I make a few assumptions about the nature of this idea, so take it with a grain of salt.

16 hours ago, Stagg54 said:

We can use VI analyzer to check for certain things such as:

• PW protected VIs
• Removed BDs
• Call Library Node
• .NET nodes
• Network nodes (TCP, UDP, etc)
• File I/O nodes
• Shell commands
• Run on open
• Subvis with no icon or hidden under other objects

This will immediately flag all existing (non-malicious) packages as malicious, because each one will fail at least one of those checks. Just try running those checks on the OpenG packages...

Also, most of those points only indicate potential technologies with which one could build malicious software. They are certainly not indicators of malicious software on their own.

Not just that, but it also limits the options for the kind of licenses one can choose for their package. In fact, only an open source license is able to pass the checks (no password protected VIs + no removed block diagrams). While I like open source as much as the next developer, this will prevent businesses from providing licensed solutions via packages. In my opinion this is a bit too restrictive.

16 hours ago, Stagg54 said:

How do we verify that code is not malicious?

I'm no security expert, but malicious code is generally detected during execution. Static code analysis is simply not smart enough to detect nuances in execution behavior. There is also no 100% guarantee that malicious code is triggered during code execution, which is why each users is responsible for verifying code that they downloaded from the internet (sandboxing).

16 hours ago, Stagg54 said:

Any thoughts from the community about security and package management/distribution?

We are developers. As such it is our responsibility to take care of every tool we use for our work. This includes third-party packages from "unknown" sources or even package vendors.

There are of course a few things that the package vendor could (should) do to help identify the origin of a package. For example, I want to be sure that the OpenG packages are actually from the OpenG community and not from someone random. This is why packages typically include information about their origin and are tied to a specific username. For example, the OpenG library (package) could belong to the OpenG account: "gcentral.org/packages/openg/openg-library". If you want to go one step further, have package owners sign their packages (i.e. PGP). For trusted package owners, GCentral could sign their keys to build a "web of trust". That way, if I trust GCentral, perhaps I can also trust the one that GCentral trusts...

Regarding malicious code, I'd only expect GCentral to verify that packages don't include viruses (use your average anti-virus software). The rest of it is my responsibility. I am responsible for the code I download from the internet. GCentral should certainly not aim to take responsibility for that. My recommendation is to not have any kind of "no malicious code detected" tag on packages, because it will give developers a false sense of security. A "package from verified source" tag, however, could be worth looking into.

[Stagg54]

Any list we put together is probably still going to have false positives. All we can really hope for is to flag things for further review.

It could point out some problems. For instance, a math library that is using TCP/IP is probably an instant red flag.

Also any list if we make it public, will just result in a cat and mouse game, because people who are determined will find ways around it. All we are really doing is just making it harder and picking off the low hanging fruit. That is all cyber security in general is doing. A determined and skilled attacker with sufficient resources will always find a way in. 

Another thing we do need to add as you mentioned is some sort of publisher verification.

[X___]

On 9/8/2020 at 8:45 AM, Stagg54 said:

So we had a discussion during Virtual Coffee about malicious packages and vetting.

How do we verify that code is not malicious?

What might flag something as malicious?

We can use VI analyzer to check for certain things such as:

• PW protected VIs
• Removed BDs
• Call Library Node
• .NET nodes
• Network nodes (TCP, UDP, etc)
• File I/O nodes
• Shell commands
• Run on open
• Subvis with no icon or hidden under other objects

LabVIEW itself would be highly suspicious, according to these criteria. But wait...

[Dataflow_G]

To add to the list of potential red flags:

• Windows Registry Access VIs
• VI Scripting calls (deleting or subtly modifying existing project code)
• Large VI file sizes / large constants (malicious VIs stored as byte arrays, so avoiding VI Analyzer's checks)
• Bugs known to crash LabVIEW
• Shortened links in VI help
• Non-standard block diagram colors (hiding a subVI on an identically colored BD)
• Obfuscated code (strings masquerading as boolean arrays, numbers with hidden precision, etc):
  • 
• Very small subVI icons (think a VI disguised as an error wire, as seen on reddit😞
  • 

 

In reality flagging a package based on any of the previously mentioned criteria will be almost exclusively false positives. Perhaps providing a list of function types a library uses would better help the developer assess the library, similar to the app permissions shown when downloading an app on iOS / Android. So a library may use Network, Scripting, and File System. As LogMAN said, it's ultimately up to the developer to take responsibility for the code they use.

obfuscated_LV2014.vi

Edited September 10, 2020 by Dataflow_G
Adding obfuscated code example

[LogMAN]

Here are some more potential flags:

• Private function calls (anything offered by "SuperSecretPrivateSpecialStuff")
• Undocumented function calls (anything from <labview> that is not on the palette, except those hidden gems)
• Functions that access files in the user's scope (desktop, documents, etc.)

Although the question is about malicious LabVIEW code, there are other points to consider:

• Any form of harassment, racism, etc. as part of the codebase (file names, free labels, VI documentation, error messages, etc.)
• Non-LabVIEW files like pictures, videos, presentations and others, which may contain harmful content. For example, macros in office files.

In my opinion, the likelihood of malicious LabVIEW code is far smaller than malicious office documents. This might change with the availability of the community edition, but since LV is very niche, there is not much to gain. (unless there is a chance that malicious code gets used by a company like NI or NASA...).

[Chris Cilino]

Howdy ya'll

Thanks for your input. Please keep it coming! I'm trying to minimize my interactions with this thread so as not to inadvertently skew the conversation. 

I love the technical aspect of this conversation. Sounds like so far in this conversation we're exploring the "How can we do this?". I'd like to propose the additional following set of questions to summarize the virtual coffee conversations we've been having and hopefully merge the conversations (mentioned by Stagg54) in the first post

To summarize, here is the logic \ questions that have arisen:

The primary question: "How do I (as a consumer of code) prevent unwanted effects from code I download?"

Leads to responsibility:

1. Who is responsible to prevent unwanted effects of code?
2. How do the responsible parties prevent unwanted effects of code?

There seem to be two ways to prevent unwanted effects:

1. Prevention: don't distribute bad code
2. Mitigation: As a user, I have bad code. I need to remove it.

Mitigation spawns two more questions:

1. How to notify people so they can remove bad code?
2. Should people be forced into a system so they can be notified?

I'm not suggesting answers to those questions, but want to also throw them into our calculus. Please feel free to comment on those questions and keep the conversation rolling.