Hi Everyone,
I hope all is well!
I’m considering using Libre Office for one of my projects. Upon scanning the software for vulnerabilities, I discovered 135 critical issues. Is there a potential solution to address these vulnerabilities, or do we need to proceed with the associated risks?
If you need more information, please let me know.
Thanks in advance for your time and support.
Warm Regards,
Harshith
Where did you find these vulnerabilities? In the CVE database? Some of them may already have been addressed and fixed. Please provide a link to the information source.
Hi @ajlittoz ,
I’ve conducted a scan using the Black Duck Binary Analysis tool, and I’ve included the report for your reference(Black Duck Binary Analysis - LibreOffice_7.6.0_compressed.pdf - Google Drive).
Thanks,
Harshith
How do you read the report? Can you tell if some of the vulnerabilities are already fixed? Are they all pending?
From superficial reading, The analysis encompasses everything LO is based on, even library components which are not under LO developers’ responsibility. So, how can they use the report?
Remember that contributors on this site are users only. If you want to reach developers, you should open a bug report on TDF Bugzilla and attach this report. However, give the reading key: where is useful information, which hint does it give about the cause of the vulnerability, how critical it is, …
Hi @ajlittoz ,
I’ve attached 2 more detailed report in the xlsx format which contains the component that has the vulnerability and few other details.
libreoffice_760_win_x86-64msi-vulnerabilities (1).xlsx (165.3 KB)
libreoffice_760_win_x86-64msi-components.xlsx (20.8 KB)
I’ve not fixed any vulnerability yet but trying to get any fix if possible. My knowledge in this domain is limited. I hope the attached document would help in answering your question.
Thanks,
Harshith
In the end, there are only 58 CVEs against LO proper. Perhaps, those against firebird should be added, but I am not sure.
If you created the spreadsheets, why are they .xlsx and not .ods? 
I totally do not understand what is being discussed here.
The “libreoffice_760_win_x86-64msi-vulnerabilities (1).xlsx” file. As @ajlittoz says, “there are only 58 CVEs against LO proper”. Fine; but what are they?
Row 246: “CVE-2014-0247”: “Fixed in: LibreOffice 4.2.5”.
Row 247: “CVE-2014-3524”: “Fixed in: LibreOffice 4.2.6-secfix/4.3.1”.
Row 248: “CVE-2011-2685”: “Fixed in: LibreOffice 3.3.3/3.4.0”.
Actually, I stopped after these three. (EDIT: I also went to the end there, and checked the last entry: row 302, “CVE-2023-2255” - “Fixed in: LibreOffice 7.4.7/7.5.3”.) What are you trying to tell? That your tool doesn’t tell you the actual state? That you don’t know what it tells? Or what?
Note that despite many components are external projects, we pay close attention to updating them, and resolve any issues in them. E.g., yesterday we upgraded our OpenSSL; last week, we had five upgrades (zlib, liborcus, curl, poppler, and libtommath).The latter three all fix some CVEs in the respective libraries.
Although my knowledge on the domain is limited, I noticed the vulnerability and thought it would be beneficial to seek advice from the community. The file is in XLSX format because I haven’t started using Libre Office yet. 
Please inform me if, in the event that I begin using the software, these known vulnerabilities would pose a security risk or if there is a solution available to address them.
Thanks,
Harshith
and ignored the word “fixed”, wich usually implies: No known danger, if you use a version higher or same than the one named there as fixed.
Nobody but you can check on this. For example when there was a security issue with LibreLogo I did actually nothing in my company, as I had not installed this part. Others may need to update.
.
You have also to know of the risks for your environment: We use an old laptop with XP. Not risky at all, because it is used as a big calculator, with a 30 years old .xls-file. Not connected to anything and will be used until it breaks…But it would have an impressive cve-list. So if you construct a lunar lander you may have different needs than sombody using a tax-calculator.
… and you have addressed all CVE-“risks” of your xlsx-producing software and the OS? If your system is secured like that, don’t change anything.
My first idea is to recommend a pen (not to sharp), then reminding you “fixed in” means “yes, there is a solution available”.
.
On a general scale, LibreOffice like any big bundles of code will always have to address security concerns, but developers do and we have to update, if our “profile” is affected. If you use Windows and MS-Office, there are bigger problems lurking than LibreOffice. If you are really concerned about security, then consider cubesOS, but as usual: Security comes with the price of reduced convenience.
… and what you did was throwing some huge spreadsheets (initially a PDF) to the community, expecting people to do the work of making sense of those hundreds of thousands of characters, trying to understand what they mean, and then doing the job of checking each (?) of the elements to tell if they are resolved, and how?
Let us start with your initial post:
135 is not a small number - but let’s say it’s OK. But you never came with a list of these 135 issues in a readable form! The immediate next your post is “see this PDF, which spans 199 pages! It has something - go dig it!” Then you provide two XLSX files, and those are not much better - the “vulnerabilities” one has a sheet with 2136 rows of data.
So: where is your homework, that would result in a question like:
“I found 135 vulnerabilities, that are marked as unfixed in this latest version of LO (so I show how I tried to understand the program output to only talk about something actually problematic; also I spent time to not consider version 7.6.0 of the program that already has version 7.6.2): <here they are in a simple long list>. Here is the original report for those who want to check my conclusions. I also checked these 135 vulnerabilities’ details, and I see that for my case, 10 of them are important: <here is an even shorter list>. Could you tell me how to address these 10 vulnerabilities?”.
Alright, after conducting some research, I’ve grouped these vulnerabilities into two main categories, which collectively account for around 60-70% of them.
[1] Memory-related issues:
Addressing these issues involves configuring the software build to enable memory high entropy randomizations, as well as enabling CFGs and code integrity.
[2] Weak Cryptographic Algorithms:
In cases where weak cryptographic algorithms like SHA1 or MD5 are utilized, there is vulnerability to cryptographic attacks.
I believe these issues can be mitigated by compiling the code with the appropriate compiler and parameters, and by using robust cryptographic algorithms like SHA256 with 128-bit AES encryption.
Do you think it’s feasible to prioritize these vulnerabilities and address them methodically, focusing on the most critical ones first? Your insights and suggestions on the approach would be greatly appreciated.
Which is this vulnerability? A link?
IMHO this is trolling with security buzzwords.
And what is most critical from your list?
Yes, but sometimes we can not do much here. LibreOffice is expected to open a lot of older files. Would you suggest to enforce opening only properly encrypted files? Enforce writing to encrypted odf1.3-Files? Tell everybody who has old files: Sorry we don’t support insecure habits anymore. Please question @iamharshith … Maybe my reference above to cubesOS was not so wrong. You should try it.
.
The point is: You can not delete this stuff from code, when it is needed sometimes: You will still find support for SMB1 shares in Windows codebase. Is this a security hole? No, because it is not active by default. I can activate this. But the possible security flaw is then in my settings, not the existence of the driver in the code.
Thanks @Wanderer for sharing the insights on the [2] Weak Cryptographic Algorithms.
As per the suggestion I downloaded the 7.6.2 version of Libre Office and scanned the same. Here is the vulnerability report link which mentioned both of the critical vulnerability mentioned in my previous comment - libreoffice_762_win_x86-64msi-2023-10-10-091325.pdf - Google Drive
Usually, we can solve these problems by adjusting some settings in the program, like the Configuration File (CFG) and enabling High-Entropy Address Space Layout Randomization (HA-ASLR) during the building process. But in this case, it’s a bit tricky because we don’t control the code of the library we’re using. So, I’m asking for help from the community. I’m sure others will find this solution helpful too.