Impact
A use-after-free error in the GetData parser before version 0.11.0 can be exploited via a specially crafted format file to cause a segmentation fault within libgetdata. The checkdirfile utility provided in the GetData sources is affected by this vulnerability.
Explanation
In any Dirfile containing RAW fields, one of those RAW fields is designated as the Reference Field. The Reference Field is used to determine the length overall of the Dirfile as a whole. The Reference Field can be explicitly set via the /REFERENCE directive in the format metadata, but if it is not explicitly set, then an implicit Reference Field is chosen. The Dirfile Standards specify that the first RAW field defined in the format metadata shall be the implicit Reference Field, when no explicit Reference Field is provided.
If the first RAW field (hence the implicit Reference Field) has a name which duplicates the name of another field defined earlier in the format metadata, then in certain circumstances outlined below, the GetData parser in versions 0.10.0 and earlier will retain a reference (pointer) to the parsed metadata for this duplicate-named RAW field for use as the implicit Reference Field. This reference will remain even after the parser has destroyed the parsed metadata for this RAW field, which happens once it determines its name duplicates a previously-defined field.
In this case, a use-after-free error will subsequently occur if an attempt to access the Reference Field for the open Dirfile is attempted.
The GetData parser is invoked in two situations:
- By far the most common is when reading the format metadata when opening a new Dirfile (via
gd_open(3) or similar).
- The parser is also invoked when adding a new format fragment to an existing open Dirfile (via
gd_include(3)). In this case, the vulnerability can only be triggered if the Dirfile to which the new fragment is being added has no Reference Field already, which can only be if it has no RAW fields.
In the parser's default operational mode, encountering a field with a duplicate name results in a fatal error, causing the operation (Dirfile open or fragment inclusion) to fail. In this case, the vulnerability cannot be triggered.
The vulnerability can only be triggered when the parser is told to suppress the fatal error normally generated when encountering duplicate field names. This is possible two ways:
- Using the
GD_IGNORE_DUPS flags.
- Using a parser callback to change the parser's response to the duplicate field name error. This is what happens in the
checkdirfile utility, which is why it is affected by this vulnerability.
Patches
This vulnerability has been fixed in GetData-0.11.0. All users are encouraged to upgrade.
Workarounds
Users unable to upgrade are encouraged to remove uses of the GD_IGNORE_DUPS flag and to never suppress duplicate field name errors for RAW fields in parser callbacks. This vulnerability may also be mitigated by explicitly setting a Reference Field (with gd_reference(3)) before attempting to access an open Dirfile.
References
Impact
A use-after-free error in the GetData parser before version 0.11.0 can be exploited via a specially crafted format file to cause a segmentation fault within libgetdata. The
checkdirfileutility provided in the GetData sources is affected by this vulnerability.Explanation
In any Dirfile containing RAW fields, one of those RAW fields is designated as the Reference Field. The Reference Field is used to determine the length overall of the Dirfile as a whole. The Reference Field can be explicitly set via the
/REFERENCEdirective in the format metadata, but if it is not explicitly set, then an implicit Reference Field is chosen. The Dirfile Standards specify that the first RAW field defined in the format metadata shall be the implicit Reference Field, when no explicit Reference Field is provided.If the first RAW field (hence the implicit Reference Field) has a name which duplicates the name of another field defined earlier in the format metadata, then in certain circumstances outlined below, the GetData parser in versions 0.10.0 and earlier will retain a reference (pointer) to the parsed metadata for this duplicate-named RAW field for use as the implicit Reference Field. This reference will remain even after the parser has destroyed the parsed metadata for this RAW field, which happens once it determines its name duplicates a previously-defined field.
In this case, a use-after-free error will subsequently occur if an attempt to access the Reference Field for the open Dirfile is attempted.
The GetData parser is invoked in two situations:
gd_open(3)or similar).gd_include(3)). In this case, the vulnerability can only be triggered if the Dirfile to which the new fragment is being added has no Reference Field already, which can only be if it has no RAW fields.In the parser's default operational mode, encountering a field with a duplicate name results in a fatal error, causing the operation (Dirfile open or fragment inclusion) to fail. In this case, the vulnerability cannot be triggered.
The vulnerability can only be triggered when the parser is told to suppress the fatal error normally generated when encountering duplicate field names. This is possible two ways:
GD_IGNORE_DUPSflags.checkdirfileutility, which is why it is affected by this vulnerability.Patches
This vulnerability has been fixed in GetData-0.11.0. All users are encouraged to upgrade.
Workarounds
Users unable to upgrade are encouraged to remove uses of the
GD_IGNORE_DUPSflag and to never suppress duplicate field name errors for RAW fields in parser callbacks. This vulnerability may also be mitigated by explicitly setting a Reference Field (withgd_reference(3)) before attempting to access an open Dirfile.References