Vulnerable to meltdown?
- Inicie sesión ou rexístrese para enviar comentarios
Per https://github.com/paboldin/meltdown-exploit my installation appears vulnerable to Meltdown:
BIOS: Libreboot 20160907
VULNERABLE ON
3.13.0-137-lowlatency #186+7.0trisquel2 SMP PREEMPT Sat Dec 9 14:45:23 UTC 2017 x86_64
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 CPU P8600 @ 2.40GHz
stepping : 10
cpu MHz : 2401.000
cache size : 3072 KB
physical id : 0
siblings : 2
I've ran updates, anything I could further do or shouldn't I worry?
You could download a more recent kernel from jxself's repo. https://jxself.org/linux-libre/
Alternatively you can install the linux-lts-generic-xenial package. Really everyone still using the default kernel ought to do this, the default kernel no longer receives updates.
Hmm, installed latest lowlatency lts kernel:
Spectre and Meltdown mitigation detection tool v0.31
Checking for vulnerabilities against running kernel Linux 4.4.0-93-lowlatency #116~14.04.1+7.0trisquel1 SMP PREEMPT Mon Aug 28 17:34:47 UTC 20 x86_64
CPU is Intel(R) Core(TM)2 CPU P8600 @ 2.40GHz
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel: NO
> STATUS: VULNERABLE (only 32 opcodes found, should be >= 70, heuristic to be improved when official patches become available)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
* Hardware (CPU microcode) support for mitigation
* The SPEC_CTRL MSR is available: NO
* The SPEC_CTRL CPUID feature bit is set: NO
* Kernel support for IBRS: NO
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* Mitigation 2
* Kernel compiled with retpoline option: NO
* Kernel compiled with a retpoline-aware compiler: NO
> STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): NO
* PTI enabled and active: NO
* Checking if we're running under Xen PV (64 bits): NO
> STATUS: VULNERABLE (PTI is needed to mitigate the vulnerability)
Apparently the current packages in belenos are too old?
They are, hence mason's advice: https://trisquel.info/forum/vulnerable-meltdown#comment-126601
I'm a knob, thought I already had done that.
Meltdown was fixed:
Spectre and Meltdown mitigation detection tool v0.31
Checking for vulnerabilities against running kernel Linux 4.14.14-gnu #1 SMP Wed Jan 17 15:33:18 UTC 2018 x86_64
CPU is Intel(R) Core(TM)2 CPU P8600 @ 2.40GHz
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking whether we're safe according to the /sys interface: NO (kernel confirms your system is vulnerable)
> STATUS: VULNERABLE (Vulnerable)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Checking whether we're safe according to the /sys interface: NO (kernel confirms your system is vulnerable)
> STATUS: VULNERABLE (Vulnerable: Minimal generic ASM retpoline)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Checking whether we're safe according to the /sys interface: YES (kernel confirms that the mitigation is active)
> STATUS: NOT VULNERABLE (Mitigation: PTI)
A false sense of security is worse than no security at all, see --disclaimer
"So perhaps it can't really be fixed with software patches but indeed just 'mitigated'."
Indeed; they are all "mitigations." Plus: There are numerous mitigations for Spectre that won't work on libre systems because they require (proprietary) microcode changes which neither Trisquel nor I will provide. For obvious reasons of them being proprietary.
I understand that those dedicated to software freedom would not install such proprietary microcode on their computers. So upstream really did us a disfavor by choosing a solution that relies on microcode changes. I wonder if it would be possible to spark some community movement towards alternate mitigation techniques that do not require microcode updates.
But, really, remember that the key point is that the CPU itself is broken/defective. Software can only do so much.
> There are numerous mitigations for Spectre that won't work on libre
> systems because they require (proprietary) microcode changes which
> neither Trisquel nor I will provide. For obvious reasons of them
> being proprietary.
> I understand that those dedicated to software freedom would not
> install such proprietary microcode on their computers.
I gather that,
* The CPU we buy off-the-shelf does carry a proprietary microcode on it, and yet it is OK to use it.
* But an updated microcode from the same manufacturer is _not_ OK to use.
What I don't quite get is, which of the following is true?
1) The updated microcode itself is unacceptable per-se. (which would imply that the original one is somehow more benign than the updated one)
2) Original and updated microcodes are equivalent in their acceptability, but the very act of uploading a proprietary microcode onto a CPU is an unacceptable act per-se. (which would imply that acceptability is somehow related to "having to touch the code" rather than using it)
I'm curious about it because there was a thread in which I was told that a modem card running proprietary firmware off of onboard ROM would be acceptable, whereas a variant of the very same modem card running the very same proprietary firmware from onboard RAM would not, because the second card needs its firmware (a blob) be uploaded by the OS.
IOW, it is perfectly acceptable to use a proprietary modem (with all the strings attached) as long as you (the OS, that is) don't have to upload its firmware yourself. Back then, I couldn't understand the rationale behind this logic. Now I see that the same goes with CPU microcodes.
The two cases (CPU and modem) are almost identical, and your standing is identical too. I suspect I must be missing something, so I am geniuinely curious about the rationale of it.
Rather than me explaining it, why not listen to John Sullivan? He's Executive Director at the Free Software Foundation and gave a talk called State of the GNUnion. This question was discussed during the Q&A session. I encourage you to listen to it: http://faif.us/cast/2013/oct/17/0x43/
The Q&A starts at about 45 minutes in but the whole thing might be good to listen to.
In the Q&A you'll hear him say "It's not that it's OK."
Someone also jumped in explaining that "there is a definitional problem going down as well as going up."
Hopefully listening to it will clarify it.
> http://faif.us/cast/2013/oct/17/0x43/
Unfortunately I can't view/download online multimedia and the issue is covered in Q/A which is in MM form, so I can't listen to John Sullivan's explanation.
Anyone cares to share the gist of it, or provide a link to an abstract in text? (any text format would be fine)
(BTW Richard Stallman's essay on SaaSS was a good read.)
"Unfortunately I can't view/download online multimedia and the issue is covered in Q/A which is in MM form, so I can't listen to John Sullivan's explanation."
Why not? It should be as straightforward as:
wget http://faif.us/cast-media/FaiF_0x43_GNUnion.ogg
> Why not? It should be as straightforward as:
> wget http://faif.us/cast-media/FaiF_0x43_GNUnion.ogg
Well I didn't want to stray off topic, so I had been a bit terse on the subject. Let me explain why (it is a bit personal)
Basically I don't like the way internet is evolving from an information highway into an entertainment junk yard, where useful information quality and density per MB is going lower and lower.
So I don't do multimedia on internet. Use midori %99 of time, which has Java, JS, Flash, plugins, even images disabled (effectively browsing internet in text). And for banking, etc. I use Qupzilla %1 of time, where aforementioned features are enabled, and shut it down as soon as possible.
As such, I don't need bandwidth much so I use the minimal plan of my ISP, which is 1 GB/mo. Because of this quota, I don't do large downloads even when I would like to, save extreme cases. So when I am directed to some MM content, I usually look for text alternatives, which also happens in line with my original proposition in the first place. (high quality, high density of information on internet).
Hopefully you would consider this talk to be of high quality, not a junk yard with low information quality. I have found all of the Free As In Freedom episodes to be very good. To my knowledge no one has transcribed this or any other episode of Free As In Freedom. The duration of the file is 1 hour and 20 minutes so it would be quite the project. But, this sounds like a personal decision to exclude yourself.
But the thing would be that, if you were to take the time to listen to John's talk, they're not saying that that stuff is OK. You mentioned another forum thread. It's important remember that other people talking is not the FSF. This is why I steered you to them. To hear things out of the horse's mouth, so to speak.
From what I hear in the talk, they're not trying to say stuff in a ROM is acceptable. And so my interpretation is that their take would be both the original and updated microcode are not acceptable.
A quote from someone in the audience to another audience member that was asking some questions: "Someone wrote the microcode that runs inside your Intel processor as well, that Intel put in there, that they can't get out. So does that mean that, therefore, you have to have a, in order for a system to be free, that the processor design -- right down to the microcode -- you know, so there's a definitional problem going down as well as going up, and the FSF isn't going to say "We're not going to run Intel chips until Intel release the source to all of their microcode." So they've got to draw a line somewhere, and where John has drawn it seems like a pretty clear line to draw."
For right now. As the world changes I look forward to that line being pushed further down the stack.
I am a member!
The way I look at it is this:
Regardless of what's on your system, do the following: install free
software, don't install proprietary software.
The FSF recommends installing free software on top of proprietary
firmware that can't be replaced in the same way that they recommend
installing free software on Windows:
1. Add free software.
2. Do not add proprietary software.
Maybe, after installing so many things, you'll install a whole OS.
I can't download it because I am bound by 1 GB/mo quota - not because I find it unworthy. The parts in my explanation regarding information quality, text browsing, etc. was only there in order to explain why I have such a low plan as 1 GB/mo.
Please consider making an exception when interesting stuff like this comes up. :)
The problem is that no body can see the code of that crap, nobody knows if there is something worse inside the microcode (maybe improved backd00r). So I won't use microcrap. So maybe we are f***ed.
I am a translator!
>The problem is that no body can see the code of that crap, nobody knows if there is something worse inside the microcode (maybe improved backd00r). So I won't use microcrap. So maybe we are f***ed.
Hehe, right? In order to fix a vulnerability you install a backdoor \o/
That would be very funny indeed.
> nobody knows if there is something worse
> inside the microcode (maybe improved backd00r)
Good point.
It is also possible that meltdown and spectre were already long known by Intel and AMD, but only recently made public by them (via indirect channels) so that they get to install a better backdoor worlwide.
Just a theory:
Backdoor embedding "technology" evolves by time, and previous versions of various backdoors embedded in Intel and AMD CPU's have various shortcomings. Recently, they have perfected their backdoor techniques and want to implement this on billions of CPU's deployed worldwide. What is more convenient than making one of already known bugs public, thus forcing everyone to a microcode upgrade, thus installing their perfected backdoor worldwide?
May be a conspiration theory, but not improbable at all.
> Just a theory:
The moment I posted this, it occured to me that should it be the case, then the vulnerabilities made public would be highly localized and easy to fix with just a microcode upgrade. But the situation with meltdown and spectre is more complex, requiring both microcode upgrade and software changes, and all these don't even amount to a fix - they're just mitigation. Only a new CPU would fix it for good.
So I take this theory back.
> So perhaps it can't really be fixed with
> software patches but indeed just 'mitigated'.
Note that these mitigations are only good against hackers and criminals - they have no effect on Intel, as long as the microcode is proprietary. And it doesn't matter if the it is factory loaded or upgraded.
I find it interesting that FSF et.al. take great pains to eliminate -not only proprietary code itself- but everything related to proprietary software (firmware blobs that run elsewhere, documentation referrals, suggestions, etc.) all the while there's this huge gaping hole in security by way of proprietary microcode. As long as the CPU rides on closed microcode - be it factory default or upgraded - there can be no security against the designer of that CPU.
For instance, there may be some "undocumented" (covert) instructions which can -for instance- break CPU ring boundaries. OTOH, an automated audit (simply dissassemble) of binary code would reveal all such out-of-band instructions. But then there's this recent "web browser" case of yours: Many open source browsers, supposedly audited by the community, _do_ covert background chattering. Then how can we depend on the possibility of catching usage of undocumented instructions in Intel's binary code base? E.g. anyone ever tried to dissassemble Intel software base (the whole lot of it) ever?
Also there may be other attack vectors that I can't think of right now. E.g. microcode "knocking" (as in "port knocking") possibility comes to mind. In this scenario, a specific juxtaposition and repetition of in-band opcodes can be used as a pass phrase to switch opcode interpretation one way or another, so that certain in-band opcodes suddenly start behaving differently. In that case no dissassembly would reveal such out-of-band instructions (because they are actually documented opcodes which just behave temporarily different). It would be near impossible to detect them.
And I'm sure there must be many other potential attack vectors that I can't think of right now. It really boils down to the fact that with a proprietary microcode/architecture, no higher level security scheme would hold water against Intel or any entity they cooperate with. With such an architecture, all the security measures, actual or perceived, goes out of the window. Sorry to say that.
So, gladly (or otherwise) accepting factory-loaded proprietary microcode, and yet rejecting an upgrade, is just... strange, if you ask me.
I can't see an easy way out of this dilemma unless Shakti team (RISC-V architecture) succeeds.
http://rise.cse.iitm.ac.in/shakti.html
http://lists.phcomp.co.uk/pipermail/arm-netbook/2017-December/015062.html
> So, gladly (or otherwise) accepting factory-loaded proprietary
> microcode, and yet rejecting an upgrade, is just... strange, if you
> ask me.
Really? Because not all undesirable things can be avoided at this time we should not try to avoid any of them? Suppose I approached you from behind and punched you in the back of the head. You turn around and realize that I am about to punch you again. Do you say, "Gladly (or otherwise) getting punched in the back of the head, and yet protecting myself from getting punched in the face, is just... strange. Go for it!"
That said,
> (RISC-V architecture)
you're right that this might allow us to avoid even more undesirable things, and I appreciate that you are looking toward a positive solution rather responding to current obstacles by becoming complacent.
To clarify, if someone were to refuse to support RISC-V because they felt that repurposed Intel tech was good enough despite its freedom and security issues, that would indeed be strange. If that's what you meant I apologize for putting words in your mouth.
> Really?
Your punch analogy misses my point. Accepting a microcode upgrade from Intel is more analogous to accepting security patches from Microsoft. As in, by installing Windows, one already acknowledges being a vassal to Microsoft upfront. From then on, one cannot protect oneself from Microsoft. The security patch served by Microsoft covers one only against the common criminal - not against Microsoft. Then, for a Windows user, it is obviously beneficial to accept and install that patch, because if he doesn't do it, he will be vulnerable to _both_ Microsoft _and_ the hackers. If he does apply the patch, then he is _only_ vulnerable to Microsoft.
Swap Microsoft with Intel, Windows with CPU, and security patch with microcode upgrade.
> Thanks for the link.
You are welcome. :)
> http://lists.phcomp.co.uk/pipermail/arm-netbook/2017-December/015062.html
It's been a while since I read something that made me so optimistic. Thanks for the link.
I am a translator!
>The tree is there, you can see it, touch it. You don't need a community of experts to provide certifications and endorsements that there is a tree.
I beg to differ
I can easily go full-shit-philosophical about it until I really convince my self there really is no tree and no observer either :P
> FSF proponents here would argue that through trust (in so called community) you get the necessary certainty. But as I have said on other occasions - trust is a belief. It creates more uncertainty as it is not based on direct observation but on an idea. When you look a the tree outside your house - there is nothing to trust or believe. The tree is there, you can see it, touch it. You don't need a community of experts to provide certifications and endorsements that there is a tree.
Well you do have to trust your senses. That you aren't having an hallucination or a dream, for instance.
But more importantly there are plenty of things you can "trust" (in a qualified sense) that you don't interact with directly. I haven't directly seen an electron or the dwarf planet Pluto. I haven't been to Thailand or Angola. Nor have I touched the original Rosetta Stone or Terracotta Army. Nor have That doesn't mean that I am "wrong" to trust that those things are real. All of those things can be verified by a community of scientists, cartographers, historians, and archeologists because they are by their nature open to peer review, in both its formal and informal sense. One does not need to fall into the trap of solipsism, instead we can have various degrees of trust.
To bring it back to software, I have not read the millions of lines of code in the software I use. But I "trust" in the free/libre community of programmers to find flaws in them. Is it perfect? Of course not. Can it be improved? Yes, auditing software for security flaws should be an extremely important part of software design. (Just like replicability should have an even more important role in science) Is it the best we have? It appears that way.
In fact your test of various browsers for leaking information is a great example of this. You, a member of the free/libre community even as an amateur, found a problem, reported it, and it appears is being taken seriously. Thank you for that.
> Those are all things which have no or very little relation to your life. So trust or no trust - it really doesn't expose you to any risk. But when your life is based on a computer which can be modified remotely by an evil expert and so create a disaster for you - that is something entirely different. It is like sleeping with a tiger in the room and trusting that it won't eat you.
Then let’s extend the metaphor to the immediately practical. I haven't seen a poliovirus, but I trust getting a polio vaccine will help prevent me from getting polio. Why? Because I have a basic scientific mindset and since science is at its core communal I have trust in the scientific community. (With all the necessary caveats) Similar concepts apply to free/libre software community and its approach to security.
> I am not so sure. For the moment there have been only verbal confirmations by only a few parties. We will see.
It is still pretty early in the process. But yes, certainly something to keep an eye out on.
> That is not immediately practical.
> It would be if you were in an actual situation which is threatening to your health. But are you? Or is it a fear that one day you may be (a non-fact ATM), so that you are taking preemptive measures?
Taking preventive measures seems practical to me. Whether those measures are a vaccine or software security update.
Linux 4.15 Git kernel built with GCC 8.0.1 and full Retpoline protection as well as the yet-to-be-merged RETPOLINE_UNDERFLOW support for Skylake and Kabylake systems.
That is what we need if we don`t want intel closed microcode.
https://www.phoronix.com/scan.php?page=article&item=gcc8-mindirect-thunk&num=1
If I don't use JavaScript in my browser, and only use free software, is there a way I could still be attacked? I mean, don't this attacks have to be executed in my computer?
"I mean, don't this attacks have to be executed in my computer?"
Yes.
"If I don't use JavaScript in my browser, and only use free software, is there a way I could still be attacked?"
It probably helps but a program being free software doesn't mean it's free of problems (a concrete example being Ubuntu's sending of search terms over the internet when they were looking for files on their computer.) It only means that you can fix those problems yourself and don't have to pray to a proprietary software developer and hope that they fix them for you.
I am a translator!
>I think that if XHR is blocked, JS cannot steal info from your RAM and send it to another host. Additionally if cookies are blocked JS cannot store a 'state' which can be transmitted via HTTP in following site navigation. uMatrix is a great extension which helps to control all that.
Heh, am I doing it right mate joe? :P
I am a translator!
..ughhh, which reminded me I need to tcpdump da netsurfy, meh.
- Inicie sesión ou rexístrese para enviar comentarios