[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[aspell-devel] Potently unbounded buffer over-read in GNU Aspell 0.60.*
From: |
Kevin Atkinson |
Subject: |
[aspell-devel] 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:
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [aspell-devel] Potently unbounded buffer over-read in GNU Aspell 0.60.*,
Kevin Atkinson <=