the next Core Update 118 is almost there. We have no major new bugs left any more and it is good to go. But before our release engineering team pulls the trigger and is releasing this for everyone of you, we would like to make you aware again that a number of add-on packages has been discontinued and will automatically be uninstalled when Core Update 118 is installed. Those are:
nagiosql, because we have Icinga, which is a fork of the famous monitoring tool
openmailadminwhich are both not maintained upstream any more
owncloudwhich require PHP which has also been dropped in this release
PHP is being removed for security reasons and for more and more of the software that we ship becoming independent from it. If you have installed any custom applications that use PHP, please move them to another machine.
We are sending you this deprecation announcement to give you some extra time to prepare for the upcoming changes in case you have missed them from the pre-announcement of this Core Update.
the next Core Update for IPFire is now ready for testing and will be released soon. Please support is with that to provide you with a number of security and bug fixes as well as some new features.
Thanks for the people who contributed to this Core Update by submitting their patches and please help us to support everyone’s work with your donation!
It is the time of the year where we reviewed large parts of the distribution and decided to drop support for various packages and add-ons that cannot be maintained any more:
Most importantly, this Core Update drops support for PHP and therefore various add-ons that rely on it. We have taken that decision some while ago without any objections and first dropped all add-ons that are not supported and updated by their respective authors and maintainers. That left us with only one package that needed PHP but also be installed anywhere else.
PHP is a huge problem to maintain and does not really have a place on a firewall in 2018. Our web user interface is entirely independent and since we value security more than anything else, we have decided to drop support for PHP with this Core Update.
If you have anything installed manually that requires PHP, please move it to another web server before installing this Core Update.
Add-ons that have also been dropped:
icinga is available,
This Core Update originally contained the microcode updates that Intel has now pulled from public release. Since they make the system very unstable and cause random reboots and reportedly can render some systems unbootable, we decided to remove them from the update again.
So far due to the hardening Meltdown exploits do not work on IPFire although this still is a hardware bug and software can only be modified to mitigate this massive problem. Over the coming days and weeks we will continue to work on providing a solution that mitigates all problems, but so far we are not in a position to have patches for Linux that fix them all and are at the same time complete and stable enough to be released.
Justin Luth has contributed fixes and improvements for the Update Accelerator which has sometimes re-downloaded files with special characters in the URL (#10504).
He has also improved caching of Microsoft updates which is now based on a checksum of the update file (#11558).
squid, the web proxy, has been patched against a security vulnerability in its HTTP parser (SA 2018:2)
fireinfois now submitting all profiles over HTTPS
mdns-repeateris now being packages which is a tool that relays mDNS messages from one network segment to another one. That helps devices like printers and other IoT devices to be auto-discovered from the GREEN network when they are connected to the BLUE one and vice-versa.
clamav0.99.3 which fixes various severe security vulnerabilities
libvirthas been updated to version 4.0
I am sure that it has been unmissable: Every modern processor has unfixable security flaws. The story has now been boiling for weeks and has finally made the main news one week ago.
To make this article shorter, I won’t go into details of the technical issue. That has been discussed in many places so far and everyone of you can search around a bit to find an explanation to your desired detail. The most important piece of information that you should know is that the CPUs are allowing applications to access parts of the memory that they should not and that allows an attacker to get important information from the victim’s computer.
The most important question for us is: Is IPFire affected? And the unfortunate answer is yes, most likely. This is a hardware bug and if IPFire is running on hardware that is vulnerable, it is affected. The even worse news is that there is probably not many systems that are not affected. The IPFire kernel has been patched and hardened against multiple attack vectors and there is a possibility that we are able to mitigate at least some exploitation of this attack through grsecurity. However, this is not 100% confirmed, yet.
Talking about what we can do from a distribution point of view brings me to point that I have to raise first: I have never read so many speculations, false assumptions and comments that were just wrong about any vulnerability before. For me, new about this vulnerability are just breaking and so are the patches that are out there to mitigate the problem. Many things are just in the unknown until today. The biggest problem there seems to be the embargo that hasn’t been followed properly and one specific vendor who is following their own rules.
It is still officially unconfirmed if 32 bit architectures are affected as well. Logic tells us they are, but the Linux kernel maintainers who pride themselves in having delivered a good set of patches have only working on the 64 bit x86 version of it and not 32 bit. So all 32 bit systems remain unpatched.
The latest versions of the kernel (4.14 and 4.15-rc*) have received a patchset called KAISER which is supposed to mitigate the hardware bug. However, only an old version and parts of that patchset have been backported to older kernels. IPFire is always based on an older kernel that is on long-term support and well maintained just like many other distributions. Some have patched parts of the vulnerability but I think I can be certain that nobody fixes all of it. By that I certainly do not want to say that the kernel maintainers are doing a bad job. They are doing a great job, but of course their time is also limited and this is not a simple fix that requires a few lines like Heartbleed did. It requires major rework of some essential parts of the kernel and I am very grateful for them doing that work. My point is just that they are not done, yet and deploying half a fix is probably not a good idea. People have reported bugs in the other kernels that will probably never be fixed.
So what will IPFire do? Having said that we think that we might already mitigate some portion of that problem and that the distribution is not too easy to exploit, we are continuing to work on rebasing the distribution on 4.14 which is the latest long-term supported kernel. That will take some more time though since supporting ARM is a huge maintenance problem for us right now. It is holding up a release that is basically ready for beta. If a good patchset that is also compatible with grsecurity becomes available we will ship that with the current kernel, but I am not expecting that to happen in the near future.
That leaves me with saying that everyone who can should probably upgrade from 32 bit to 64 bit.
I cannot finish this article with having a rant about Intel and how they dealt with this issue. There are also some other groups who deserve some criticism and but clearly Intel did not handle this well and is still trying to play down the huge size of this problem. First of all it is the most severe hardware issue that has been around in probably all time. It is not only in a product that some people use, but probably every person who reads this article owns at least one Intel processor that has been produced in the last decade. Their power in the market is that huge that they have a monopoly.
Bugs happen. I do not want to point a finger at a certain person or group who did something wrong. Clearly they should have known better, but this has happened now, so we have to deal with it. But you should own your bugs. Take responsibility. Instead their PR department seems to have chosen a route to blame other vendors as well for a bug that only they had. Yes, ARM and yes, AMD is also affected by some problems that are also very severe, but there is one that only affects Intel processors. That is also the most severe one. They continue to put out benchmarks that only show a little performance impact but deliberately neglect older processors where the performance impact is a lot higher.
That is not a very good way to gain my trust. And not that I had the biggest trust in that company before, this did not help. So I am stuck in a world where I do not have many alternatives to what I can buy from the shelfs. Your products are inside every modern computer. Make yourself aware of that responsibility. That includes your CEO who apparently did not want to own that financial risk.
And the only reason why I care about this so much is, that secure software requires secure hardware. It does not matter how secure IPFire is, because when the hardware is compromised, the software is compromised, too.
it is time again for testing the next Core Update with number 117 which comes with a huge number of various bug and security fixes. This will also most-likely be the last Core Update in this year.
Thanks for the people who contributed to this Core Update by submitting their patches and please help us to support everyones work by sending us your donation!
One moderate and one low security vulnerability have been patched in OpenSSL 1.0.2n. The official security advisory can be found here.
strongswanhas been updated to 5.6.1
nasm, the Net Assembler, has been updated to 2.13.2
ffmpeghas been updated to 3.4
mchas been updated to 4.8.20
nanohas been updated to 2.9.1
Poundhave been dropped because they are not maintained upstream any more and incompatible with OpenSSL 1.1.0