From: Kevin Atkinson Date: Sat, 17 Aug 2019 23:16:15 Subject: Potently unbounded buffer over-read in GNU Aspell 0.60.* 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 with the original API. To use null-terminated UCS-2/4 strings separate functions need to be used so that the width of the underlying character type is also passed in. 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 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 call `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 [Edited August 18 & 19 for clarity. Original version: https://lists.gnu.org/archive/html/aspell-announce/2019-08/msg00000.html]