If you have a problem or need to report a bug please email : support@dsprobotics.com
There are 3 sections to this support area:
DOWNLOADS: access to product manuals, support files and drivers
HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects
USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here
NEW REGISTRATIONS - please contact us if you wish to register on the forum
Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright
The root of all eval()
7 posts
• Page 1 of 1
The root of all eval()
Made a discovery the other day, I had no idea you could do this with Ruby. (But then there's lots & lots I don't know ... > Lots. )
In my example you can write a regular text list containing expressions, and then select one of them.
A bit like the new Eval prim in the FS Alfa, eval() enables Ruby to run code that has been written as text somewhere else, outside of its own regular 'red' editor. In this instance it comes from a text box, but it could actually be sourced from anywhere. So this is really flexible - with this arrangement you can enter any valid Ruby code through an S input and eval() will execute it; my code-selector example is just one possibility.
However ...
I put up something similar on Discord, and got an immediate warning from Myco (The Boss!), with a link to an 'Eval is Evil' site! Omg Omg . (Google that phrase - there's lots of them).
The point is, always, that if you allow external code to enter an eval() in Ruby then it's going to get executed, and if you take no precautions it could allow for something malicious to enter. It's a lesson heeded because my plan is - guess what! - to make something like this that decodes some form of 'config' text file, in order to set up various input parameters and maybe switching-equations. Seems like I'm going to need to introduce some careful parsing/filtering to make it safe ...
H
In my example you can write a regular text list containing expressions, and then select one of them.
A bit like the new Eval prim in the FS Alfa, eval() enables Ruby to run code that has been written as text somewhere else, outside of its own regular 'red' editor. In this instance it comes from a text box, but it could actually be sourced from anywhere. So this is really flexible - with this arrangement you can enter any valid Ruby code through an S input and eval() will execute it; my code-selector example is just one possibility.
However ...
I put up something similar on Discord, and got an immediate warning from Myco (The Boss!), with a link to an 'Eval is Evil' site! Omg Omg . (Google that phrase - there's lots of them).
The point is, always, that if you allow external code to enter an eval() in Ruby then it's going to get executed, and if you take no precautions it could allow for something malicious to enter. It's a lesson heeded because my plan is - guess what! - to make something like this that decodes some form of 'config' text file, in order to set up various input parameters and maybe switching-equations. Seems like I'm going to need to introduce some careful parsing/filtering to make it safe ...
H
- Attachments
-
- eval_dem.fsm
- (436 Bytes) Downloaded 491 times
-
HughBanton - Posts: 265
- Joined: Sat Apr 12, 2008 3:10 pm
- Location: Evesham, Worcestershire
Re: The root of all eval()
Hi Hugh
I have succesfully used this method for storing drum machine songs/patterns and other settings in a config file and it works like a charm.
As this is only used by me I don't see an issue with the vulnerabilities. If however this was released to the public then obviously it would be a concern.
I'm wondering is it possible to encode the file somehow so that it is not saved as plain text . . . or would that make no difference?
Hoping one of the Ruby experts can advise
I have succesfully used this method for storing drum machine songs/patterns and other settings in a config file and it works like a charm.
As this is only used by me I don't see an issue with the vulnerabilities. If however this was released to the public then obviously it would be a concern.
I'm wondering is it possible to encode the file somehow so that it is not saved as plain text . . . or would that make no difference?
Hoping one of the Ruby experts can advise
-
DaveyBoy - Posts: 131
- Joined: Wed May 11, 2016 9:18 pm
- Location: Leeds UK
Re: The root of all eval()
Some time back, eval() came up here on the forums as well, and I also warned harshly! It cannot be stressed enough, how dangerous it is to use it, especially when you are not a Ruby Pro (none of us here is, that's the level of Pro I mean).
Just two lines of code can erase a users whole harddisk for example. Installing a trojan would be easy, and so on. Don't use eval().
Just two lines of code can erase a users whole harddisk for example. Installing a trojan would be easy, and so on. Don't use eval().
"There lies the dog buried" (German saying translated literally)
- tulamide
- Posts: 2714
- Joined: Sat Jun 21, 2014 2:48 pm
- Location: Germany
Re: The root of all eval()
DaveyBoy wrote:As this is only used by me I don't see an issue with the vulnerabilities. If however this was released to the public then obviously it would be a concern.
If there is no user access at all, it is safe. If the files you write to are not part of the evaluation, it should be safe. As soon as user input is involved, it is highly dangerous.
"There lies the dog buried" (German saying translated literally)
- tulamide
- Posts: 2714
- Joined: Sat Jun 21, 2014 2:48 pm
- Location: Germany
Re: The root of all eval()
Thanks for the heads up Tula, confirms my thoughts.
I have been experimenting with the green text prim that Hugh is using in his example.
Strings can be formatted and written to the prim(s) and evaluated when required.
The data is saved when powered off so this could be used as a safe 'internal' config or memory component without the need to write to file which can obviously be interfered with.
I'm also thinking that that this could form the basis of a custom preset manager
I have been experimenting with the green text prim that Hugh is using in his example.
Strings can be formatted and written to the prim(s) and evaluated when required.
The data is saved when powered off so this could be used as a safe 'internal' config or memory component without the need to write to file which can obviously be interfered with.
I'm also thinking that that this could form the basis of a custom preset manager
-
DaveyBoy - Posts: 131
- Joined: Wed May 11, 2016 9:18 pm
- Location: Leeds UK
Re: The root of all eval()
tulamide wrote:Some time back, eval() came up here on the forums as well, and I also warned harshly!
Thanks T, we just luv it when you talk harsh.
https://xkcd.com/327/
I'll be sure to sanitize my inputs
H
-
HughBanton - Posts: 265
- Joined: Sat Apr 12, 2008 3:10 pm
- Location: Evesham, Worcestershire
7 posts
• Page 1 of 1
Who is online
Users browsing this forum: Mirek Suk and 32 guests