Maya Security project

Given the rash of Maya security vulnerabilities it makes sense to pool our resources and come up with some kind of open source tool for scanning and quarantining potentially infected Maya files.

Some key items to consider:

  1. a scanner for scriptnodes (the link above includes a skeletal version but this would need to be bulletproofed)
  2. a method of securely identifying scriptnodes with a legitimate in-house purpose
  3. a method for scanning expression nodes (note: expression nodes are a real attack vector – I won’t post example code but they definitely can be used to run arbitrary code, can explain if necessary).
  4. a “pen testing” group that tries to find ways around whateve gets cooked up to make sure that the security guarantees are fairly solid.

This kind of stuff is hard and we have to be realistic about what is doable, but any shared response to this crap is a step forward. And we should encourage other communities (Blender, Max) to follow suit!

So…

Volunteers? Good chance to get a useful OS project on your resume and/or github!

5 Likes

I volunteer to help with this

1 Like

I’d be more than happy to contribute!

Yeah I like this idea a lot.

First step would be hashing out some kind of general design.

Is the assumption that we’d be testing files within a running Maya instance (presumably locked down / sandboxed in some way)?

Some starter Q’s to consider while thinking things through.

  • Scan files "offline: then isolate/report/sanitize?
  • Prescan files on load in a running maya, bail on unrecognized executable code?

0 voters

  • Use the hashing mechanism in this thread to identify & CRC safe executables
  • scan for potential unsafe operations but allow other scripts
  • I have a better idea… (include in a reply!)

0 voters

  • ban known bad scripts and ignore others
  • allow only signed (= as in previous Q)
  • Nuke and pave all executable code without explicit user OK

0 voters

Edit – i removed a question about names because @chalk’s suggestion “manik” is too good and I unilaterally embraced it!

1 Like

Hmm… I think code signing would be a viable solution but maybe it could be a graceful staggered approach. Test for code signing, if nothing found scan every file in memory based on buffer-size on load i.e. if the file is 2gb maybe pre-check then load vs a 100kb file test on stream in 64k chunks etc. Offline would be for batch folder sanitization. These would all get tested against a known set of bad actors too - essentially its like a virus checker/signer. So yeah a mix of everything :slight_smile: As for a name the Mayan god of protection is called Tohil with its symbol is called Manik. So either of these seems pretty good. (The Manik symbol is pretty sweet too)

1 Like

The offline scanning method seems good for safety, however, can .mb files be scanned in this way? If not, a running instance may be the only way to go - however, if you suppress script execution entirely, that should provide a relatively safe way to prevent any unwanted behaviours when files are opened.

What effect does node state have on code execution within nodes? For example if a .ma file is modified manually to set all expression nodes and script nodes to blocking, and the scene is then loaded, does anything execute?

subscribed. We are heads down on a rather large deliverable so I don’t know if I can volunteer too much time, but I am very interested in this project. For reasons.

One good thing we can do in the interim is to share test results – @EdArt’s question for example is a good one for people to try.

Another good one to consider is how much security is “enough” ? For example one could probably whack out a sandbox routine that would stop the viruses we have seen so far – but it’s extremely hard to guarantee that a motivated attacker could not get around any pure-python sandbox (great tech roundup here). My gut says that preventing all execution of arbitrary code is the smart way to go --but maybe people can come up with something better?

Forgot to add – another good way to contribute during this early stage would be to evolve some attack strategies we can use as tests. This weekend I’ll start a github repo we can use – i think for the short term we take it private so we don’t give away possible hacks before we have any defences, but eventually we will want to make the whole thing (including the test cases) public since there’s more security in many-eyes-on-the-problem than in obscurity…

To your first post, I think there are various methods we could work on:

  • filtering and evaluation with reporting - allowing users to decide what is dangerous and what isn’t, by not looking for malicious code explicitly, but simply looking for any code at all. This would then allow users to create whitelists.

  • extraction mechanisms - systems that can “rescue” content from potentially malicious files by extracting it, and only it, any breakages be damned (as this is likely to cause missing references, but that’s better than a virus)

  • like you said, a list of tests to identify attack vectors would be good; I have no idea about this, but could there be other methods to run code than script nodes / jobs? Can code be embedded in places where it gets evaluated?

I bet there are other vectors that we’ll have to find by trying. I know that catching potential bad scripts by static analysis will be very hard – it’s just too easy to objuscate potentially bad code that suddenly becomes evil at run time. Hopefully our “red team” of attack testers will uncover all the sneaky ways to deliver a bad payload, and the “blue team” will then find countermeasures. Nuking script nodes is easy (and, apart from some rigging scenarios, probably not too much of a loss) – as for other vectors we will have to see.

I’ve created a private github repo and team. pm me or @bob.w to get added