https://meltdownattack.com/

Started by opnsense_user12123, January 04, 2018, 04:35:00 PM

Previous topic - Next topic
1. Is there a fix for that problem even on opnsense in the near future ?

2. How high will the loss of performance be?

Quote from: opnsense_user12123 on January 04, 2018, 04:35:00 PM
1. Is there a fix for that problem even on opnsense in the near future ?
Surely that would depend on the upstream kernel developers as that's where the problem is being fixed in Linux & Windows.

Quote from: opnsense_user12123 on January 04, 2018, 04:35:00 PM2. How high will the loss of performance be?
That would depend on the workload and is estimated at between 5%-30% - possibly more but you'd have to benchmark the system before and after the fixes were applied. The best advice is to read some of the more sensible articles on the subject and wait for any fixes.
Regards


Bill

January 04, 2018, 05:40:57 PM #2 Last Edit: January 04, 2018, 05:42:59 PM by opnsense_user12123
if I read correctly, data can be read from the cache. Is the firewall still safe?

What about Spectre?

I'm not a security expert (at least, not for PCs) but these exploits have been known about for a while and the embargo on the news was lifted yesterday which is why you're seeing a flurry of speculation. There is, as far as I can see, no known exploit for these vulnerabilities in the wild. As I said earlier, wait for official news from the kernel developers.There should be no reason at this point to worry about the firewall - in addition, there is also no alternative available. :)
Regards


Bill


From what we discussed on IRC this is a local attack, quite unlikely to hit in a server/appliance scenario. Also meaning it can only be exploited in conjunction with a remote exploit or local shell access.

However, network servers and routers may take a larger performance hit for full mitigation than user desktop systems.

FreeBSD is said to be working on patches. LLVM (clang) is also working on this. This will likely go on for months, if not all year.

It's likely the worst thing that ever happened. Stay tuned for more to unfold and buy AMD if you can. ;)


Cheers,
Franco

...have no stocks of either AMD or Intel, but:

https://www.amd.com/en/corporate/speculative-execution

AMD not totally safe, apparently.
kind regards
chemlud
____
"The price of reliability is the pursuit of the utmost simplicity."
C.A.R. Hoare

felix eichhorns premium katzenfutter mit der extraportion energie

A router is not a switch - A router is not a switch - A router is not a switch - A rou....

Not safe, but maybe safer. Note we have "Meltdown" (Intel) and "Spectre" (Intel, AMD, ARM).

...but based on this I would not kick out any Intel hardware and replace by AMD, currently ;-)
kind regards
chemlud
____
"The price of reliability is the pursuit of the utmost simplicity."
C.A.R. Hoare

felix eichhorns premium katzenfutter mit der extraportion energie

A router is not a switch - A router is not a switch - A router is not a switch - A rou....

True, I didn't mean replace. Just buy smart. :)

As a side note, please enjoy this gem from Theo de Raadt (OpenBSD) from 2007 on the Intel Core 2 bugs and his predictions for the future.

https://marc.info/?l=openbsd-misc&m=118296441702631&w=2


Cheers,
Franco

January 04, 2018, 08:45:10 PM #10 Last Edit: January 04, 2018, 09:50:24 PM by lattera
Quote from: franco on January 04, 2018, 06:55:23 PM
From what we discussed on IRC this is a local attack, quite unlikely to hit in a server/appliance scenario. Also meaning it can only be exploited in conjunction with a remote exploit or local shell access.

Hey Franco,

I'd like to clarify this bit. The Meltdown and Spectre attacks are only local. Remote attacks are extremely unlikely. If a remote vulnerability is found and exploited, the attacker will likely use that vulnerability to gain local access. It's after gaining local access that side channel attacks like Meltdown come into play. Meltdown then becomes extremely serious, especially on systems with non-ECC RAM where Row Hammer could be combined to gain arbitrary write access in the kernel.

FreeBSD's kernel is extremely leaky. Meaning, the kernel is full of information leak vulnerabilities. Log in and simply issue `sysctl -a | grep 0x` as an unprivileged user. While Meltdown is critical in that it can leak the contents of arbitrary kernel and userland memory, the FreeBSD kernel itself is an easy target once local access is achieved. Mitigating Meltdown would simply cause an attacker to look at the plentiful amount of other information leaks, buffer overflows, integer overflows, and other vulnerabilities that lie within the kernel.

We at HardenedBSD are paying attention. We're interested in the mitigation FreeBSD comes up with and will work to audit, test, and include it. We will work with OPNsense to merge it in.

OPNsense users are at a great advantage here due to the inclusion of a few of HardenedBSD's core features (ASLR, SEGVGUARD, and SafeStack integration). The inclusion of those features will drive up the economic cost for attackers, frustrating them and their attempts at exploitation. With HardenedBSD, gone are the days of copy & paste mass exploitation.

edit[0]: llvm is working on an approach (https://reviews.llvm.org/D41723) to mitigate Spectre. If the approach makes it to 6.0.0, I will definitely play around with it in a special feature branch of HardenedBSD.

Thank you for the detailed response, Shawn. :)

@Shawn

always good to read that there are people who keep their heads!

thanks cheers till

If you need local access, why does Cisco release Snort rules for Port 25? It would only make sense if the mail service has some buffer problems too, right?

January 06, 2018, 04:11:53 PM #14 Last Edit: January 06, 2018, 06:13:34 PM by xinnan
I'm not really worried about any of this as far as my firewall goes because unless opnsense is going to start writing code to exploit the vulnerabilities themselves, I'm totally at a loss for how any of this would ever get a chance to RUN on my box.  Sure, it might pass through the firewall, but I don't see that as a threat to the firewall itself.

Now, If I had something running in a cloud I'd be very worried that someone else might run something malicious on that same cloud server.  I suppose it also makes sense to worry about computers where you run web browsers or that idiots who like clicking "yes, download, install" might have access to the keyboard.

However, probably the biggest problem I see is people running things in the cloud.  If I read and understand these vulnerabilities correctly, it would mean that I could run a malicious VM that could potentially start grabbing info from the memory of the server running many other VMs and potentially get lucky and gain some privileged info.