Following this:
I installed spectre-meltdown-checker, which it seems to have found: CVE-2018-3640:KO
https://fireinfo.ipfire.org/profile/3402a2969f610247cadd6eea109917521f3d8410
What are your thoughts on this?
How much could the problem be affected in IPFire?
I thank you and have a good evening.
I think Braswell CPUs are not affected but
Cheers,
Holger
I thank you.
How can I verify the CPU ID?
The BIOS is not up to date. Aware that even an accidental error results in the machine breaking down, I try not to do that.
And comumany this is a discontinued generic mini PC. I doubt if BIOS updates can be found. The company seems nonexistent as well.
IPFire has the most up to date intel CPU microcode packages. I think this is saying that if the CPU is vulnerable to variant 3a then Intel have to provide an up-to-date CPU microcode for it.
However, as we said in the previous thread the Braswell CPU family is not longer getting any service support so Intel are not investigating if those CPU’s are affected or not and therefore not applying any available mitigation.
As the spectre-meltdon-checker script is from Intel then maybe they have investigated the variant 3a on braswell but then they have not supplied any microcode updates for it as IPFire has the most recently released version of both the Intel and AMD microcode updates.
Looking at CVE-2018-3640, it says that any attacker has to be able to get local access to the system to be able to run a side channel analysis on the system to be able to utilise the vulnerability.
A side channel analysis is a security exploit that attempts to extract secrets from a chip or a system. This can be achieved by measuring or analysing various physical parameters such as supply current, execution time, and electromagnetic emission.
So if you are unlikely to have an attacker able to physically be able to access your computer then this vulnerability is probably not critical for yourself.
I thank you for the valuable information.
How do you see the problem for IPFire?
Meaning: if by “physically accessing your computer,” you mean locally, I have no problem. I am the only user on my network.
Yes, it is meant locally. I reread everything more carefully 
.
Well…not really… 
The term “side channel attacks” became popular when someone found out, that e.g. you can monitor the current of a chip executing some crypto algorithm and then draw conclusions of the used secret in this algorithm. (If you like to know more about that, get some beer, lean back and take a look at: https://youtu.be/GynPbvfyHxs - it’s not only educational but very entertaining as well ) Later this term was used whenever it was possible to draw conclusions out of some environmental changes a process produces as a side effects. With spectre/meltdown this was some remnants from predictions a modern CPU computes to speed up things (as far, as I remember). And to use these remnants, you just need to be able to execute some code on the processor. This doesn’t imply a physical access.
But usually this becomes critical, if you have a system, where several different users/customers/… have access to - e g. a hosting provider where the customer should not have access to others. A user may get access to data/secrets/keys/passwords from other users by using this exploit. Maybe this works even across different virtual machines… Another scenario (more important for IPFire) is to use another exploit/misconfiguration/… to gain user level access and then use spectre/meltdown to claim root access.
Cheers,
Holger
I think I understand:
in my case, if my processor IPFire really had this vulnerability, I would not be at risk, because I am the only user on my network and I don’t provide hosting or anything like that to anybody. So theoretically, no one will be able to access my IPFire machine, except for a possible hacker attack on one of my local machines that acts as a client.
Is that correct?
In other words:
First, the attacker should be able to access (remotely) “my local network,” exploiting my hypothetical hosting or something else.
Then, it could also exploit CVE-2018-3640.
first of all: if someone gets (remote) access to one of your local client, you have a much bigger problem and the security of your firewall is not important anymore
But back to the firewall vulnerability: I wouldn’t be that concerned about this spectre/meltdown thing. To compromise it, at least two steps were needed: first is to get any access to it in a way that allows code execution and only after this, the spectre/meltdown exploit can (with some luck on the attackers side) be used to gain root access. (Someone may please correct me, if I’m wrong!) If step one can’t be made, the exploit can’t be used.
To theoretically (!) complete this: imagine a scenario, where you run some service on the Firewall, that is accessible from outside or maybe just gets some data from outside that is processed on this machine - e.g. a reverse proxy or a blacklist download. If the reverse proxy has a bug which allows to inject some executable code or the server which hosts the blacklist gets compromised / dns-highjacked / … and the delivered data is manipulated in a way the blacklist parser on your firewall starts to execute something of it… Well… then step 1 is made and the attackers get access with the same rights, the service runs at (normally this is not root, whenever possible).
Yes, I was thinking about that .
I had thought right that the attack should be in 2 stages.
I agree. I think I understand better what you told me. The attack, in any case, must be done directly on the machine affected by the vulnerability and in 2 steps, as explained.