[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kevin Atkinson
Subject: Potently unbounded buffer over-read in GNU Aspell 0.60.*
Date: Sat, 17 Aug 2019 23:16:15 -0400 (EDT)
User-agent: Alpine 2.11 (DEB 23 2013-08-11)

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:
It is fixed in rev de29341638833ba7717bd6b5e6850998454b044b in Aspell's git repo available at and 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 ''.


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.


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.


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 


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`.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]