bug#27270: display-raw-bytes-as-hex generates ambiguous output for Emacs strings

[Lars Ingebrigtsen <larsi@gnus.org>]

Paul Eggert <eggert@cs.ucla.edu> writes:

>> The likelihood of anybody actually encountering this issue is ... small.
>
> Sure, if strings are random. But strings from opponents aren't random.
>
> I'll readily grant that it's a much smaller exposure than SQL
> injection. Still, like SQL injection it's an exposure and should be
> fixed.

The opponent would have to get somebody to start an Emacs with -nw, then
cut and paste a string with the mouse, then get the user to use the Lisp
reader to read that string in again, and then end up with a string that
will somehow be a security issue.

Comparing this to SQL injection is far fetched, to put it mildly.

We have a similar issue with the octal printer -- if you print something
out with it, and you end up with something displayed as foo\205bar, you
cut and paste that from -nw, and you save it into a file, you end up
with a file containing 10 characters instead of 8, and then you have
your exploit.

I.e., the Lisp reader and strings isn't the only thing confusable here.

>> what about (format "%cf" #x9e)
>
> Since that returns a multibyte string, I suggest "\u009ef" which is
> multibyte. For its unibyte counterpart (encode-coding-string (format
> "%cf" #x9e) 'iso-latin-1) I suggest the syntax "\x9e\ f" which is
> unibyte. (These are not the only possibilities; for example, the
> former could be "\u009e\ f" if you think that's clearer.)

display-raw-bytes-as-hex is a display setting.  You want to change it so
that the data output will be different, which will break all kinds of
things, even if (when you use the Lisp reader) it'll end up being the
same.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no