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.
Since we have never really been to good to put news about this project into the press, we are now starting to implement a few things that we are becoming better at this. It is a pitty to me that we are having such a nice project here but too few people know about it.
It is nice to read stories talking about their problems that they have had for years and that end with “until I found out about IPFire”, but why didn’t they find out about it earlier?
We have a new mailing list now for the press now which is for journalists, editors and writers where we will pre-announce things that are going on. For example the release of a new major version of IPFire or just the next Core Update. There is no need to subscribe for our regular users since you won’t miss out on anything as long as you make sure to be subscribed on the announcement mailing list.
The press list is non-public (since we don’t want to ruin the surprise for everyone) but open to subscribe for everyone. Subscriptions need to be approved, so please make sure to use the email address for the newspaper/magazine/blog you are writing for. It is open to post for everyone in case there are any questions.
Please forward this message to everyone you think should be subscribed and please everyone help us to make our project better-known.