The get_app_path function in desktop/unx/source/start.c in LibreOffice through 6.0.5 mishandles the realpath function in certain environments such as FreeBSD libc, which might allow attackers to cause a denial of service (buffer overflow and application crash) or possibly have unspecified other impact if LibreOffice is automatically launched during web browsing with pathnames controlled by a remote web site. Upstream Bug: https://bugs.documentfoundation.org/show_bug.cgi?id=118514 Affected Code: https://github.com/LibreOffice/core/blob/master/desktop/unx/source/start.c#L191
Related to CVE-2018-11236
For one, that get_app_path is only called with argv[0] of LO's oosplash helper executable (installed at /usr/lib.../libreoffice/program/oosplash, called during the LO start-up sequence). So an attack would need launch that executable with a suitably long argv[0]. I don't see how that could happen "if LibreOffice is automatically launched during web browsing with pathnames controlled by a remote web site." (<https://nvd.nist.gov/vuln/detail/CVE-2018-14939>) For another, I don't see how that get_app_path uses realpath(3) wrongly. If there is an issue with the glibc implementation of realpath(3), as CVE-2018-11236 states, then it should be necessary and sufficient to fix the issue in glibc, and not in client code calling realpath(3), or am I missing something?
Neither do I see how can this cause buffer overflow on Linux. I also can't think of such attack scenario where a path name to oosplash can be controlled by remote web site. For CVE-2018-11236, you're right, that's indeed a separate issue in realpath implementation that might get potentially triggered using this code, but that's out of scope of LO and this issue.
Statement: This issue did not affect the versions of libreoffice as shipped with Red Hat Enterprise Linux 5, 6 and 7.