Re: Can "gawk -i extension" be made safer?

[Stephane CHAZELAS]

2023-06-24 13:23:16 -0600, arnold@skeeve.com:
[...]
> The issue boils down to having a value of AWKPATH that you consider
> to be safe in the environment.  As gawk's behavior is thoroughly documented
> in the manual, and as gawk, like most Unix tools, assumes that users know
> what they are doing, it's up to the user to set an AWKPATH in their
> .profile or .bashrc that they are comfortable with.
[...]

Thanks. I confess that I've been using gawk -i inplace for years
without realising until now that it was looking for that inplace
first in the current working directory, and that I was
introducing security vulnerabilities in the process.

Like I discovered not so long ago that the default $PATH in the
GNU libc had been /bin:/usr/bin: (with the current directory as  the
last component) for decades even though it's been very well
known for years that $PATH should not contain relative paths. I
believe they have fixed it since.

It's my bad for not reading the manual, though in this instance
I didn't discover it by reading the manual, but by stumbling
upon /etc/profile.d/gawk.sh when reviewing the configuration of
a server.

I was finding it strange to find functions in there in a file
intended only for login shells to setup the login session
environment.

That:

gawkpath_default () {
        unset AWKPATH
        export AWKPATH=`gawk 'BEGIN {print ENVIRON["AWKPATH"]}'`
}

Also didn't make sense. How could gawk return the value of that
environment variable while  it was just unset beforehand? (BTW,
in bash, you need unset -v AWKPATH or that unset could unset a
AWKPATH function instead, also there's no point using backticks
as the only shell that doesn't support $(...) is the Bourne
shell which doesn't support export var=value either and that
command substitution must be quoted in some shells to prevent
IFS-splitting).

That's when I realised what it was returning and saw the
confirmation in the manual that it was as intended.

So now, please consider this fictional story:

I maintain some free software called line-number that is written
in gawk:

#! /usr/bin/gawk -E
BEGIN {
  if (ARGC <= 1) {
    print "Usage: line-number <file> [<file>...]" > "/dev/stderr"
    exit(1)
  }
}
@include "inplace"
{printf "%7d %s", FNR, $0 RT}

Now, yesterday, one of my users reported that their system had
been infected because they had run my software as root from
within /tmp, where there was a file called "inplace.awk" (even
though /tmp was mounted with noexec).

My software clearly has a security vulnerability and it's
entirely my fault for using that -i inplace without fully
reading the manual.

I can hardly blame the user for using such an unsafe value of
$AWKPATH (like I could if it was $PATH that had "." as the first
entry) as that happens to be the default value, and any way
removing "." from $AWKPATH breaks #! /usr/bin/awk -f or 
#! /usr/bin/gawk/-E scripts (though only in some corner cases).

Now, how do I fix it?

I'm already hardcoding the path of gawk in the shebang, so I might
as well hardcode the path to the extension:

@include "/usr/share/awk/inplace.awk"

Is that the recommended solution?

How about for scripts written as:

#! /usr/bin/env -S gawk -E
@include "inplace"
...

Where we don't know in advance where gawk is installed?

Should we replace it with:

#! /bin/sh -
export AWKPATH="$(LC_ALL=C gawk 'BEGIN {
  n = split(ENVIRON["AWKPATH"], dirs, ":")
  for (i = 1; i <= n; i++)
    if (substr(dirs[i], 1, 1) == "/") {
      newawkpath = newawkpath sep dirs[i]
      sep = ":"
    }
  print newawkpath}')"
if [ -z "$AWKPATH" ]; then
  echo>&2 "Can't find gawk extension library"
fi
exec gawk -i inplace -e '...' -E /dev/null "$@"


Now, how "fictional" is that story?

https://github.com/search?q=%22-i+inplace%22&type=code&p=2 a
github code search for "-i inplace" returns 1.4k hits.
Similar searches for comp.lang.awk or unix.stackexchange.com
also return hundreds of hits. I don't see many mentioning
$AWKPATH.

How many of these constitute security vulnerabilities or promote
something that introduce vulnerabilities? Can't we do something
about it?

-- 
Stephane