It sure looks like it but it is not. Our VMs use perl script to autoconfigure when deployed. Unfortunately there are a number of vm templates with incorrect script which is a huge pain to manually log in and fix. So I was looking for a smarter solution. If this approach is not appropriate to be published I can delete the thread. | [reply] [Watch: Dir/Any] |
In the OP you write:
I have the script on one of my systems that I can't modify at all
Well, this reeks of privilege escalation. Why can't you modify a script? I can think of a number of reasons/scenarios, and a short description of why this can't be done would be appropriate, so any suspicion of inappropriate privilege escalation would have been dispersed at the beginning.
So this is an XY problem. The script should be fixed in the first place, at its origin. A script which allows execution of arbitrary commands by this simple mechanism is a high security risk which should be fixed immediately. You should escalate this issue, not your privileges.
Unfortunately there are a number of vm templates with incorrect script which is a huge pain to manually log in and fix.
There are ways to automate this process. It would have been better to ask for ways of how to do that. If this script is part of a deployment environment shipped by some VM vendor, please escalate to that vendor prior to disclosure. There's no need to delete this thread (yet ;-)
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
| [reply] [Watch: Dir/Any] |
Sure I understand the concern. I agree fully that the script should be fixed and it is planned for the next release of the VM template. This VM template is produced internally by our development org and we are managing an internal cloud where we they want to spin up sessions off of this template. The problem is that this script will be only fixed in later versions of the template.
Anyway it appeared it was not that simple after all. The suggested approaches did work in command line, but when testing end to end I found out that all quotes and apostrophes were replaced with &aquot; and & apos;. The arguments are being passed in the vm through an xml, so I guess that's why they were converted. So unless there is a way to do the same without apostrophes or quotes, our script is safe :).
| [reply] [Watch: Dir/Any] |
If the problem is that you do not have tools in place to roll code to dozens, hundreds, or thousands of VM's, write that tool, now. If the problem is that you don't have tools in place to securely run commands, or better, call sanctioned methods against dozens, hundreds, or thousands of VM's, write that tool now. If the problem is that you have code that exists on dozens, hundreds, or thousands of VM's that allows for the type of exploit you are contmplating, fix that code now!
| [reply] [Watch: Dir/Any] |
Thanks Dave, all of these issues are being addressed at the moment.
| [reply] [Watch: Dir/Any] |