The guile-3.0(1) command-line interface is documented to take the filename
of a script to execute. Here's how well it understands filenames:
$ echo '(display "sadness") (newline)' > 'L?on.scm'
$ echo '(display "joy") (newline)' > $'L\xe9on.scm'
$ LC_ALL=C guile-3.0 --no-auto-compile $'L\xe9on.scm'
sadness
$ LC_ALL=de_DE.utf8 guile-3.0 --no-auto-compile $'L\xe9on.scm'
sadness
$ LC_ALL=de_DE.iso88591 guile-3.0 --no-auto-compile $'L\xe9on.scm'
joy
In this example I've created two different script files, with different
but related names, I've told guile-3.0(1) three times to run one
of them, and it's run the wrong one on two of the three attempts.
(The --no-auto-compile option doesn't affect the substantive result,
I'm just using it to avoid the noise that the caching system would
otherwise make.) In the invocations that ran the wrong file, one can see
via strace(1) that guile-3.0(1) doesn't use the correct filename for any
file operations at all; it completely substitutes the erroneous filename.
The use of the wrong filename doesn't depend on the file of that wrong
name existing: if there is no file of that name then guile-3.0(1) will
fail to find any script to execute, and will generate an error message
that shows the erroneous filename.
How guile-3.0(1) mangles the script filename on each invocation depends
on the locale implied by the environment, and more specifically on the
character encoding nominated by the LC_CTYPE component of the locale.
Nominating a locale that's not installed behaves the same as nominating
the C locale. Part of my example above depends on having the de_DE.utf8
and de_DE.iso88591 locales installed. If you don't have the specific
locales that I used then you can get the same results as me by
substituting an installed locale that nominates the same encoding.
This bug occurs in most cases where the supplied filename doesn't have
the syntax of locale-nominated encoding of text. (A different bug occurs
in some other cases of the supplied filename not having such syntax,
report to come.) The nature of the manglement is that each octet that
doesn't look like valid encoded text gets replaced with "?".
It appears that the supplied filename is being decoded, according
to the locale-nominated encoding, with decoding errors muffled and
"?" silently substituted in, and then the lossily-decoded filename is
re-encoded according to the locale-nominated encoding, and the result
of that process is the filename that gets actually used. As far as I
can see the manglement comes only from character decoding: there isn't
also any Unicode normalisation.
This could cause a security problem in some circumstances that are only
slightly strange. Suppose a privileged program is using guile-3.0(1)
to run scripts that partly derive from untrusted user input. Suppose the
program has created an innocuous script to run, has permitted an untrusted
user to determine part of the filename for that script, and has ensured
that the supplied filename is innocuous from a Unix point of view but
isn't preventing the use of filenames with high-half octets. Suppose
further that an untrusted user can cause the same program to create
another file, of content that the program doesn't intend to execute,
under the mangled name, which is almost as innocuous from a Unix point
of view. Then it could execute code determined by a malicious user,
due entirely to guile-3.0(1) misinterpreting a filename. I'm not aware
of any specific program that can be exploited in this way, and I haven't
based the declared severity of this bug report on this security issue.
Preferably, guile-3.0(1) should use the script file of the name that
was supplied on the command line. It must pass to the file syscalls
the same octet string that was supplied as a command line argument,
without assuming anything about its syntax.
If it cannot be made to handle arbitrary filenames correctly, then
guile-3.0(1) must at least detect that it can't handle the specified
filename. It must signal an error on any filename it can't handle, and
not use any mangled form of the filename for any purpose. Furthermore,
this limitation must be documented.