Skip to main content ↑ ↓
Topic: Disable Intel MEI? (Read 7186 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Disable Intel MEI?

Reply #15 –
It's not that I'm trying to defend what I've posted or that I'm nickpicking, but I feel that I need to shed some perspective upon this.

rm -rf / 

is actually not one line of code. it requires a running shell, a fully compiled rm binary, a running kernel with the appropriate filesystem  module loaded and a whole lot of memory to keep the state of the OS in.

At the point of actually loading the microcode, none of that is true for the main CPU.

I don't underestimate what even a single bit flip can do, I'm not even saying it's not something to be worried about, but with the obscurity of essential parts of CPUs, it's way too easy for unfounded speculation to become "common knowledge", with everything bad that comes out of it.

This isn't even apples to oranges. It's a few lines of low level machine code on uninitialized hardware. Perspective.

Of course, this is my opinion on the microcode alone.

There's ample space elsewhere to put bad stuff in, I don't believe the microcode is it.

But I also subscribe to the camp that believes malicious intent should be proven, not implied by default. Yes, I'm aware that different people define "malicious" in different ways. I was unable to prove that my computer is doing stuff it shouldn't. That could say a lot about my (in)ability, but I have yet to see proof of intentional backdooring from anyone.

Note that the ME does not fall under "stuff it shouldn't", because it's well documented. I falls under "stuff I would really like removed because it is reasonably suspicious".

I have yet to see millions of people protesting against Intel, ME is not hidden from the consumer, so people know what they are buying. This issues is (strangely) subject to the vote of the mass consumer.

Re: Disable Intel MEI?

Reply #16 –
<<This isn't even apples to oranges. It's a few lines of low level machine code on uninitialized hardware. Perspective.>>

all true accept rm -rf  / translates to only six bytes of code on the hardware level ;) depending on the file system.  Less to just zero out the physical hard drive.  That would be 3 bytes, I believe.  Fetch the address of the first HD local, and send 00000000.  increment the memory location, repeat.

no os is even needed.

Re: Disable Intel MEI?

Reply #17 –
<<But I also subscribe to the camp that believes malicious intent should be proven, not implied by default. >>

Yeah, I never really understood this when the malicious intent in there is plain sight and there only extortionist rationality available for an action.  When you ask to not make edge a default browser, and you can't remove it, and MS asks you, how bout this FUD?  Are you sure you want Firefox to be your default browser?  They are telling you their intent.  They are not your mother.  These companies are systematic rapist who's purpose is to strip you of every aspect of your every aspect of your worth.  Your  interaction with them since designed to  be for their  gain, and it is an inelastic economic relationship.

Re: Disable Intel MEI?

Reply #18 –
"I have yet to see proof of intentional backdooring from anyone"
Shadowbrokers and Edward Snowden are quite convincing. Remember Eternal Blue?  :D
https://en.wikipedia.org/wiki/EternalBlue
The trouble with leaving back doors open is other people can go round the back and walk in too, so it is generally better to avoid this if possible. But weighing microcode updates with possible unknown issues vs the known and published M&S exploits then a microcode update to fix it (if relevant) seems the safest option to me.

Re: Disable Intel MEI?

Reply #19 –
Quote from: mrbrklyn – on
<<This isn't even apples to oranges. It's a few lines of low level machine code on uninitialized hardware. Perspective.>>

all true accept rm -rf  / translates to only six bytes of code on the hardware level ;) depending on the file system.  Less to just zero out the physical hard drive.  That would be 3 bytes, I believe.  Fetch the address of the first HD local, and send 00000000.  increment the memory location, repeat.

no os is even needed.

This is false. rm does not overwrite the device with zeros. It keeps the filesystem in its place and in most cases, even allows for files to be recovered further down the road. You are severely distorting reality to suit your argument. That command itself needs to be path aware (/), needs to parse arguments, needs to know about filesystem directories to be recursive. I even wonder how overwriting a device with zeros could be considered a backdoor. I thought something like remote access of some kind was needed for that definition. Or at least something more than mindless data destruction.


I'm surprised at the direction this conversation is taking, I'll take a break from Artix for a while. By the very same logic you're using, Artix may well be backdoored by intentional holding back of packages compared to the Arch repos, with known vulnerabilities. Or by the lack of transparency of the build process. Or hey, look! No public CVE bug tracker and no dedicated security team! We're all doomed!

I'm not saying it is (backdoored), but it's your logic, applied on a different context. Because you can't check it, then it's bad, right? As simple as that! How could you possibly tell the machines doing the compiling aren't controlled by some agency you're afraid of! omg!


Quote from: ####### – on
"I have yet to see proof of intentional backdooring from anyone"
Shadowbrokers and Edward Snowden are quite convincing. Remember Eternal Blue?  :D
https://en.wikipedia.org/wiki/EternalBlue
The trouble with leaving back doors open is other people can go round the back and walk in too, so it is generally better to avoid this if possible. But weighing microcode updates with possible unknown issues vs the known and published M&S exploits then a microcode update to fix it (if relevant) seems the safest option to me.


We were talking about ME and micrcocode, not Microsoft's SMB protocol, right? And even then, are you saying MS did that on purpose? Proof?

I know that as far as computer security goes, whitelisting > blacklisting, any day of the week. But if you want to change the status quo, you have to work with the social and legal system, and that means proving guilt, not proving innocence.

Have fun!

PS: remember that time you ordered an HDD or SSD and it was delivered to your home? _THEY_  intercepted the pakage in transit and changed the firmware on it, so that on boot it will load an invisible backdoor from a file hidden in the firmware, giving _THEM_ root access, loaded with the kernel. Yes, on _ALL_ the storage devices _EVERYWHERE_. They call it the Just Intercept Everything In Transit And Replace The Firmware So That We Would Have Too Much Data (lovingly known as JIEITARTFSTWWHTMD)

 Sero wonders about backdooring usb powered IOT adult toys....

Take that, silicone-covered ARM firmware, I will overwrite you with ZEROS!

Re: Disable Intel MEI?

Reply #20 –
Quote from: Sero – on
This is false. rm does not overwrite the device with zeros. It keeps the filesystem in its place and in most cases, even allows for files to be recovered further down the road. You are severely distorting reality to suit your argument.


No, I am not arguing with you at all.  And after that diatribe that I didn't read past this point, I am arguing even less with you now.  I thought there was a worth while conversation to be had here, but I was mistaken.  To the most part, this has been a freindly forum for artix users.  There was no need for this confrontation, and I feel you have perversed what I wrote inorder to find an argument that I don't want to participate in.
 

Re: Disable Intel MEI?

Reply #21 –
From the link I provided above:
"According to Microsoft, it was the US's NSA that was responsible, by dint of its controversial strategy of "stockpiling of vulnerabilities", for, at the least, preventing Microsoft from timely public patching of this, and presumably other, hidden bugs."
If you had looked into the shadowbrokers NSA rootkit which they published (I can understand why you didn't though  :D ), you would have seen there was a Linux and also Windows section. Rather than being one single thing, it was more like a set of shell commands, in that each element was insignificant and unobtrusive, yet together they could be applied to do something. So what to us may look like a bug could in fact be a secret vulnerability. Or it may just be a bug.
It required extra elements to be added to use though - the standard OS had the potential to be compromised, but it was not compromised by default.
And luckily Linux is updated so while the Shadowbrokers tools may still work against Windows XP those particular issues have been long since fixed for us. But I think it was a good example of how these things work, and proves that they are real.
I do apologize if I have caused any offence though, my comments were intended in an entirely cheerful and friendly way, you are free to hold and express your own opinions! I have found your contributions to this forum to be interesting and helpful.

Re: Disable Intel MEI?

Reply #22 –
Quote from: ####### – on
From the link I provided above:
"According to Microsoft, it was the US's NSA that was responsible, by dint of its controversial strategy of "stockpiling of vulnerabilities", for, at the least, preventing Microsoft from timely public patching of this, and presumably other, hidden bugs."
If you had looked into the shadowbrokers NSA rootkit which they published (I can understand why you didn't though  :D ), you would have seen there was a Linux and also Windows section. Rather than being one single thing, it was more like a set of shell commands, in that each element was insignificant and unobtrusive, yet together they could be applied to do something. So what to us may look like a bug could in fact be a secret vulnerability. Or it may just be a bug.
It required extra elements to be added to use though - the standard OS had the potential to be compromised, but it was not compromised by default.
And luckily Linux is updated so while the Shadowbrokers tools may still work against Windows XP those particular issues have been long since fixed for us. But I think it was a good example of how these things work, and proves that they are real.
I do apologize if I have caused any offence though, my comments were intended in an entirely cheerful and friendly way, you are free to hold and express your own opinions! I have found your contributions to this forum to be interesting and helpful.

It was complaining to you.  I'm aware of the NSA activity and I think I've written quite a bit about it since and before snowden.  Generally I am with you, and share your remorse over both government and corperate intrusions on security and privacy.