Now you have a chance to write a line, without using 3ds max, just for fun.
I haven’t written a line of maxscript for three years.
you’re best out of it, the current max is horrible the UI is like a nasty twitchy cracked up drug addict. The more I have to use it the more I hate it. Just Nasty.
Same here please, can I get this?
Thanks
You got a PM
@PolyTools3D, in your custom attribute example, if you load the scene file that has the CA in a session of Max other than the one in which you evaluated the CA’s definition, the safe scene script execution (SSSE) will block the unsafe command (DosCommand).
The reason that in your example the security feature seems to not work, is because the CA’s definition was evaluated as non-embedded and due to an code-optimization, it is being used as such until you restart 3ds Max.
We are aware of this issue and will address it in a future release of 3ds Max.
I wanted to chime in some on this thread. I haven’t been so active here lately as my work has kept me busy for a few years. Over the last decade+, several of you have been awesome resources to all the world and to myself as I learned the ins-and-outs of MAXScript.
I started thinking about security several years ago as I realized all the things you can do with MAXScript. When the topics started coming up in the Max beta forums over the last few years, I was honestly skeptical about the project initially. As someone who had made his living primarily because of technical MAXScript expertise in the last several years, I was concerned about anything that might take away the power of MAXScript as a pipeline tool.
Fast-forward and I now get to work alongside Attila as a fellow product owner at Autodesk. After following the topic very closely (and often providing my own perspective to Attila’s team), I think that the situations was handled very well. All of my initial fears are gone because of the way that the features were developed. The commands that are blocked are only when the calls are from embedded scripts in the scene—preventing the kinds of things that people wouldn’t expect to be doing anyway. Are people actually using hiddendoscommand() inside of a scripted controller, for example? Users aren’t going to expect that if they open a Max scene, a custom attribute on the rootnode is actually able to automatically edit files on your computer.
If you still need for one of the blocked commands to work from within a custom attribute, you can simply change your approach to writing startup scripts to define global functions, structs, macros, etc, and call those from your embedded custom attributes. Because they are run at startup, they are not considered embedded functions.
The reason this is safer is that those functions will only be there if you put them on your computer yourself—and this assumes that you understand and trust those tools. It’s protecting someone from opening a scene file they download from the internet and suddenly they have problems. The system is not about protecting every vector of attack—but closing the door on spreading attacks inside of Max scenes.
I just wanted to share my thoughts on this topic, because after all is said and done, I’m actually proud of what Attila’s team accomplished. I think there are some things to polish (like what Attila mentioned above), but I know he and his team have been very dedicated and passionate about trust and reliability for all of us Max users in the world.
May I ?
for OP, well… max team need something even tho it can’t block 100%.
All anti-virus don’t prevent virus 100%.
But, we still installs and need them.
Parser sound awesome. But, there are million of users who can’t even write a single line of script. They need something.
If this even reduce the issue, that’s big win for max dev since it will reduce the support ticket.
It shall be noted that my criticism is not to the security features themselves, but to their implementation and advertising.
From my perspective, even the use of words like “malware” or “virus” is inadequate in the context of an artistic software.
That’s a design problem, it could block 100% of the code and give the user the opportunity to clean up the files or to analyze them further. If the user does not have the knowledge, that’s their responsibility.
Since malicious codes comes first, you can’t warrantee any safety, unless you delegate that responsibility to the end user. In the end, if something very wrong happens to your system or confidential information is leaked from your network, will you say “well, the software has good security features but they were bypassed, what a shame”?
If by having an antivirus installed on your system you think you can safely run every .exe find out there, you are plain wrong, and there is no one you can blame for that except yourself, even if you don’t know what the word “programming” means. And the antivirus company won’t take any responsibility on the matter, so you’ll probably end up switching to a “better” antivirus, and you will be in the exact same situation as before.
My statement “DO NOT RELIE ON THIS FEATURE” is indeed to protect the 3ds Max reputation and to make the users aware of (same as with any antivirus), the files they are opening may contain “unsafe script commands” that can bypass the SSSE and that they are responsible for opening it.
Otherwise users may feel safe opening any file, and in the end they will blame Autodesk for not protecting them enough if something goes wrong. When people gets piss off the first thing they will look for will be a responsible, and most of them will make sure to exclude themselves from that list in first place.
The fact that I get the best bulletproof vest ever created, doesn’t mean that I will shoot myself just to verify how good it is. And things get worse if I had to shoot myself with experimental guns.
Reducing the support tickets can’t and shouldn’t be a concern. Security is far more important than a support ticket.
There is a well-known saying: “The hardest thing of all is to find a black cat in a dark room, especially if it is no cat.” I want to make the opposite sentence: “The easiest way to solve a problem is to pick one that does not exist.”
I have been doing 3D graphics and this business in general for over a quarter of a century, and I want to say that I have never met a single virus or malware transmitted through plugins, and even more so through files for 3D tools. It should be noted here that by viruses and malware, I mean deliberately harming or creating problems in order to make a profit. So I didn’t see it.
There were cases when simply inept developers created serious problems with their developments. I’ve seen this many times, and also with bugs (or “fatal improvements”), such as in official releases of 3DS MAX, which could halt production for long periods of time, lead to deadlocks in development, and cause technical problems.
Many can recall to me an example of what is probably best known as the ALC / CRP problem. Yes, this is an epic story that has deeply affected millions of files, hundreds of companies and projects.
However, there is no malicious intent in this story, but only the developer’s “monstrous crookedness”, multiplied by the carelessness of the 3DS MAX community, which includes both 3DS MAX developers and its users.
I may be wrong, but first encountered this problem sometime in 2013-2014. At that time, it took me about two weeks to solve the problem, cure and protect all files for the future, reliably and securely enough for the specific needs of the company. That’s all, and this should be the way such stories should end.
Five years later, when the problem had already become “pandemic”, and there came some solutions in the community, the Autodesk paid attention to this. As subsequent events showed, in order to solve this problem, it was just necessary to think about its solution. If you discard everything unnecessary and duplicated from “3ds Max Scene Security Tools”, you are left with 200-300 lines of simple pure MXS code that solves the whole problem. And it would be great and enough if the 3DS MAX developers posted this code as an example of how an advanced technical artist works.
Now let’s talk about the mechanism of infection and spread of such “sores” in the 3DS MAX system.
Firstly, there are only two ways to “litter” the 3DS MAX scene with possible “infection”. I’m talking about script controllers and custom script attributes. The rest (a couple more) are technically difficult and meaningless in terms of the presence of the first two.
Secondly, there is only one way to “transmit infection” (spread) – the using of startup script files. There are simply no others! And no other has ever been used.
We could easily identify cases of accidental and unintentional infection if we had a good parser for MAX scenes. But until recently it was not possible to even redirect callbacks.show to StringStream! Which in the case of ALC / CRP can give us 80% of the idea of what is happening and what to do about it.
Distribution usually occurs via .MSE files (most often hidden). It would seem that disallow encryption of scripts and launch scripts from hidden files – this is quite enough. That’s all! But no …
What we have for today … Instead of creating a system and running scripts in MAX as transparently as possible, a kind of “top-secret” mechanism is again created in the “security” service.
So I ask, “Why look for a black cat in a dark room?”