Re: Emacs Lisp's future

[Eli Zaretskii]

> Date: Thu, 9 Oct 2014 00:49:17 -0400
> From: Mike Gerwitz <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden, address@hidden,
>       address@hidden, address@hidden, address@hidden,
>       address@hidden
> 
> On Thu, Oct 09, 2014 at 12:56:42PM +0900, Stephen J. Turnbull wrote:
> > Richard Stallman writes:
> > 
> >  > If you demonstrate that this claim is valid, I will be concerned.
> > 
> > *sigh*  Be unconcerned.  The world is a *lot* more hostile today than
> > it was in the days when you posted your passwords on the 'net.
> 
> Agreed. Character encoding attacks are also something that has been
> exploited "in the wild". Some examples include:
> 
>   - UTF-7 character encoding to bypass filters[0] (e.g. for XSS);
>   - IIS WebDAV validation exploit (CVE-2009-1535);[1] and
>   - CAPEC-80: Using UTF-8 Encoding to Bypass Validation Logic;[2] and
>   - Google's XSS vulnerability, related to the first item in this list.[3]
> 
> Note that not all of the above may be applicable to the specifics of this
> discussion---the point is to convey, generally, that character encoding
> poses serious threats when improperly handled. Though this discussion seems
> to be about what is "improper".

Aren't you again confusing the application level with the lower
"engine" level?  Applications, which do interpret the text, should
indeed be aware of these issues.  (For the purposes of this
discussion, "application" means Lisp code that processes text, or
presents it to the user, or acts according to user responses.)  But
the "engine" must be able to handle raw bytes, including invalid UTF-8
sequences, unless told otherwise.  Any other default will unduly
punish the innocent majority on behalf of the evil minority.

> With regards to passing raw input to other systems: this isn't necessarily
> Unicode related (unless an invalid sequence contains a null byte), but
> serves to illustrate the point that Mark is trying to make: there is a
> well-known issue in PHP whereby passing a null byte as a parameter to a
> script (e.g. via HTTP GET/POST) opens up a number of attacks.  Specifically,
> PHP handles null bytes in strings (by storing the string length as part of
> the struct that holds the string). However, it makes calls directly to libc.
> So, if an unvalidated input $foo contains "../../../../etc/group\000", and
> PHP makes a call to `fopen' with the path "/webroot/modules/$foo/index.php",
> the result would be opening "/webroot/modules/../../../../etc/group".

So what would you have Emacs do when I'm editing a file with binary
nulls: ask me for each save whether I really mean it, and lecture me
about possible security implications?  The encoding routines have no
idea whether they are encoding a PHP script, much less whether it will
be sent via HTTP.

> I can dig up more examples, but hopefully some of these help to illustrate
> the severity of ignoring character encoding concerns.

Please do, but (a) please make the examples be relevant to what Emacs
does with decoding and encoding external bytestreams, and (b) please
suggest what you think Emacs should do in those cases instead of what
it does now.  Otherwise, this discussion is much less constructive
than it could be, because our concerns are with how the discussed
issues will or should affect Emacs.