Intel bug incoming.

More DragonFlyBSD updates related to Meltdown:

More Meltdown fixes

If you’re on the bleeding edge of DragonFly and already updated for Meltdown fixes, there’s a few more commits you’ll want to get.

Matthew Dillon wrote a summary of the current status, noting there’s not much you can do for Spectre beyond new hardware. There is an update to the “defensive browser setup” plan for DragonFly (using –site-per-process) that can help at least with Javascript versions of Spectre.

I've seen Chromium's experimental "Site Isolation" feature mentioned multiple times now with regard to helping address some Spectre exploits via Javascript:
https://www.chromium.org/Home/chromium-security/site-isolation

I think we've already seen mentions in this thread of the latest Firefox releases addressing some aspects of Spectre, but since it's in context:
https://www.mozilla.org/en-US/security/advisories/mfsa2018-01/
 
Google sucessfully applying patches. I hear if google Inc using FreeBSD as a system for hi's server... Apple is still Unix and it patching own system too. Why FreeBSD do not have a patches yet? Who know.... But FreeBSD after this patch will be back to throne as king of security, and way for fully anonimity, far away from Inc like a FB and Youtube. Oh I'm sorry. :D
 
Is it only DragonFly that has a fix currently?

https://www.reddit.com/r/freebsd/co...ade_aware_of_meltdown_and_spectre_in/ds9tf3s/

Nothing yet from Net or Open either?

Seems like DragonFlyBSD is the only flavor of FreeBSD that has patches for Meltdown at this time.

We saw a couple of patches from NetBSD for Meltdown as well:
https://twitter.com/netbsd/status/950050623260712962

Update: Eric also mentioned a patch for FreeBSD is in review:

---

Also,I thought this was an interesting description of the vulnerability and why Raspberry Pi hardware is not vulnerable:
Interesting explaination why the Raspberry Pi isn't vulnerable (and why others are):
https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

In short: "The lack of speculation in the ARM1176, Cortex-A7, and Cortex-A53 cores used in Raspberry Pi render us immune to attacks of the sort."
 
Greetings all,

this may be a naive question, but I am no computer science expert.

As I understand it, an illicit software still must be installed to take advantage of the bugs, er, features. So, if an individual is careful about the attack channels, i.e., does not visit shady web-sites, has java-script turned off, is careful with opening strange files and attachments, etc., how big the risk really is?

Or am I completely missing an important concept?

Kindest regards,

M
 
Greetings all,

this may be a naive question, but I am no computer science expert.

As I understand it, an illicit software still must be installed to take advantage of the bugs, er, features. So, if an individual is careful about the attack channels, i.e., does not visit shady web-sites, has java-script turned off, is careful with opening strange files and attachments, etc., how big the risk really is?

Or am I completely missing an important concept?

Kindest regards,

M
I think you are right. But:
- Most computer users do not care for security and do not use ad/script blockers, and visit every site they want;
- The Meltdown/Spectre bugs are hardware bugs, and os's now need to try to patch things. Which is actually impossible because the only real solution is to remove the processor, and it has a serious performance impact.
 
As I understand it, an illicit software still must be installed to take advantage of the bugs, er, features. So, if an individual is careful about the attack channels, i.e., does not visit shady web-sites, has java-script turned off, is careful with opening strange files and attachments, etc., how big the risk really is?
Absolutely correct. To exploit these bugs, an exploit must be running on your machine. The best protection against these bugs is to only allow trusted users to access your machine (which is easy for a single-user desktop/laptop, a bit harder for a shared server), and then ask those users to only install or run trusted software.

If you run a server without a GUI, this is reasonably easy to accomplish.

And as you point out, the big gap in this is the web browser. We have gotten into the bad habit of allowing any arbitrary Java and Javascript to run in our browser windows. And in their implementation, these languages allow people to perform arbitrary memory accesses and arbitrary instructions. That wasn't always the case; if you remember when Java first came out, one of the important ideas behind it was to "sandbox" code that ran in browsers or in applets, so it could do no harm. But in those days, "harm" was defined differently: code could not print, not open arbitrary files, and such.
 
And as you point out, the big gap in this is the web browser. We have gotten into the bad habit of allowing any arbitrary Java and Javascript to run in our browser windows. And in their implementation, these languages allow people to perform arbitrary memory accesses and arbitrary instructions.

One more reason to use the NoScript extension and only allow select scripts to run.
 
One more reason to use the NoScript extension and only allow select scripts to run.
Common/widespread poor web page design nowadays more often leaves no option other than 1. enable scripts or 2. search/use elsewhere. The new version of NoScript for Firefox 57.0.4 (that is patched for exploits) is also pretty poor IMO.

I dual boot. One system treated as though it were a public PC despite being sole user installed to the first partition. Data stored on the second partition (I use ext3 format as that can be mounted as though ext4 by Linux, and/or as ext2 by BSD) with good quality disconnected backups of that data. Third partition BSD, secure, only used for accessing known/trusted web sites (online banking etc.). Thinking about setting up a separate box entirely for that, to avoid reboots, but I'm not really a regular financial transactions type user, more a case of once/month or so paying the bills type user and it takes just 10 mins or so to freshly install the third partition (latest factory fresh/pristine snapshot, with latest factory fresh copy of browser).

Hint to businesses, if you want to increase your online revenues ensure that your web page developers/providers include non-javascript versions.
 
Common/widespread poor web page design nowadays more often leaves no option other than 1. enable scripts or 2. search/use elsewhere. The new version of NoScript for Firefox 57.0.4 (that is patched for exploits) is also pretty poor IMO.
uMatrix is really nice.
 
uBlock Origin with defensive settings: all is blocked except what I selectively allow.
 
uBlock Origin with defensive settings: all is blocked except what I selectively allow.
How do you set defensive settings? Generally I have a anti add /etc/hosts file (lots of entries), I also have NoScript, and Ublock Origin installed, but I've never changed it from its default settings (seems to work fine with that, but if there is a more defensive option I'd like to try that out). I have looked through the dashboard options, but didn't see anything obvious about changing the settings to being even more secure.
 
In the parameters tab, you can select advanced user features to get extra column for global rules. Click on the box 'All' in red to block all.
 
According to German IT magazine golem.de Intel chieftain announced they will release microcode fixes for meltdown and spectre for processors up to 5 years old in less than a week.

I guess this step was motivated only by the threat of lawsuits, and the fear of being sentenced to refund 1/3 or more of the price of every processor still under warranty they do not fix, compensating for the performance loss and additional damage, like increased power consumption, service disruptions due to infrastructure getting overloaded. For example, the German laws would allow for such.

My Intel processors were released 5 1/2 yrs ago. I really hope that community increases pressure on Intel to release microcode fixes for older processors also.
 
Technically the NetBSD users can use the sysutils/intel-microcode-netbsd to update the latest cpu firmware from Intel.
Yes, confirmed, I've been layely looking for a security update on pkgsrc.se, and today found it had just been submitted :) sysutils/intel-microcode-netbsd
Log message: Update Intel microcode with newest version which, hopefully, has more fixes for Meltdown and Spectre vulnerabilites

On DragonflyBSD Matt Dillon addressed Meltdown with patch:

Intel user/kernel separation MMU bug fix part 4
Benchmarks report with performance impact:
Intel user/kernel separation MMU bug fix part 3
and started implementing Spectre mitigations with patch:
Implement spectre mitigations part 1

Anyway, it looks like FreeBSD's sysutils/devcpu-data has just received an update too, Revision 458617:
Update Intel microcode to 20180108

MFH: 2018Q1

It should contain the latest firmware definitions, involving (hopefully) a partial security fix, as for NetBSD: I didn't manage to find better reference anywhere else. Likely someone else here is better informed
 
Also, DragonFlyBSD note on microcode updates:

Microcode updates on DragonFly

One side effect of Meltdown/Spectre are CPU microcode (firmware) updates. For future needs: sysutils/devcpu-data is the port that has the updates for Intel, and cpucontrol(8) is the program you run on DragonFly to add them.

I haven’t used this myself, yet, so I can’t tell you how necessary an immediate update could be – but you will probably want to use it soon.

Update: Newer CPUs might require this sizing change.

Does anyone know if these microcode updates are the first stab at addressing Spectre Variant 2 that requires IBRS (Indirect Branch Restricted Speculation) to mitigate?

---

Not sure if it was mentioned this already, but here's the microcode from Intel: https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?product=122139

What I'm confused about is -- what does the microcode fixes ? Does it mean OS doesn't need to be patched ?

My understanding is that there are 3 separate vulnerabilities to address:

1) Meltdown: Intel-only issue related to out-of-order execution. Requires KPTI (Kernel page-table isolation) as an OS patch to mitigate.

2) Spectre: (has 2 Variants) Impacts all processors with branch prediction that perform speculative execution.

Variant 1: Requires compiler changes to mitigate. We've seen some web browser updates to prevent exploitation via JavaScript.

Variant 2: Requires IBRS (Indirect Branch Restricted Speculation) and CPU microcode updates to mitigate.
 
Back
Top