Autoexecute refers to code in Maple worksheet that is executed when the worksheet is loaded. Typically it is used to initialise a worksheet before calculations.
Because it is possible (though difficult) for someone to create Maple code that might breach your computer's security you are warned by default when it is executed. You can disable the warning. Help autoexecute gives you some pages with more detail.
On Linux, sure - but on Windows, if the user has Administrator priviledges, then breaching security from Maple code is very easy. There are SO many different ways to accomplish it that the only challenge is to come up with something 'clever' rather than just doing it. [I will not demonstrate this here, that would be irresponsible].
Now, if maple is running with -z, then it is indeed challenging. I wonder if, instead of using the kernel to breach security, one can use the GUI itself? That might be challenging too. A further challenge might be to use some of the external components to breach security [for example, to get the C compiler to execute some code while it is processing some files via Compile]. I am sure other external-calling components could be coerced as well.
For usual Office programs a virus scanner at least could try to search for a makro virus ... as long as files containing binaries can be saved or other programs can executed (as the mentioned C compiler or the command shell) I would consider it as door, which is wide open ...
I believe that the -z option (to Maple) disables Compiler:-Compile as well as wrapper-generating external-calling. Without -z, both of those mechanisms could be made to execute arbitary shell commands (with the authority of the user running the Maple session).
The trick was to embed the commands in a string prepended to (say) the linker command or linker options. To do that with the Compiler, it was necessary to call it once to initialize its internal settings, and then to change the external linker command using undocumented internals of that Compiler module, and then to call Compile once again. To do it with wrapper-generating external-calling was easy, as the means of setting compiler/linker flags by using a Maple record is fully documented. I submitted working examples (software change requests) to illustrate both of these situations. In Maple 11, if the -z switch is omitted when starting up Maple, then the Standard GUI's disable-system-commands option was inadequate to prevent this breach.
Using wrapperless external-calling, it was straightforward to call system functions (eg. from libc.so on Linux).
For anyone concerned with security In Maple, I would suggest looking at the Security page (tab) in the Options menu in the Standard GUI. The level of granularity for security control is much improved in Maple 12. I was not able to get any of the breaches mentioned above to function, with the relevant security settings enabled from this menu. The disable-system-calls button disabled the Compiler (good). External libraries like libc.so, outside of Maple's own binaries, could be disallowed for wrapperless external-calling (good). And warnings/queries could be toggled for autoexecution of .mla archives or worksheets or worksheet execution groups.
i am not in hacking and set this in a Standard sheet - by default it allowed executables down the root, where my working directory sits - thus deleted that and said 'No writable files allowed'.
now just entered a plot command saying export - it exports, even the picture, as gif (despite dis-allowing) and IIRC a standrad attack is through gifs which load through network
so I would not really feel 'secure'
the other point is: using the *.wm may contain 'invisible' code, beyond the auto-exec ... (stumbled into that answering a question here and opened the according sheet ...)
more or less my feeling is: if Maple is following the way to build applications (an idea that I like) it will be confronted with that problem, inescapable
it is just that is not highly likely here to meet a bad mind (which is a kind of whistling in the dark)
anyway, for me it is not a serious problem (even if dislike it ...), more or less one has to be carefull (see my idiocy above ... which should unfortunately prevent me from reading unknown poster's files, i.e. giving answers)
Autoexecute
Autoexecute refers to code in Maple worksheet that is executed when the worksheet is loaded. Typically it is used to initialise a worksheet before calculations.
Because it is possible (though difficult) for someone to create Maple code that might breach your computer's security you are warned by default when it is executed. You can disable the warning. Help autoexecute gives you some pages with more detail.
David Clayworth Maplesoft GUI Developer
Difficult?
On Linux, sure - but on Windows, if the user has Administrator priviledges, then breaching security from Maple code is very easy. There are SO many different ways to accomplish it that the only challenge is to come up with something 'clever' rather than just doing it. [I will not demonstrate this here, that would be irresponsible].
Now, if maple is running with -z, then it is indeed challenging. I wonder if, instead of using the kernel to breach security, one can use the GUI itself? That might be challenging too. A further challenge might be to use some of the external components to breach security [for example, to get the C compiler to execute some code while it is processing some files via Compile]. I am sure other external-calling components could be coerced as well.
:-)
For usual Office programs a virus scanner at least could try to search for a makro virus ... as long as files containing binaries can be saved or other programs can executed (as the mentioned C compiler or the command shell) I would consider it as door, which is wide open ...
Security settings, Maple 12
I believe that the -z option (to Maple) disables Compiler:-Compile as well as wrapper-generating external-calling. Without -z, both of those mechanisms could be made to execute arbitary shell commands (with the authority of the user running the Maple session).
The trick was to embed the commands in a string prepended to (say) the linker command or linker options. To do that with the Compiler, it was necessary to call it once to initialize its internal settings, and then to change the external linker command using undocumented internals of that Compiler module, and then to call Compile once again. To do it with wrapper-generating external-calling was easy, as the means of setting compiler/linker flags by using a Maple record is fully documented. I submitted working examples (software change requests) to illustrate both of these situations. In Maple 11, if the -z switch is omitted when starting up Maple, then the Standard GUI's disable-system-commands option was inadequate to prevent this breach.
Using wrapperless external-calling, it was straightforward to call system functions (eg. from libc.so on Linux).
For anyone concerned with security In Maple, I would suggest looking at the Security page (tab) in the Options menu in the Standard GUI. The level of granularity for security control is much improved in Maple 12. I was not able to get any of the breaches mentioned above to function, with the relevant security settings enabled from this menu. The disable-system-calls button disabled the Compiler (good). External libraries like libc.so, outside of Maple's own binaries, could be disallowed for wrapperless external-calling (good). And warnings/queries could be toggled for autoexecution of .mla archives or worksheets or worksheet execution groups.
acer
i am not in hacking
i am not in hacking and set this in a Standard sheet - by default it allowed executables down the root, where my working directory sits - thus deleted that and said 'No writable files allowed'.
now just entered a plot command saying export - it exports, even the picture, as gif (despite dis-allowing) and IIRC a standrad attack is through gifs which load through network
so I would not really feel 'secure'
the other point is: using the *.wm may contain 'invisible' code, beyond the auto-exec ... (stumbled into that answering a question here and opened the according sheet ...)
more or less my feeling is: if Maple is following the way to build applications (an idea that I like) it will be confronted with that problem, inescapable
it is just that is not highly likely here to meet a bad mind (which is a kind of whistling in the dark)
anyway, for me it is not a serious problem (even if dislike it ...), more or less one has to be carefull (see my idiocy above ... which should unfortunately prevent me from reading unknown poster's files, i.e. giving answers)