Max 2022 New "Security Feature" - What do you think?


#1

A feature that was introduced in previous versions and in 3ds Max 2022 it just got…:no_mouth:

My first impression is:

  • Rather than SAFER, it makes 3ds Max look like an UNSAFE software, that people can use to ruin your life.
  • It does not only prevents embedded code in scenes to run, but also external code.
  • The UI gets cluttered with “this” kind of antivirus buttons (wow) :roll_eyes:
  • It DOES NOT provide any benefits or safety, plain truth. DO NOT RELIE ON THIS FEATURE.
  • It seems like a waste of development resources, when there are so many other things to improve.

I really could not find positive thing about the new “Security Feature”, but all the contrary.

What could be done then to prevent real malicious code to be embedded or run from a scene file?

  • Do not allow scripts to be embedded in scene in first place. Who want to embed a hidden script in a scene after all? Isn’t just that behavior look the scene suspicious?

Just to verify what I stated, here is a silly script showing how dangerous 3ds Max is (it won’t do anything bad to your system, but shows the potential.)

  1. Run the script, save the file, open the file (it is now an embedded script).
  2. Select the box and go to the Modify Panel.

I bet we could do the same with controllers and even write a C++ stream to the file and execute it. I wonder how dangerous could that be? :thinking:

(
	
	delete objects
	bx = box isselected:on
	
	def = attributes ca
	(
		rollout params "Malicious CA"
		(
			button bt0 "Create File" width:160 height:24
			button bt1 "Delete File" width:160 height:24
			
			local theFile = @"C:\delete_me.exe"
			
			on bt0 pressed do
			(
				file = createfile theFile
				format "file created: %\n" file
				close file
			)
			
			on bt1 pressed do
			(
				format "file exist: %\n" (doesfileexist theFile)
				format "deleted: %\n" (deletefile theFile)
			)
			
			on params open do
			(
				bt0.pressed()
				messagebox "Hey, be careful!!\n\nPeople can do malicious things here."
				doscommand theFile
				sleep 0.2
				bt1.pressed()
			)
		)
	)
	
	custattributes.add bx def #unique baseobject:on
	
)

What do you guys think?


#2

Exactly my thoughts. I can’t see how is it any safer than before. Perhaps it is just a first step and more restrictions to come.

But how is it possible?
You can store bytes and strings in max scene in millions of ways and then read them and execute at any time.
The only way to make max scene a secure container is to block by default any attempts to use execute or readExpr like commands, disable CA, rollout, macroscript events and script controllers evaluation, ShellExecute and HiddenDosCommand and disable .Net as a whole. To my surprise they’re all already listed here.
Mission impossible until something like whitelist being introduced in the next versions of max.


#3

That would make things even worse in my opinion. This feature must be completely removed. This is a design software, not an Antivirus. Most complex software out there can be extended with scripting language or plugin architecture, and I don’t know any other that includes a sort of antivirus, what is that?

You just need to prevent the execution, not the creation. I see no reason to hide any kind of execute command in a scene file. If a developer must use this feature it needs to be external and not embedded in the scene.

So, the only solution would be to not make MAX extensible anymore. Just remove MXS and the SDK and we are safe to go.

I was aware of the blocked commands list, that’s why I created an example that proves it is incorrect, the commands I used are not blocked at all, and you can do very dangerous things with just those commands.

Even if it would be possible, it is impractical and just as unsafe as any other bit of software you run on your computer. What will AD do, hash and flag the millions of 3d Max files out there? Even though, nothing prevents a donkey from creating a piece of code like the one I showed above.

If removing this ridiculous feature isn’t an option, then there should be an external tool to clean up the files. AD could partner with any independent developer to create such a tool and keep the internal team working on improving MAX. Such a tool would be easy to maintain and independent from the 3ds Max system.


#4

AD could have legal reasons to implement this feature. Not that they wanted to add this Disable Maxscript checkbox.
I was amazed what you can do to a user machine since the day .net was introduced. This compile-on-the-fly things and many other things look very dangerous. And still it took them more than 10 years to take first measures to ‘protect’ users from unsafe content.

It was my only assumption what could they do about it when I was writing the post. Any only after a minute I bothered to google if something about this “feature” was already in the docs. And there was that long list of forbidden words and those funny adblock red-green buttons you mentioned.
I guess they will blacklist these commands you used as well in the next update.

I don’t have 2022 installed to test, but it is quite interesting how do they detect that certain function from embedded script must be blocked? By name? Can we simply assign execute to a variable and use it to call ? I know it is dumb, but who knows for sure


#5

First of all, I want to repeat what I said a several years ago - 3DS MAX is transforming from a tool for professionals into a toy for dilettantes. It all started with reworking the UI to fit the standards of popular gadgets.
Today it is a “Security Feature”…

I was also surprised to see this feature in MAX. What for? was the first question.
It is quite obvious that by allowing the use of modern programming languages ​​and advanced scripts, you can get full access to the entire system, and therefore the ability to destroy (break) it.
By pushing away professionals from participation, and encouraging amateurism, the developers themselves create the prerequisites for the “manifestation of the creativity of hackers.” After that, the fight against such manifestations looks doubly naive.

In my opinion, “Security Features” would rather provoke some people to hack than stop someone. In short, this is another useless initiative from the MAX development team.


#6

formatAllDisksUnsafe
letVirusTakeAWalk
killSystemForever
hackersPower

these functions must be detected and blocked! :point_up::face_with_raised_eyebrow:


#7

I completely agree with this statement. For many years we have been asking for a Parser for max files so that we can check the contents of the file without opening the scene. But alas … we see no progress in this direction from the MAX developers.

Secondly, it is necessary to completely disable encryption of executable scripts. I have been in this business for many years and I am responsible for what I say. This will not affect add-on developers in any way, it will just give the most talented and least lazy an opportunity to stand out from the crowd.


#8

What you say it’s not dumb, dumb is this new feature and the waste or productive energy in this kind of stuff.

Dumb is the code I wrote that fully bypass this “Security”. It would take me 2 minutes to write a piece of code that really ruins a system.

Anyway, the interpreter is aware of every command so it can detect literally anything.

I insist, if the corruption of scenes is a concern, it must be either avoided or solved with an external tool.


#9

That’s because you are old. We, the young guys, love colors and rounded controls. :stuck_out_tongue:

Seriously speaking, I think every software UI needs a re-bump from time to time, but I agree with you that how it was implemented in 3ds Max is a very wrong move. The UI is still very unstable, instead of improving and expanding what already was good (since Windows NT), we now have faulty controls living along with the old guys like the terrible outdated Curve control.

I wonder what they will do with the release of WinUI 3 that seems very promising.

Well, many companies took the same direction, make the UI look nice (according to who know who) instead of making them usable and solid. Apparently the big corporations decided to hire Interior Designers instead of software engineers and UI designers.

Next move will be to make the UI vertical, because cellphones are widely more used than desktop computers.

Absolutly !


#10

Well, we know MXS encryption was born as a joke anyway and was hidden behind the dark curtains for many years. :lying_face:

But I have to admit that I use it, what puts me in the lazy group. :smile:

Fully agree with this, a long requested feature that shouldn’t be hard to implement.
And how about a decent step debugger?

PD: Forgot to mention, a good, flexible and solid obfuscator would be appreciated. They have the lexer and the parser, so it wouldn’t be too hard to do.


#11

To be fair, not everything is negative, I think in the last couple of releases, there were a few outstanding features, some awaited for over 20 years or so, like the independent viewport.

But when I see stuff like this “Security Feature” it makes me ask if the persons that makes the decisions do really know anything about the business. And when I say business I don’t mean just money, I mean listening and understanding the community, look at how Blender made its own solid path up to the throne.

The Dev Team always (since I remember) complained about the lack of resources, and this is how they expend the few they have?


#12

Is the MAX Security problem far-fetched? Who can name at least a dozen viruses spreading through MAX?

Technically, only one group of “viruses” is widely known (it seems from the same developer) - this is ALC / CRP. But in this case, 50% is a lack of developer experience, 40% is a lack of user protection, 9% is an accident and only 1% is malicious intent.


#13

The 3DS MAX community is too small to seriously consider 3DS MAX as a source of hack for profit. …As well as any other 3D tool community, as well as all of them combined.


#14

I want to remind you that at that moment the User Interface of the Ribbon Tools, the only one written in WPF, and still remains an example of technical ugliness and crookedness, was subjected to my criticism. Can anyone really like it?


#15

I don’t want to shame or accuse anyone of using encryption … let’s just say it makes life easier and instills confidence in the security of your intellectual property. But this is an illusion, as I have explained many times.

On the other hand, all the malicious examples I know of in MAX are somehow related to MSE, directly or indirectly.


#16

Too simple and easy to find … :wink:
I can write a CA that will not be seen by any scene exploration tools, but will come with the scene and will be saved with all other scenes loaded and saved after. :sunglasses:

However, if there was a max file parser, then my CA could not be hidden. Therefore, I wrote to the Security Tools developers that they should look for the problem not after loading the scene, but while reading the contents of the file. …Although this does not guarantee success.


#17

I analyzed all forbidden commands and functions …
Letters (“e”, “t”, “o”, “i”) appear at least once in each name. Thus, it is sufficient to exclude all functions that use one of these letters! :point_up::face_with_raised_eyebrow:


#18

Is this statement true?

In fact, there are not so many places and ways to “hide” something in a file that can be used to extract the data and execute it.
But the most stupid thing that can be done to prevent this from happening is to look for “executors” by their names.


#19

This can be a problem in the case of using encrypted scripts.


#20

Maybe I’m overly optimistic about the execution, but there’re plenty of places to store bytes. Starting from appdata to directly putting the payload into the extra mapping channel or whatever else container. Shouldn’t be a big deal in non-empty scene.

It would be the most interesting maxscript challenge done here. :smile:

.

so if the Autodesk.Max.dll is whitelisted couldn’e we just do it like this?

((dotNetClass "Autodesk.Max.GlobalInterface").Instance.GetType()).Assembly.Load