OPNsense Forum
English Forums => General Discussion => Topic started by: 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 ?
2. How high will the loss of performance be?
-
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.
2. 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.
-
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. :)
-
GREAT NEWS! :'(
-
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.
-
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 ;-)
-
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
-
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?
-
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.
-
Amazon has already patched its cloud https://www.neowin.net/news/amazon-aws-customers-see-slowdown-after-meltdown-patch
Bart...
-
Amazon has already patched its cloud https://www.neowin.net/news/amazon-aws-customers-see-slowdown-after-meltdown-patch
Bart...
So have google: https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html
There's also a patch from VMware for ESXi systems: https://kb.vmware.com/s/article/2151099
-
I believe the word that is being tossed around is "mitigation".
I think we are stuck with Spectre until the next slew of chips are fabricated and the problem is eliminated at the chip level.
-
Statement of freebsd.org (admin):
About the Meltdown and Spectre attacks: FreeBSD was made aware of the problems in late December 2017. We're working with CPU vendors and the published papers on these attacks to mitigate them on FreeBSD. Due to the fundamental nature of the attacks, no estimate is yet available for the publication date of patches.
https://forums.freebsd.org/threads/63985/#post-371432
-
I'm not really convinced attacks are only possible through local access, what about hypervisors. It seems even attacks from one vm to fetch another vm's data are possible. VMWare has patches but those work together with the OS patches. If that's the case any vm running on the same hypervisor host could be used to attack.
That's the type I'm most worried about since we use OPNSense on a vCloud environment where of course other customers have vm's.
-
Totally agree judging by what I've read, however, VM is a local attack. It is code running on the machine. However, If you own the machine and you are the only one running VMs on the machine I think you are in the clear.
I don't think this really impacts most of us as far as opnsense is concerned unless we are running VMs in the cloud and we don't know what the neighbors are up to.
-
There are two major areas where these attacks hurt *badly*:
* End users that browse the web, read emails, run applications and updates
* All VM deployments where end-users are deployed or unsupervised code is ran (the "cloud provider") because they make the attack local to the host, even if "sandboxed" in the guest
The best attack vector is to simply *buy* a cheap VM and start scraping the host for secrets in other VMs on it. ;)
Cheers,
Franco
-
The sad thing is that my box's processors are dated enough to be immune to these attacks but I bet the patches slow down my boxes anyway. Its an epic mess. Maybe some good will come of this and the x86 architecture will get a badly needed revamp.
-
@xinnan: I heard the only processors "safe by age" originate from before 1995. What am I missing?
-
Generally true, but some of the Atom chips before 2013 and AMD chips as well are immune. I'm talking about spectre. Meltdown can be addressed with OS updates if I'm not misled.
I'm pretty sure that neither my Athlon X2 nor my D2700 are at risk. However, every laptop and desktop and small server I have are. Those are all fairly modern Intel CPUs and I do not believe intel when they say they have a fix for this. I think they are just grasping at straws trying to prevent further devaluation.
-
...yeah! I have an older AMD CPU machine too! :-D ...and my little farm of RaspberryPis--- :-)
-
Hot off the press...
https://lists.freebsd.org/pipermail/freebsd-security/2018-January/009719.html
Cheers,
Franco
-
Security guys are talking a big game but I feel like this is a whole new game they are not prepared for.
BTW - The firefox and google chrome patches seem to make things both slow and memory hungry if you ask me.
I'm going to need more tinfoil...
-
I thought I'd update everyone with the progress I'm making in addressing Spectre in HardenedBSD.
- I've created a feature branch called hardened/current/retpoline in HardenedBSD's Playground repo (https://github.com/HardenedBSD/hardenedBSD-playground). This branch is based on HardenedBSD 12-CURRENT.
- I've imported FreeBSD's projects/clang600-import branch and performed some fixups.
- I merged in llvm's retpoline patch and integrated it into the build framework and enabled it by default on amd64 (the retpoline patch only addresses amd64).
- I updated my HardenedBSD laptop with the this retpoline branch.
- I'm now typing this from the same laptop with world + kernel build fully with retpoline.
What's left to do:
- Benchmarking
- Enable and build binary binary updates for the retpoline feature branch for wider testing.
- Further down the road: experimental package builds.
Note that this work is only applicable to HardenedBSD 12-CURRENT/amd64. We're still in the very early stages. Once retpoline makes it officially to llvm 6.0, it will be backported to prior versions. Applying this work to OPNsense will take some time. The work I'm doing is simply research. Getting my feet wet.
So, great progress is being made. FreeBSD's PTI patch is coming along as well.
Screenshot here: https://photos.app.goo.gl/nemutoL6zYceaVH12
-
Another update. In the past few days:
- Merged in Kostik's PTI patch into the retpoline feature branch in HardenedBSD
- Updated the retpoline patch
- Enabled retpoline for the entire HardenedBSD ports tree for users of the retpoline feature branch
- Migrated four systems over to the retpoline feature branch
- Published numerous binary updates
- Completed an experimental package build
Everything's looking good so far. Not a single issue with retpoline, even when building over 29,400 packages. I've had a few issues with PTI, but those have since been resolved. I haven't noticed any real performance impact of retpoline.
The PTI patch does come with a rather large performance hit, especially since it doesn't currently support PCID. (I've been assured by upstream FreeBSD PCID support will follow.) Kostik's PTI patch should land in upstream FreeBSD in a "default disabled" state later today.
I plan to merge into HardenedBSD 12-CURRENT the retpoline patch within the next week or two. Note that retpoline requires lld as the default linker. HardenedBSD enabled lld as the default linker for 12-CURRENT/amd64, but GNU ld remains the default in 11-STABLE/amd64.
The soon-to-be-released OPNsense 18.1 uses FreeBSD 11.1-RELEASE as its upstream, with a select few crucial HardenedBSD bits mixed in. In OPNsense, GNU ld remains the default. Thus, retpoline as currently implemented will not be applicable to OPNsense.
-
Sounds like good stuff. How big is "rather large" in terms of percent performance impact?
-
`make -sj6 buildworld` on my Intel Xeon E3-1505M v5 @ 2.80GHz laptop went from 1.5 hours to about 2.25 hours with PTI enabled. retpoline didn't increase the time.
-
I'm very interested to find out how all these changes will impact packets per second, throughput in terms of bandwidth and VPN bandwidth etc. I'm hoping it won't be huge.
I'm assuming that more packages, more filtering, more processing will equal more impact, but I'm just guessing and hoping it is less than initially thought.
-
That's a really good question, one that I cannot answer right now. Once PTI becomes available for 11.1-RELEASE, we at OPNsense will definitely have to do one or more "Call For Testing" rounds.
-
Well, thanks for banging away on it.
-
The amd64 PTI patch has landed in FreeBSD HEAD, disabled by default: https://svnweb.freebsd.org/base?view=revision&revision=328083
We'll enable it by default in HardenedBSD.
-
https://www.theverge.com/2018/1/22/16919426/intel-advises-pause-deployment-of-spectre-patch
https://techcrunch.com/2018/01/22/linus-torvalds-declares-intel-fix-for-meltdown-spectre-complete-and-utter-garbage/
https://gizmodo.com/intel-is-trying-to-fix-the-biggest-problem-with-its-spe-1822305604
All fixed!
-
Update: PTI is now enabled by default on HardenedBSD 12-CURRENT/amd64. The retpoline patch has landed in both upstream llvm (https://reviews.llvm.org/D41723) HEAD and HardenedBSD 12-CURRENT/amd64. Packages are building with retpoline applied to the entire package repo.
HardenedBSD will likely be the first OS to ship with retpoline applied to the entirety of the operating system, spanning not only world and kernel, but also third-party applications in its package repository.
-
@xinnan:
Much better, there WAS NEVER anything to fix. Intel hardware all OK.
No joke:
https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html
One day in the not-so-far future I will end with Parkinsons' from the all-day head shaking....
-
But Intel proposing an OPT-IN hardware flag for "this cpu is insecure, please make it safe and slow" is no indication of lawyer-based R&D and general "cover-my-ass"ing for having done nothing wrong whatsoever? It seems silly on the surface to even entertain the idea of it, the malice hidden beneath if baked into actual hardware... "you can't sue us if you don't use the secure mode -- also we are fast by default, slow is merely your fault -- both issues are not linked if you try to imply that".
https://news.ycombinator.com/item?id=16202205
Cheers,
Franco