Bug 115486 - LibreOffice shouldn't require writable and executable memory pages at the same time
Summary: LibreOffice shouldn't require writable and executable memory pages at the sam...
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Memory
  Show dependency treegraph
 
Reported: 2018-02-06 10:55 UTC by hessnovTHR44
Modified: 2020-02-05 03:37 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description hessnovTHR44 2018-02-06 10:55:47 UTC
Description:
https://stackoverflow.com/questions/48631646/why-does-libreoffice-wants-memory-pages-to-be-writable-and-executable-in-the-sam

OpenBSD has great features for Memory protection, ex.: W^X.

https://en.wikipedia.org/wiki/W^X

https://man.openbsd.org/mount

We can disable this function with the "wxallowed" mount point if a program needs it, and sadly, LibreOffice needs the wxallowed on /usr/local/. 

See example here: https://unix.stackexchange.com/questions/411405/libreoffice-soffice-oosplash-start-permission-denied-error

Steps to Reproduce:
1. Use a secure OS that can help security audits, ex.: OpenBSD
2. Remove the wxallowed flag from /usr/local to enable the W^X enforcing, reboot
3. LibreOffice cannot start anymore, because it requires writable and executable memory pages in the same time, see Wiki link, why is this dangerous: https://en.wikipedia.org/wiki/W%5EX

Actual Results:  
LibreOffice is prone to memory bugs if it needs writable/executable memory pages

Expected Results:
LibreOffice should run even with the remove wxallowed mount option. 


Reproducible: Always


User Profile Reset: No



Additional Info:
This is a security issue, please fix it with higher prio. 

Additional help from the forums: 

I'm not really sure but my guess is that LibreOffice is doing some dynamic runtime linking of a shared object and it's mapping the whole address space using one syscall with PROT_READ|PROT_WRITE|PROT_EXEC or alternatively PROT_ALL which i have already seen somewhere on github. – Karim Manaouil

@KarimManaouil Probably here: 

https://github.com/LibreOffice/core/blob/b7c5ddcdd05ceba73acb1a298500892d6157f360/bridges/source/cpp_uno/shared/vtablefactory.cxx

It creates anonymous mapping with RWX access. – Ivan 


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Comment 1 Julien Nabet 2018-02-06 11:24:12 UTC
I confirm your findings.
On master sources updated today, 
git grep -n 'PROT_ALL' * returns nothing

git grep -n 'PROT_WRITE' * gives:
bridges/source/cpp_uno/shared/vtablefactory.cxx:82:        nullptr, n, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1,
bridges/source/cpp_uno/shared/vtablefactory.cxx:87:    else if (mprotect (p, n, PROT_READ | PROT_WRITE | PROT_EXEC) == -1)
bridges/source/cpp_uno/shared/vtablefactory.cxx:275:        block.start = mmap(nullptr, block.size, PROT_READ | PROT_WRITE, MAP_SHARED, block.fd, 0);
external/hunspell/0001-Revert-Remove-autotools-autogenerated-files.patch:24139:+  data2 = (char *) mmap (0, pagesize, PROT_READ | PROT_WRITE, MAP_SHARED, fd2, 0L);
external/hunspell/0001-Revert-Remove-autotools-autogenerated-files.patch:24155:+  if (data2 != mmap (data2, pagesize, PROT_READ | PROT_WRITE,
sal/rtl/alloc_arena.cxx:1063:    addr = mmap (nullptr, static_cast<size_t>(size), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);

So, there's only the second line (already quoted by reporter), see https://opengrok.libreoffice.org/xref/core/bridges/source/cpp_uno/shared/vtablefactory.cxx#87

It's been like this since 2006, see https://cgit.freedesktop.org/libreoffice/core/commit/?id=dca1c17b960e40c824fd396242acbee1eb2e97f5

Stephan/Mike: noticing your last commit on this file, thought you might be interested in this one.
Comment 2 Stephan Bergmann 2018-02-06 12:39:05 UTC
LO does some native code generation at runtime (for the bridge between C++ and binary UNO).  There is USE_DOUBLE_MMAP to not have to map those pages as rwx, but rather to split that into w and rx access.  This is enabled for LINUX and the various *BSD in bridges/inc/vtablefactory.hxx.

The relevant code is VtableFactory::createBlock in bridges/source/cpp_uno/shared/vtablefactory.cxx.  For performance reasons, it first tries to allocate rwx pages, via rtl_arena_alloc calling allocExec (at the top of that vtablefactory.cxx).  If that fails (because rwx is forbidden by the OS), VtableFactory::createBlock goes on to do the double mmap.

But this code should not be executed by the oosplash process.  (It will be executed e.g. by the soffice.bin process, though.)  You would need to debug oosplash further to find out why it fails with "permission denied" for you.

(Julien, not sure why you set this from UNCONFIRMED to NEW.  I don't think your argument for doing so is sound.)
Comment 3 Julien Nabet 2018-02-06 12:43:29 UTC
Thank you for your very detailed feedback Stephan.
I had put it at NEW since the code showed indeed the use of write and exec flags.
Now if you say that's normal, no pb. I must recognize I'm not expert at all on this subject.
Let's revert back to UNCONFIRMED then.
Don't hesitate to update to a more appropriate status.
Comment 4 hessnovTHR44 2018-02-06 14:20:55 UTC
Can I / Should I open a new bug for oosplash / soffice? 

Or can we inform someone that maintans them, to see this bug? 

Many thanks!
Comment 5 Stephan Bergmann 2018-02-06 15:03:17 UTC
(In reply to hessnovTHR44 from comment #4)
> Can I / Should I open a new bug for oosplash / soffice? 
> 
> Or can we inform someone that maintans them, to see this bug? 

I'm not sure what you mean with either of those two questions.

The essence of your problem description in this bug's comment 0 is something like, "on OpenBSD with W^X enforced, starting LO fails with 'Permission denied' in oosplash", while this bug's title looks like guesswork to me.  I think it's best if you make the title match the problem description.

And if you don't want to debug the problem yourself, lets hope that somebody who knows how to do so comes across this bug, or you can point people in some OpenBSD-specific channel at it.
Comment 6 sthen 2018-02-13 15:55:15 UTC
Hi, OpenBSD ports dev here.

The reporter is confused about how the mechanism works on recent OpenBSD. W+X mappings are rejected unless an executable has OPENBSD_WXNEEDED in the ELF program header. Executables marked in this way will always get EPERM immediately at startup unless the filesystem holding them was mounted with the "wxallowed" flag.

I haven't investigated this (and to be honest don't have time to do so at present) but if LibreOffice itself is doing shadow mappings (USE_DOUBLE_MMAP), it's quite possible that the flag is set due to use of Java (the normal method of getting the flag set is by a linker flag, and in ports the standard method is to use a wrapper "ld" script to add the flag, so all executables from that port will be so marked).

In any event simply disabling wxallowed on the mount point is not giving any useful information, it is guaranteed that a program linked in this way will fail to start. A proper test would be to build without setting the linker flag and then see what (if anything) fails.
Comment 7 hessnovTHR44 2018-02-13 21:34:16 UTC
Thanks for your helpful hints that would lead to fixing this W^X related crash in LibreOffice. 

Thanks!
Comment 8 Jean-Baptiste Faure 2018-03-11 07:41:10 UTC
So, is the unconfirmed status still appropriate for this bug report ?

Best regards. JBF
Comment 9 Stephan Bergmann 2018-03-12 09:04:52 UTC
(In reply to Jean-Baptiste Faure from comment #8)
> So, is the unconfirmed status still appropriate for this bug report ?

Somebody involved in the LO OpenBSD port would need to answer that.
Comment 10 Buovjaga 2018-03-13 13:42:58 UTC
(In reply to sthen from comment #6)
> A proper test would be to build without setting the linker
> flag and then see what (if anything) fails.

hessnovTHR44: can you try it?
Comment 11 hessnovTHR44 2018-04-04 15:12:16 UTC
"A proper test would be to build without setting the linker flag and then see what (if anything) fails."

Can someone please help me that what "linker flag" should I use when building/testing LibreOffice? 

If I would know it, then I can help!

Many thanks.
Comment 12 Xisco Faulí 2018-11-27 20:07:32 UTC
(In reply to hessnovTHR44 from comment #11)
> Can someone please help me that what "linker flag" should I use when
> building/testing LibreOffice? 
> 
> If I would know it, then I can help!


@Stephan Bergmann, do you know it ?
Comment 13 Stephan Bergmann 2018-11-28 09:02:40 UTC
(In reply to Xisco Faulí from comment #12)
> @Stephan Bergmann, do you know it ?

no
Comment 14 Buovjaga 2018-11-28 10:34:36 UTC
(In reply to hessnovTHR44 from comment #11)
> "A proper test would be to build without setting the linker flag and then
> see what (if anything) fails."
> 
> Can someone please help me that what "linker flag" should I use when
> building/testing LibreOffice? 

sthen: can you elaborate on this?
Comment 15 sthen 2018-11-28 17:10:48 UTC
You can build from ports with the USE_WXNEEDED=Yes removed/commented-out. To save time with dependencies you can do "make prepare FETCH_PACKAGES=Yes" and to build on multiple cores "make MAKE_JOBS=4" or similar, but it will still take a LONG time to build.
Comment 16 Xisco Faulí 2019-07-08 16:06:32 UTC
(In reply to sthen from comment #15)
> You can build from ports with the USE_WXNEEDED=Yes removed/commented-out. To
> save time with dependencies you can do "make prepare FETCH_PACKAGES=Yes" and
> to build on multiple cores "make MAKE_JOBS=4" or similar, but it will still
> take a LONG time to build.

@hessnovTHR44, any update here ?
Comment 17 QA Administrators 2020-01-05 03:48:51 UTC Comment hidden (obsolete)
Comment 18 QA Administrators 2020-02-05 03:37:47 UTC
Dear hessnovTHR44,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp