Parsing of script arguments can interpret a string starting with $ as variable name

[MarikaChlebowska]

Describe the bug

While working on PR (#11030) I've noticed some different edge cases with script argument parsing. Using the script from the issue I worked on (#10908) with an argument that starts with $ leads to interpreting it as a variable name.

As a clue where to look at I debugged it a little bit and the script arguments go through parsing process 2 times. First they are parsed, then escape_for_script_arg is called and they're parsed again. When the second parsing process begins quotation marks are stripped already so it's reinterpreted as if it was passed without them if I understand the logic there correctly.

How to reproduce

1. Create echo.nu script:

def main [input: string] {
    print $input
}

2. Run it with an explicit string starting with $ and not containing any white spaces

> nu echo.nu "$foo"                                                                                                                                                                                                                                1 11/12/23 11:38:53 AM
Error: nu::parser::variable_not_found

  × Variable not found.
   ╭─[<commandline>:1:1]
 1 │ main $foo
   ·      ──┬─
   ·        ╰── variable not found. 
   ╰────

Expected behavior

With give input $foo should be printed.

Screenshots

No response

Configuration

key	value
version	0.86.1
branch	main
commit_hash	77fbf3e
build_os	linux-x86_64
build_target	x86_64-unknown-linux-gnu
rust_version	rustc 1.71.1 (eb26296b5 2023-08-03)
rust_channel	1.71.1-x86_64-unknown-linux-gnu
cargo_version	cargo 1.71.1 (7f1d04c00 2023-07-29)
build_time	2023-11-12 11:45:47 +01:00
build_rust_channel	debug
allocator	mimalloc
features	default, sqlite, trash, which, zip
installed_plugins

Additional context

No response

[MarikaChlebowska]

I don't want to create another issue so there is one other error with arg parsing I found, a string with backtick crashes the script, the same happens with single quotation mark (')

> nu echo.nu "123`"                                                                                                                                                                                                                                          1 11/12/23 13:45:17 PM
Error: nu::parser::unexpected_eof

  × Unexpected end of code.
   ╭─[<commandline>:1:1]
 1 │ main 123`
   ╰────

[MarikaChlebowska]

To be honest I think the function escape_for_script_arg can't handle many edge cases and I'd be happy to work on it when I have some time.

[DonSheddow]

This is a more serious issue than what it seems. You can achieve code execution by running nu echo.nu "\$'(ls)'" from bash (or nu echo.nu "$'(ls)'" on windows cmd), and similarly nu echo.nu '$env' actually prints all environment variables. Depending on how nu is used, this can lead to remote code execution.

As @MarikaChlebowska discovered, the command line arguments are actually parsed twice; first to Vec<String> in gather_commandline_args() where escape_for_script_arg() is used, then the Vec is joined to a string which is then evaluated directly in eval_source(). It seems the whole point of escape_for_script_arg is to prevent arguments to be interpreted as code in eval_source, but this is obviously not good enough. It seems like a better, less roundabout solution is to just skip the escaping step and pass the arguments directly as Value::Strings to main if possible.

As an example for how this can be exploited, using

#!/usr/bin/env nu
def main [input: string] {
    print $input
}

as a CGI script should be completely harmless, but this opens you up to remote code execution. Nu scripts are usually not exposed to the internet of course, but this can also be used for local privilege escalation.