Custom packages - virus and malicous code risk?

Its not so much a Dynamo issue at this point, as it is an issue of Admin versus User permissions, and what does the IT department allow folks to do on the company machines.

While it may seem limiting and hamstringing, i dont think its outlandish for IT groups to consider installing Dynamo in a controlled fashion, meaning: Users cant update their builds, and users cant install packages on their own. Obviously companies need a mechanism for testing packages in a controlled (but fast) environment, before shoving them out to all users, but yes: its a very real concern.

Dropbox and Box have both led to real companies getting cryptolocked out of their own files, for periods of time. Email, P2P file transfers, etc. They are all things company IT groups need to deal with.

Ive been talking with Gordon Price a LOT about deploying Dynamo, and managing it at an enterprise level, as that was/is my hesitation to want to get in to Dynamo. If we dont have a way we recommend companies deal with it, eventually they will just shut the door on it. Companies serious about security already do that to other apps they cant vet and protect inside.

Jm2c.

2 Likes

This discussion is becoming really serious and should maybe be reported on another level. I would assume, however, that a cost analysis should be done to compare productivity gains with the cost of a Code Security Analysis or something similar?

1 Like

Oh wow. I haven’t heard that tone on this forum since … never actually.
@LARCH - since you’re obviously a new member you may not have taken the time yet to review our community guidelines. I would suggest you do that at your earliest convenience. The Dynamo community is by far the friendliest community I have been involved in so far and we would very much like to keep it that way. Please refrain from calling other peoples’ opinions “unqualified” in the future - there are more respectful ways of voicing your disagreement.

@lordsummerisle - I would agree with @Konrad_K_Sobon and @Brendan_Cassidy and add the following (elaborating a bit on what @Yna_Db wrote) :
At least in the case of Python-based nodes it could be assumed that the vetting is performed by the community. Lots of people on this forum regularly take a look under the hood of a lot of the Dynamo packages out there. So I think it’s fairly safe to assume if a package has a certain number of downloads under the belt and nobody here has complained about it being malicious that it will be safe to use. In fact, I would actually consider it safer than downloading a Revit addin since that is actually closed source and may be logging my every key stroke for all I know. :wink:

I think what we need to be concerned about is something else. As @Aaron_Maller has pointed out, we need more control over what users can do with Dynamo. Because they are the single greatest risk in cyber security. Gaining control over who can use the package manager would be a good start, I think:

8 Likes

I would go a step further, and say:

  1. The ability to disable Package Manager for some users
  2. The ability to tie other users to one users Package Manager (so a BIM Manager installs, everyone gets package).

Right now, i do number two with a series of Robocopies, and it works like a champ. But, the ability for someone to update a package (one of you gifted folks that develop packages), and for a BIM Manager of 1000 people to test it in a controlled setting, and then “push” it to all users on prem?

Silly as it sounds, Dynamo would get ten times more powerful than it is now.

1 Like

Aaron-
I too wish we could disable the package manager for everyone except the trusted few.

For your #2 - I would not recommend that the BIM Manager’s installs be pushed to everyone. The BIM Manager is likely the tester/gatekeeper - he will install and vet things, then the good stuff would be pushed out to all using the a common networked library of packages (via Settings/Manage Node and Package paths) that the BIM Manager controls the contents of. Copying everything he/she has would defeat the purpose of protecting the majority of users wouldn’t it?

2 Likes

@Ben_Osborne beat me to it.
We have all our packages located on a read-only network drive and Dynamo gets deployed with a customized DynamoSettings.XML that points the packages path to that drive. When I want to push out an updated package I simply put it on the network drive.

5 Likes

i’m guessing what @Aaron_Maller was meaning was a BIM manager could maintain a folder from which all office users get the authorised packages.

i’m thinking as a workflow - Dynamo manager downloads a package to their local machine, once vetted - copy package to second folder - robocopy this to a networked folder location to which all office users have their dynamo pointing too.

One hacky way to disable the package manager is to deploy a customised DynamoPackage.dll.config file to all users, without a packageManagerAddress value. Once its removed, it will no longer be able to find the server…and so no user will be able to download anything:

You can find this file in C:\Program Files\Dynamo\Dynamo Core\1.2

7 Likes

@Thomas_Mahon - Nice. That’s close enough. :slight_smile:

1 Like

Thats what i meant. Sorry i wasnt clear.

The issue with security was a concern of ours for all of three seconds. The benefits far outweigh the risk by an exponential factor.

Typical digital security will block or severly limit 99% of the issues they are worrying about. For those aspects Dynamo is no less secure than the rest of the stuff you use. The small remaining portion of issues are exploits so rooted deep in the system that no one would waste leaking them to the world via dynamo. Be it for fun or profit, they will be exponentially more successful in getting the malicious code into the system via other means.

Note that the package manager website (https://dynamopackages.com) shows less than a half million downloads so far. That’s a great number that many of the people reading this post should take a TON of pride in by the way. Thanks for all you guys do. Someday I hope I can be 1/10 as helpful to the community as the publishers have been to me. Thanks.

By contrast a well placed and distributed bit of code that works with something like the heartbleed exploit (https://en.m.wikipedia.org/wiki/Heartbleed) can hit that many systems in a nano second. Interesting to note that autodesk software you likely use was impacted by this but the fix wasn’t out for 23 days. How did the bosses handle that? Most of the industry didn’t care and continued with business as usual. Keep in mind similar exploits and malicious code could be hidden in manufacturer PDFs and DWGs, RevitCity families, or even a web ad placed through Google. The only way to be 100% safe is to never bring any outside data into your office.

Is it possible that malicious code could be snuck into your systems via dynamo? Yes. Its also possible for a disgruntled employee to write a .bat file that turns your exchange server into a brick. Fortunately, neither are very likely and I won’t be losing any sleep over them. It’s far more likely (boardering on certain) malicious code has already snuck into your system via the numerous other items you use daily, or that you have a far larger exploit ready for someone to crack open. We just don’t know about it yet.

Don’t let the fear of ‘what if’ deny the firm the benefits the rest of us are seeing. Instead take an opportunity to review your company security protocols (I.E. no user should have complete system access) to limit exposure. I reccomend using an external vendor for this who can help you look at things with fresh eyes. You will be safer long term against the very unlikely dynamo attack (or bat file wielding employee) and the absolute certainty of a large distribution attack.

7 Likes

Thanks for sharing this, I would have one more question, if you let me: can we safely exchange files here (such as .dyn or .rvt)? (This could have been already discussed somewhere but I am not aware of it…)

thanks Jacob, that’s really helpful

our office dyno group is having it’s second meeting on Tuesday, so hopefully with all the excellent replies on here we can put this issue to bed.

Interesting topic. There are so many ways to compromise a system and yes Dynamo packages could be one way I guess. However, other more common ways are through email attachments, infected USB drives, drop box or sloppy web protection, something that management are at risk of doing quite a bit I’d say. If your company was that concerned you could get your own Revit API guy and generate the content yourselves, or if the nodes are in python, peek under the hood and have a look at what’s in there - this way you can learn how it works and start learning to develop your own content.

At my company, we test and peek in all packages before they are rolled out on our server globally so we have vetted the quality and some packages are whitelisted as I know they come from a reputable source and always good quality e.g clockwork, arch-lab, data-shapes to name just a few.

I agree with most of the comments above, although it did get rather heated. But, you always run the risk of infection as long as your computer has an internet connection and USB ports. As @JacobSmall said, the functionailty Dynamo gives you is well worth the risk and in most cases you can view the code yourself, not something that can be done with Revit Add-ins (or any other 3rd party add-in for any software) which you could argue is riskier.

Anyway, good luck with your business case and don’t forget to download the IStealAllYourData package, it’s slower than flux.io but by guegle so far more secure of course. :stuck_out_tongue_winking_eye:

2 Likes

As far as I know this site is as safe here as any other reputable file transfer method. I have faith that Autodesk wouldn’t let anyone splicing anything bad into the stuff we download and other users would have to hack into the system to get that level of access. So no real worries on that end. That said, if someone uploaded an infected file to the site and you downloaded it then you’re vulnerable - which is exactly the same with any other file transfer.

Now let’s all go start out our week worrying about all those infected bits of code in dyf files that we’ve passed around like pink eye through a kindergarten!

Seriously though I can’t stress this enough - it would be difficult and not worth the effort to attach malicious code to something on these forums. Not a wide enough distribution network. So don’t worry about it on that front.

A virus (meaning self replicating malicious code) can attach itself to a dwg, rvt, dyf, jpg or any other file type though. That’s why they are called viruses: they spread. But this is why we protect ourselves. Everyone here has heard about the need for antivirus and why when they bought their last personal computer, tablet or phone. Just because you’re working in a corporate environment doesn’t change that need. But the sad reality about antivirus is that it works like real medicine in that the ‘vaccine’ for a virus can’t be put in place until we know what that virus is (imagine the next Polio, now go cure that before it exists).

This is why every office should have digital security measures in place (firewalls, antivirus, limited permissions, frequent data backups on separate media, etc). The severity and restrictions of these measures should be tailored to the work of your office (the neuclear plant should have more restrictions than a sole proprietor doing single family homes).

Ask your IT department, consultant, or the ‘computer guy’ in your office for specifics about your office’s system. They won’t have to go into too much technical detail for you to get the just of it. You will likely be surprised by what actually happens in the background while we do our documentation and design work. So much of what they do goes completely unnoticed until something breaks at which point they usually serve as the ‘fall guy’ for stuff that is out of their control.

There should really be a national ‘IT support’ day… someone call Hallmark I’m sure they would love a reason to sell more greeting cards.

1 Like

@Andreas_Dieckmann
Nice way to manage :slight_smile:

Ok found the DynamoSettings.XML file here:
C:\Users\ UserName\AppData\Roaming\Dynamo\Dynamo Core\1.2

I can see the listings as the same from Settings>Manage nodes & Package Paths from within Dynamo
But what should be changed to make all future packages reside in the network drive?
Also, how to make installation of Dynamo on a new machine read this file?

Thanks!

Guys for the corporate people I am happy to run malicious code checks validations on my source code in my packages and issue a certificate at $500 a company as well as digitally signed dll’s. This will guarantee my packages are safe to use and free from virus’s. Contact me for details. I could probably speak for a number of other people as well who would be happy to offer that level of guarantee for financial compensation.

3 Likes

There was a virus that would upload all CAD files to a remote destination, Mexico I think. Revit models have a lot of value, especially military ones… Interestingly, it was written in LISP! (Dynamo’s feeble grampa?)

I think it’s far fetched to go through Dynamo, but to say that Revit models have no value and that no on would want it is not wise. Many people could die if Revit models would go into the wrong hands. Think Pentagon or security or bank buildings.

2 Likes

Hi Andreas,

We would like to adopt the same method but worry some .dll files won’t update if they’re being used while a package is updated/replaced? How would you ensure this doesn’t cause an issue?

Many thanks

Tell people to shut down their machines or at least Dynamo when they leave the office. Then update packages at night. Works 95% of the time. :slight_smile:

3 Likes