Note that I am not the maintainer but another list member.
> When using cat on some files, the files put stuff on the commnand line
> that gets executed the next time you hit return.
> Here is an example with my prompt set to XXX for clarity
> I first cat -A the file to show what special characters the file contains.
> Note that the high bit is set. vi shows this as ~Z
> XXXcat -A junk
> M-^Z$
> XXXcat junk
>
> ^[[?1;2cXXX1;2c
> 1: Command not found.
> 2c: Command not found.
> XXX
This looks like the file "junk" contains terminal escape sequences
that places characters into the input buffer. It was not clear to me
exactly what characters existed in that file. Which made it difficult
for me to exactly recreate your test case. But in that case why wait
for a return? It could easily place a return in the input buffer as
well and execute the commands immediately without needing the user to
type a return.
> This could potentially be a security problem if there was a command called
> 2c or just 1 (Yeah, minor but cat shouldn't execute stuff none the less,
> and I did not look into other high bit characters).
So far I see nothing that leads me to believe that cat is doing
anything other than it should be doing. The security problem exists
with smart terminals that allow characters to be stuffed into the
input stream. Attacks on them have been around for a long time so
this is nothing new. This is why 'mesg n' is needed to turn off
terminal write permission. Otherwise users could write to other users
terminals and execute commands as them. Gaining access to the root
terminal is equivalent to gaining root access on a host.
What I see is that your security issue is that if a user copies a
compromised file to the terminal that it could execute commands as the
user. But the user would need to give this capability to the file by
cat'ing it to the screen directly. Saying that you should never copy
a suspect file directly to the terminal is like saying you should
never execute a program that was mailed to you from an unknown person.
The two have the same capability for mayhem.
> We find this on both Alpha linux and x86 linux (both redhat).
>
> Kurt Glaesemann
>
> p.s. This bug does not exist in vendor supplied versions of cat on AIX and
> IRIX.
I suspect that the terminal type is different and/or the stty settings
are different which is masking to 7-bits or some other perturbation
which is adding noise to the data and preventing the test case from
being exactly the same on both boxes. The cat program itself has no
special capability beyond what the user can piece together from other
forms. Think about using "grep . junk" as a replacement for "cat
junk" as one example.
Bob Proulx
