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
We host our own infrastructure here and use multiple mirror servers to cope with the amount of downloads and also to provide good redundancy. After all it is not too bad to host this project from the bandwidth’s perspective since most people update anyway and for our new users, the OS image is not too large. It only has about ~150-200MB depending on the image you are downloading.
However, we still provide torrent downloads which are useful for people who cannot reach our website which unfortunately seems to be blocked in some countries. Just getting the magnet URL is enough to download it.
They are also useful because we do not have to provide 100% of the bandwidth and they also check the integrity of the downloaded file.
To provide communication between the multiple peers that want to download a torrent file and the seeders who have some parts of the file or the entire file ready to be uploaded again, a database called the tracker is being used. It just exchanges IP addresses and the peers spin up a peer-to-peer network and transfer the data directly.
That tracker was implemented in our webapp that is hosting the website, this blog, fireinfo and some more things, but it was not really the best implementation there is. It was stable, it was good, but it was not too efficient by using a PostgreSQL backend and unfortunately had some bugs when it came to peers with IPv6 access as well as IPv4 access.
So to make our infrastructure leaner, faster and generally better, I installed opentracker which we used to use in the past before we wrote our own implementation. Since then it has grown a bit and is now available in repositories of CentOS which we use on many of our servers. Hence I installed it quickly, configured it and did the switch. For a few weeks now, the torrent tracker has been running on opentracker and it just works.
The tracker part of the webapp has been removed which takes quite a load off of it and we switched from an open tracker to a closed one which will only accept our own torrent files. On top of the HTTP protocol, we also support contacting the tracker over UDP and we are running two instances of opentracker; one for IPv4 and one for IPv6.
Next time maybe, you might want to use the torrent network to download a disk image of IPFire. I still find it a very fascinating way to exchange data and although people instantly think about sharing the wrong things, the torrent network is used a lot to distribute files like this and even commercial vendors of games and similar large files use it.