Potently unbounded buffer over-read in GNU Aspell 0.60.*

[Kevin Atkinson]

A potently unbounded buffer over-read was discovered in the Aspell library 
(ver. 0.60-60.7).  Applications that set the encoding to a known value (for 
example "utf-8") are not affected.

This vulnerability will be fixed in Aspell 0.60.8, but unfortunately, the fix 
will break applications that use null-terminated UCS-2 or UCS-4 strings with 
the C API.  These applications will need to be fixed to make use of the new 
more secure API in order to continue to have a functional spell checker. 
Most applications use UTF-8 strings and thus do not need to be fixed.

To give applications that will break a chance to be fixed, the fix is also 
available in a prerelease snapshot for 0.60.8 available at:
  https://alpha.gnu.org/gnu/aspell/aspell-0.60.8-20190817.tar.gz
It is fixed in rev de29341638833ba7717bd6b5e6850998454b044b in Aspell's git 
repo available at https://git.savannah.gnu.org/cgit/aspell.git and 
https://github.com/GNUAspell/aspell.  Although not required it is recommend 
you also apply cefd447e5528b08bb0cd6656bc52b4255692cefc to change the library 
version.  Fixed versions of the Aspell library should have a soname of at 
least 'libaspell.so.15.3.0'.


DESCRIPTION OF THE PROBLEM:

GNU Aspell supports working with wide character types, or put another way 
UCS-2 and UCS-4 Unicode text in the machines native endian order, but does not 
provide dedicated functions for doing so.  Instead, it expects the user to set 
the "encoding" config option to "ucs-2" or "ucs-4". The string is then 
expected to be cast to a `const char *` and the length of the string is 
expected to be in bytes.  If the length is -1 then Aspell expects the string 
to be null terminated.  If the encoding is UCS-2 or UCS-4 Aspell will expect 
the null terminator to be the width of the underlying encoding character type.

The problem is that, like most other config options, if this option is not 
explicitly set than Aspell can also get the "encoding" value from the 
environment or a config file.  If the encoding is set to "ucs-2" or "ucs-4" 
outside of the application and a normal null-terminated string (for example 
UTF-8) is used then there is a potentially unbounded buffer over-read as 
Aspell looks for the non-existent multi-byte null terminator.


IMPACT:

With the exception of the Aspell utility, most applications that use Aspell 
explicitly set the encoding to a fixed value so they will not be affected by 
this vulnerability. Applications that are affected are likely to crash fairly 
quickly but this is by no means guaranteed.  In addition, in order to exploit 
this vulnerability, the attacker would likely need to be able to modify the 
Aspell config file or the `ASPELL_CONF` environment variable before 
`new_aspell_speller` is called.  The Aspell utility is vulnerable, but as a 
stand-alone command-line utility the ability to gain access to sensitive 
information is limited.

The vulnerability affects all versions of Aspell since 0.60.


IMPACT OF FIX:

Application that use UCS-2/4 null terminated string with the C API will break 
when upgrading to Aspell 0.60.8.  The spell checker will cease to function but 
it should not cause the application to crash.  Functions that expect an 
encoded string as a parameter will return meaningless results or an error code 
when possible.  In addition, a single:

  ERROR: aspell_speller_check: Null-terminated wide-character strings 
unsupported when used this way.

will be printed to standard error the first time one of these functions is 
called.

Most applications use UTF-8 strings with the C API and thus do not need to be 
fixed.


OVERVIEW OF THE FIX:

In order to prevent the over-read from happening Aspell now disallows null 
terminated strings if the encoding is UCS-2 or UCS-4, unless separate 
functions are used that also pass in the width of character type.

As already indicated, this will unfortunately break existing applications that 
pass in UCS-2/4 null terminated string.  However, I do not see a way around 
this.  Aspell has no reliable way to determine if the config value was set to 
a fixed value in the source code or if it was set via some other means.  It is 
possible to determine if the value is set via the environment or a config 
file, but when it is set via the `aspell_config_replace` function but there is 
no reliable way to determine the intent of the programmer.  For example, the 
program could allow the user to set the encoding value via the U.I. or some 
other means and then use `aspell_config_replace`.


MIGRATION FOR EXISTING APPLICATIONS:

Once this vulanability is fixed Aspell will continue to function normally for 
most applications and nothing needs to be done.  For applications that use 
UCS-2/4 null-terminated string, there are several ways to fix the application, 
as documented in the manual:

  Application that use null-terminated UCS-2/4 strings should either (1) use
  the interface intended for working with wide-characters or (2) define
  'ASPELL_ENCODE_SETTING_SECURE' before including 'aspell.h'.  In the latter
  case is is important that the application explicitly sets the encoding to a
  known value.  Defining 'ASPELL_ENCODE_SETTING_SECURE' and not setting the
  encoding explicitly or allowing user of the application to set the encoding
  could result in an unbounded buffer over-read.

  If it is necessary to preserve binary compatibility with older versions of
  Aspell, the easiest thing would be to determine the length of the UCS-2/4
  string--in bytes--and pass that in.  Due to an implementation detail,
  existing API functions can be made to work with null-terminated UCS-2/4
  strings safely by passing in either '-2' or '-4' (corresponding to the width
  of the character type) as the size. Doing so, however, will cause a buffer
  over-read for unpatched version of Aspell.  To avoid this it will be
  necessary to parse the version string to determine the correct value to use.
  However, no official support will be provided for the latter method.

  If the application can not be recompiled, then Aspell can be configured to
  preserve the old behavior by passing '--enable-sloppy-null-term-strings' to
  'configure'.  When Aspell is compiled this way the version string will
  include the string ' SLOPPY'.

Please see the Aspell manual for additional information.


Kevin Atkinson,
Maintainer of GNU Aspell