[GH-ISSUE #726] Information exposed through the Script Variables substitution #2404

New issue

Closed

opened 2026-03-14 03:53:33 +03:00 by kerem · 1 comment

kerem commented

2026-03-14 03:53:33 +03:00

Owner

Originally created by @NiceGuyIT on GitHub (Sep 21, 2021).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/726

Server Info (please complete the following information):

OS: openSUSE Leap 15.3
Browser: Firefox 92.0
RMM Version (as shown in top left of web UI): v0.7.2

Installation Method:

Standard
Docker

Agent Info (please complete the following information):

Agent version (as shown in the 'Summary' tab of the agent from web UI): Agent v1.5.9
Agent OS: Windows 10 Pro, 64 bit v20H2 (build 19042.1237)

Describe the bug
The script variables functionality exposes information that might not need to be exposed.

To Reproduce
Steps to reproduce the behavior:

Go to Script Manager and create a Create a PowerShell script. Get-Timestamp is a custom function to log the time, not a built-in cmdlet.

Write-Output "$(Get-Timestamp) Command Line arguments:", $($args)
Write-Output "$(Get-Timestamp) Bound parameters:", $PsBoundParameters.Values

Go to an agent and run the script on the agent.
The Script Arguments section allows variable substitution for various client/site/agent properties. This substitution process does not check if the property is an actual property or another method/function/class.
See screenshot for example.

Expected behavior
Methods and class names should not be exposed when running a script.

Screenshots

Additional context
While this isn't a true security issue since Tactical doesn't have user permissions, this has the possibility of becoming something bad in the future. {{client.Meta}} exposes class names. {{agent.make_model}} returns the agent's make and model and is implemented as a method with @property, not an actual property. The other functions I checked return bound method. Some of these functions are return useful information. My concern is two fold:

A method may be implemented (in the future) that returns sensitive data when it shouldn't. For example, agent.get_login_token.
A method may execute code on the server resulting in data loss. For example, all three classes have a save method.

Most of this is mitigated by Tactical returning the object representation as a string instead of executing the method and returning the results as a string. It would be nice if Tactical checked if the class property (script argument from the user) is an actual property or approved method and return nothing (or an error) if it's a class method not decorated as a @property or another class name.

Originally created by @NiceGuyIT on GitHub (Sep 21, 2021). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/726 **Server Info (please complete the following information):** - OS: openSUSE Leap 15.3 - Browser: Firefox 92.0 - RMM Version (as shown in top left of web UI): v0.7.2 **Installation Method:** - [X] Standard - [ ] Docker **Agent Info (please complete the following information):** - Agent version (as shown in the 'Summary' tab of the agent from web UI): Agent v1.5.9 - Agent OS: Windows 10 Pro, 64 bit v20H2 (build 19042.1237) **Describe the bug** The script variables functionality exposes information that might not need to be exposed. **To Reproduce** Steps to reproduce the behavior: 1. Go to Script Manager and create a Create a PowerShell script. `Get-Timestamp` is a custom function to log the time, not a built-in cmdlet. ```powershell Write-Output "$(Get-Timestamp) Command Line arguments:", $($args) Write-Output "$(Get-Timestamp) Bound parameters:", $PsBoundParameters.Values ``` 2. Go to an agent and run the script on the agent. 3. The Script Arguments section allows variable substitution for various client/site/agent properties. This substitution process does not check if the property is an actual property or another method/function/class. 4. See screenshot for example. **Expected behavior** Methods and class names should not be exposed when running a script. **Screenshots** ![image](https://user-images.githubusercontent.com/7763429/134161898-34826623-aa62-43ad-8f22-b26e3c01291c.png) **Additional context** While this isn't a true security issue since Tactical doesn't have user permissions, this has the possibility of becoming something bad in the future. `{{client.Meta}}` exposes class names. `{{agent.make_model}}` returns the agent's make and model and is implemented as a method with `@property`, not an actual property. The other functions I checked return `bound method`. Some of these functions are return useful information. My concern is two fold: 1. A method may be implemented (in the future) that returns sensitive data when it shouldn't. For example, `agent.get_login_token`. 2. A method may execute code on the server resulting in data loss. For example, all three classes have a `save` method. Most of this is mitigated by Tactical returning the object representation as a string instead of executing the method and returning the results as a string. It would be nice if Tactical checked if the class property (script argument from the user) is an actual property or approved method and return nothing (or an error) if it's a class method not decorated as a `@property` or another class name.

kerem

2026-03-14 03:53:33 +03:00

closed this issue
added the
bug

security
labels

kerem commented

2026-03-14 03:53:49 +03:00

Author

Owner

@sadnub commented on GitHub (Sep 21, 2021):

That sounds like a feature to me! I don't think class names or other specifics in regards to the code is a concern because it is open source.

But like you said could lead to revealing sensitive information if a user of trmm wasn't supposed to view that. I think I am just using hasattr(obj, "prop_name") and getattr(obj, "prop_name"), so I can maybe do a check to see if the returned value is a function and not include that. I do want to keep the @property items exposed, because those could be useful

@sadnub commented on GitHub (Sep 21, 2021): That sounds like a feature to me! I don't think class names or other specifics in regards to the code is a concern because it is open source. But like you said could lead to revealing sensitive information if a user of trmm wasn't supposed to view that. I think I am just using hasattr(obj, "prop_name") and getattr(obj, "prop_name"), so I can maybe do a check to see if the returned value is a function and not include that. I do want to keep the @property items exposed, because those could be useful

kerem referenced this issue

2026-03-14 07:18:19 +03:00

[GH-ISSUE #2404] Settings for Privacy per Client/Site #3418