File: https://github.com/LibreOffice/core/blob/master/desktop/unx/source/start.c#L191 This function does not protect against buffer overflows, and some implementations can overflow internally. Ensure that the destination buffer is at least of size MAXPATHLEN, andto protect against implementation problems, the input argument should also be checked to ensure it is no larger than MAXPATHLEN. According to the documentation of realpath() the output buffer needs to be at least of size PATH_MAX specifying output buffers large enough to handle the maximum-size possible result from path manipulation functions.
Hello Dhiraj, Thank you for the analysis. Would you like to submit a patch for this problem? You can find information on how to do it here -> https://wiki.documentfoundation.org/Development/gerrit
@Stephan, I thought you could be interested in this issue...
(In reply to Dhiraj from comment #0) > File: > https://github.com/LibreOffice/core/blob/master/desktop/unx/source/start. > c#L191 i.e., dummy = realpath(pPath, pRealPath); > This function does not protect against buffer overflows, and some > implementations can overflow internally. > > Ensure that the destination buffer is at least of size MAXPATHLEN, andto > protect against implementation problems, the input argument should also be > checked to ensure it is no larger than MAXPATHLEN. What is MAXPATHLEN? What platform are you talking about? At least SUSv4 doesn't have any such requirements on realpath(3), nor does it mention MAXPATHLEN. > According to the documentation of realpath() the output buffer needs to be > at least of size PATH_MAX specifying output buffers large enough to handle > the maximum-size possible result from path manipulation functions. ...and pRealPath is of sufficient size, see char pRealPath[PATH_MAX]; a few lines further up. Or what am I missing?
(In reply to Stephan Bergmann from comment #3) > (In reply to Dhiraj from comment #0) > > File: > > https://github.com/LibreOffice/core/blob/master/desktop/unx/source/start. > > c#L191 > > i.e., > > dummy = realpath(pPath, pRealPath); > > > This function does not protect against buffer overflows, and some > > implementations can overflow internally. > > > > Ensure that the destination buffer is at least of size MAXPATHLEN, andto > > protect against implementation problems, the input argument should also be > > checked to ensure it is no larger than MAXPATHLEN. > > What is MAXPATHLEN? What platform are you talking about? At least SUSv4 > doesn't have any such requirements on realpath(3), nor does it mention > MAXPATHLEN. > > > According to the documentation of realpath() the output buffer needs to be > > at least of size PATH_MAX specifying output buffers large enough to handle > > the maximum-size possible result from path manipulation functions. > > ...and pRealPath is of sufficient size, see > > char pRealPath[PATH_MAX]; > > a few lines further up. Or what am I missing? In FreeBSD libc
(In reply to Dhiraj from comment #4) > In FreeBSD libc If the current code doesn't fulfil some FreeBSD-specific requirement, you can send a patch (<https://wiki.documentfoundation.org/Development/gerrit>) with the necessary additional code in #if defined FREEBSD blocks.
(In reply to Dhiraj from comment #4) > In FreeBSD libc Assuming this alludes to <https://nvd.nist.gov/vuln/detail/CVE-2018-11236> about "stdlib/canonicalize.c in the GNU C Library", lets close this as NOTOURBUG. (Also see the discussion at <https://bugzilla.redhat.com/show_bug.cgi?id=1614165> "CVE-2018-14939 libreoffice: Use of realpath() in desktop/unx/source/start.c:get_app_path() allows for potential buffer overflow".)