CVE-2022-43467
An out-of-bounds write vulnerability exists in the PQS format coord_file functionality of Open Babel 3.1.1 and master commit 530dbfa3. A specially crafted malformed file can lead to arbitrary code execution. An attacker can provide a malicious file to trigger this vulnerability.
The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.
Open Babel 3.1.1
Open Babel master commit 530dbfa3
Open Babel - https://openbabel.org/
9.8 - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer
Open Babel is a popular library for converting chemical file formats, currently supporting about 130 different file formats. It implements bindings for several programming languages. Because of the nature of the library, and since there are many online chemical format converters and molecule viewers which might be using Open Babel in their backend for parsing and conversion, we consider this software as potentially accessible via network.
Open Babel ships a simple converter application called obabel that can be used to trigger the issue described in this advisory. obabel supports -i and -o parameters, which select the input and output formats to perform the conversion. obabel supports multiple input and output files (as does the Open Babel library itself): this technically allows multiple vulnerabilities to trigger in sequence, which in turn could make some vulnerabilities easier to exploit. In this advisory, however, we focus on only one input file and a corresponding output file.
When a single input file and output file are supplied, obabel.cpp records the input and output formats (if supplied) and calls OBConversion::FullConvert in obconversion.cpp. Inside this function, there’s a call to OpenAndSetFormat, which uses FormatFromExt to derive the input format from the filename extension if no -i parameter was supplied. Similarly, OpenInAndOutFiles can be used to derive both input and output formats from the filename extensions when none are supplied.
Depending on how the obabel application is invoked, different paths could actually take place. Eventually, pInFormat and pOutFormat (of base class OBFormat) objects are allocated, which are instances of the classes that implement the selected input and output formats.
The code then proceeds with a call to OBConversion::Convert, which eventually leads to calling pInFormat->ReadMolecule and pOutFormat->WriteMolecule.
In this advisory, we describe an issue in the “Parallel Quantum Solutions” (PQS) file format (formats/PQSformat.cpp.cpp) when parsing an input file via ReadMolecule.
bool PQSFormat::ReadMolecule(OBBase* pOb, OBConversion* pConv)
{
...
[7] const char* title = pConv->GetTitle();
char buffer[BUFF_SIZE];
char coord_file[256];
char full_coord_path[256]="\0";
...
[1] while (!geom_found && ifs.getline(buffer,BUFF_SIZE))
{
lowerit(buffer); //look for geom except in title or text
[2] if (strstr(buffer, "geom") != nullptr &&
(strncmp(buffer,"text",4)!=0 && strncmp(buffer,"titl",4)!=0))
{
geom_found=true;
lowerit(buffer);
...
[3] if (strstr(buffer, "file=") != nullptr)
{ //external geometry file
[4] strncpy(coord_file,strstr(buffer,"file=")+5, sizeof(coord_file));
coord_file[sizeof(coord_file) - 1] = '\0';
if (strrchr(coord_file, ' ') != nullptr)
*strrchr(coord_file,' ')='\0';
[5] if (coord_file[0]!='/')
{
[6] strncpy(full_coord_path,title, sizeof(full_coord_path));
full_coord_path[sizeof(full_coord_path)-1] = '\0';
if (strrchr(full_coord_path, '/') != nullptr)
*(strrchr(full_coord_path,'/')+1)='\0';
else
full_coord_path[0] = '\0';
}
[8] strcat(full_coord_path,coord_file);
full_coord_path[sizeof(full_coord_path) - 1] = '\0';
At [1] the code loops over each line in the file. If the current line contains “geom” and no “text” or “titl” strings, the condition at [2] matches. If the line also contains “file=”, the coord_file buffer is filled with whatever comes next. At [5], if coord_file does not start with “/”, the title’s directory path is put into full_coord_path [6].
The title is retrieved at [7] using the function below, which simply returns the input filename:
const char* OBConversion::GetTitle() const
{
return(InFilename.c_str());
}
At [8], coord_file is concatenated to full_coord_path. The issue is that both coord_file and full_coord_path have a maximum size of 256. coord_file can be filled completely at [4], and the same is true for full_coord_path at [6]. This means that the strcat at [8] can write out-of-bounds of full_coord_path (stored on the stack), which, depending on how the code is compiled and the stack is laid out, can in turn lead to arbitrary code execution.
$ ./bin/obabel -i pqs strcat.pqs -o sdf
=================================================================
==1278108==ERROR: AddressSanitizer: stack-buffer-overflow on address 0xffff3410 at pc 0xf79dd381 bp 0xffff2ae8 sp 0xffff26c0
WRITE of size 251 at 0xffff3410 thread T0
#0 0xf79dd380 in __interceptor_strcat ../../../../src/libsanitizer/asan/asan_interceptors.cpp:377
#1 0xf4f50969 in OpenBabel::PQSFormat::ReadMolecule(OpenBabel::OBBase*, OpenBabel::OBConversion*) ./src/formats/PQSformat.cpp:234
#2 0xf751a915 in OpenBabel::OBMoleculeFormat::ReadChemObjectImpl(OpenBabel::OBConversion*, OpenBabel::OBFormat*) ./src/obmolecformat.cpp:102
#3 0xf63c358c in OpenBabel::OBMoleculeFormat::ReadChemObject(OpenBabel::OBConversion*) ./include/openbabel/obmolecformat.h:116
#4 0xf72a204e in OpenBabel::OBConversion::Convert() ./src/obconversion.cpp:545
#5 0xf72c717a in OpenBabel::OBConversion::Convert(std::istream*, std::ostream*) ./src/obconversion.cpp:481
#6 0xf72cf4f3 in OpenBabel::OBConversion::FullConvert(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) ./src/obconversion.cpp:1514
#7 0x565594ea in main ./tools/obabel.cpp:370
#8 0xf77923b4 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#9 0xf779247e in __libc_start_main_impl ../csu/libc-start.c:389
#10 0x5655c356 in _start (./bin/obabel+0x7356)
Address 0xffff3410 is located in stack of thread T0 at offset 2128 in frame
#0 0xf4f4e08f in OpenBabel::PQSFormat::ReadMolecule(OpenBabel::OBBase*, OpenBabel::OBConversion*) ./src/formats/PQSformat.cpp:178
This frame has 43 object(s):
[48, 49) '<unknown>'
[64, 65) '<unknown>'
[80, 81) '<unknown>'
[96, 97) '<unknown>'
[112, 113) '<unknown>'
[128, 129) '<unknown>'
[144, 145) '<unknown>'
[160, 161) '<unknown>'
[176, 177) '<unknown>'
[192, 193) '<unknown>'
[208, 212) '<unknown>'
[224, 228) '<unknown>'
[240, 244) '<unknown>'
[256, 260) '<unknown>'
[272, 276) '<unknown>'
[288, 292) '__guard'
[304, 308) '__dnew'
[320, 324) '__guard'
[336, 340) '__guard'
[352, 356) '<unknown>'
[368, 372) '<unknown>'
[384, 388) '<unknown>'
[400, 404) '<unknown>'
[416, 420) '<unknown>'
[432, 436) '__guard'
[448, 452) '__dnew'
[464, 468) '__guard'
[480, 484) '__guard'
[496, 520) '<unknown>'
[560, 584) '<unknown>'
[624, 648) '<unknown>'
[688, 712) '<unknown>'
[752, 776) '<unknown>'
[816, 840) '<unknown>'
[880, 904) '<unknown>'
[944, 968) '<unknown>'
[1008, 1216) 'errorMsg' (line 236)
[1280, 1488) 'errorMsg' (line 298)
[1552, 1808) 'coord_file' (line 190)
[1872, 2128) 'full_coord_path' (line 191)
[2192, 2452) 'coordconv' (line 253) <== Memory access at offset 2128 partially underflows this variable
[2528, 2808) 'coordFileStream' (line 192)
[2880, 35648) 'buffer' (line 189)
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow ../../../../src/libsanitizer/asan/asan_interceptors.cpp:377 in __interceptor_strcat
Shadow bytes around the buggy address:
0x3fffe630: 00 00 f2 f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00
0x3fffe640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x3fffe650: 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 f2 f2
0x3fffe660: f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x3fffe670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x3fffe680: 00 00[f2]f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00
0x3fffe690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x3fffe6a0: 00 00 00 00 00 00 00 00 00 00 04 f2 f2 f2 f2 f2
0x3fffe6b0: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
0x3fffe6c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x3fffe6d0: 00 00 00 00 00 00 00 f2 f2 f2 f2 f2 f2 f2 f2 f2
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Since the maintainer of this software did not release a patch during the 90 day window specified in our policy, we have now decided to release the information regarding this vulnerability, to make users of the software aware of this problem. See Cisco’s Coordinated Vulnerability Disclosure Policy for more information: https://tools.cisco.com/security/center/resources/vendor_vulnerability_policy.html
2022-12-20 - Initial Vendor Contact
2023-01-12 - Vendor Disclosure
2023-07-21 - Public Release
Discovered by Claudio Bozzato of Cisco Talos.