Malware Uses Obscure Intel CPU Feature To Steal Data and Avoid Firewalls (bleepingcomputer.com)

One more time, my friends! by H3lldr0p · 2017-06-08 08:17 · Score: 5, Insightful

This is exactly what was said was going to happen when it came to light that Intel was sticking extra shit to motherboards no one was asking for. And at the time, Intel said no one would be capable of getting to it. Guess what?

So tired of this crap.

Re:One more time, my friends! by Train0987 · 2017-06-08 08:36 · Score: 5, Insightful

You're assuming AMT doesn't exist as a back door mechanism for state actors in the first place.
Re:One more time, my friends! by Anonymous Coward · 2017-06-08 08:52 · Score: 0

undesirable feature is baked into hardware. check.
only switch to control said feature is flipping a bit in a rewriteable setting stored in hardware. check.
using said switch is fucking pointless. it is NOT under 'user control'.
the shit shouldn't be there in the first place.
Re:One more time, my friends! by Aighearach · 2017-06-08 09:59 · Score: 0

People don't even understand the difference between CISC and RISC processors, so how can they be expected to understand an issue like this?
They can't, and so they'll be credulous of all sorts of insane nonsense about "backdoors" and "shit... no one was asking for." Except that, it is shit people were in fact asking for.
"Give us features to manage security at the network level, we have too many hosts to do it at the host level and we have security PEBCAK."
And so they implement network level management features that can manage the security without the intervention of the idiot at the keyboard, and whiners cry "backdoor, backdoor" because they don't realize that it comes turned off by default.
"Please make our games run faster, we need more throughput and better branch prediction."
And so they upgrade the microcode and whiners whine about "extra shit" because they don't understand that you can't build a fast CISC processor in analog, you have to actually build a big mishmash of multiple RISC processors that together simulate a single CISC processor. To make it easy enough to program, it appears as a single thing, it even has fake timing semantics that are phrased as if it is a traditional digital logic circuit built from analog parts, but those analog parts are actually multiple levels of code below the interface you can touch. This goes back to the 1950s! Fast computers on the general market were already using microcode in the early 1960s! If you don't want microcode, stick to running RISC processors, and don't ask for fancy games. You can have tight real-time timing, but you won't get high total throughput or a useful cache.
We even have ignorant stuff on slashdot about "a separate chip inside Intel CPUs" which doesn't even show knowledge of what a "chip" is. And there are numerous IP blocks inside of any processor, the implication that there is something extra there is rather lame. Even an 8 bit RISC microcontroller has numerous IP blocks!
Re:One more time, my friends! by vtcodger · 2017-06-08 11:11 · Score: 4, Insightful

"This has nothing to do with any of the complaints over IME since this functionality is completely within the user's control."
As I read it, ME is sort of like the Hotel California. You can turn it off any time you wish. But it's still there and running. (Where is it getting it's power from?)

--
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
Re:One more time, my friends! by Z80a · 2017-06-08 12:11 · Score: 2

It's not a feature if you can't control it.
Re:One more time, my friends! by Aighearach · 2017-06-08 13:13 · Score: 1

It's not a feature if you can't control it.
That's just 100% pure derp.
If you'd own your statement, you might say something. But all you did is derp on my screen.
Are you saying that features you can't control are features you don't want? That has a different meaning than the stupid shit you actually said.
And in this case, if you didn't want microcode that you can't control you wouldn't buy a CISC computer at all. If you want to own a computer that can play graphical games, for example, you're already asking for microcode. You might not have the technical knowledge to understand that, but that doesn't change what is true. Nobody is going to build a CISC computer that gives the user control over the microcode because that would add a huge amount of engineering and QA. It is way better to just make it so that it mostly can't be updated.
Of course, the features in the story, that's all stuff that you can control. That's the whole point; you can control it, so if you accidentally install "malware," (or your OS does it for you) then it will have access to certain features! If you had those features turned off then you're fine. That's the situation here; if you turn IME on in your BIOS, and then install malware on Windoze, that malware can use the windows update features to patch an IME driver in memory, and thereby get access to it.
It also says right in the story that it is turned off by default. So clearly you do control it.
Re: One more time, my friends! by Anonymous Coward · 2017-06-08 13:17 · Score: 0

In a laptop, using the "idle" voltage, you know, that small amount of volts it keepa consuming so you can press a soft button somewhere and have it power on, also keeping something like nvram up in macbooks. For pcs same shit, unless you unplug from the wall and unplug your lan cables, there are plenty of power to drain
Re:One more time, my friends! by kevmeister · 2017-06-08 13:40 · Score: 1

While I think it is imperative that a means to disable ME be available, it was never a secret. It was announced several years ago (around 2009) at conferences and press releases. Initially it was only on Xeon and processors intended for server use. My 6 year old Core5i system does not have it and I'm uncertain how low in the Intel CPU family it goes by now. It has many benefits for managers of datacenter machines as it allows access to unattended systems, even when they are down.
Yes, people WERE asking for this. Many vendors developed their own add-on hardware to do this. In a world where most systems lack a serial interface, it replaces the use of this for debugging and the like.
My question is not why it is there, but why is it not disabled by default? In datacenters and network hotels, it's very valuable, but there is no reason that it should ever be enabled by default and even less reason it should not be simple to turn off. Even a jumper would be acceptable.

--
Kevin Oberman, Network Engineer, Retired
Re:One more time, my friends! by Z80a · 2017-06-08 13:43 · Score: 1

The ME have nothing to do with the microcode, it's a separate CPU embedded in the CPU that have no relationship and don't actually perform anything related to the main CPU, and it's only present on the newer Core Ix series.
It was also available on the Core 2 computers, but was embedded on the motherboard rather than CPU.
And it's a separate CPU with its own proprietary hidden ROM that can't be audited and can access your network, memory, disk etc..
Re:One more time, my friends! by Aighearach · 2017-06-08 16:57 · Score: 1

The ME have nothing to do with the microcode[blah blah blah]
Absolutely, never said differently. I was broadly addressing two separate idiocies, one relating to IME, the other relating to people whining about Intel's CPUs having extra secret code that they don't understand the reasons for. For most of the slashdot, that is just one blurry thing about Intel CPUs being like systemd.
As for auditing, you can't audit the hardware in a CISC system. End of story. There is no chance. You don't really even want a processor if need that, you want programmable logic.
Re:One more time, my friends! by Z80a · 2017-06-08 17:21 · Score: 1

Well, you can hide a CPU in a RISC processor as well, pretty much do the same exact thing as the ME Engine but just don't tell anyone about it.
Re:One more time, my friends! by cfalcon · 2017-06-08 18:44 · Score: 1

> I'm uncertain how low in the Intel CPU family it goes by now
Go ahead and research it, you're in for a GREAT time. I bet you can't find one single Kabylake, Skylake, Broadwell, or Haswell without it.
> It has many benefits for managers of datacenter machines
If it was limited to those it might make some sense.
> but why is it not disabled by default?
The vuln in question is not a default feature. Remote management is not enabled by default, neither is this goofy serial-over-TCP thing.
The real question is, if you remove the ME through hardware modifications, why does the Intel chip shut down after 30 minutes? Why is it SO mandatory on EVERY chip?
Re:One more time, my friends! by thegarbz · 2017-06-08 20:16 · Score: 1

It is, but the vast majority of the functionality that exposes attack surfaces like e.g. SOL get disabled.
Again, (and one for the moderators who don't understand the difference between facts and trolls) there's legitimate complaints about IME, it's existence, it's lack of information, and the potential for auditing. But an attack that affects a user controlled value added feature like SOL is not one of them.
Re:One more time, my friends! by jabuzz · 2017-06-08 21:52 · Score: 1

Really, can you point to a single Tier1 server vendor that is using Intel's AMT for lights out management? Certainly it's not HP, Dell, Lenovo or Oracle. Heck the ASRock mini-ITX board on my self-build home server is not using AMT either.
They all without question using shitty Java VNC based crap that requires me to keep a collection of ancient browser and Java versions to interact with them all. The best is the now old but still perfectly functional Sun servers that won't work with any remotely modern version of Java because they don't follow what was best Java practice when they where new and modern versions of Java will have nothing to do with them and there is of course no firmware update to fix it.
Re:One more time, my friends! by Anonymous Coward · 2017-06-09 04:37 · Score: 0

if intel couldn't make remote management feature in a verifiable/trustable way then they should have only put it on some chips/MBs. instead, they made it virtually impossible to avoid. they are whores of the surveillance state and it sounds like you are too.
Re:One more time, my friends! by Aighearach · 2017-06-09 06:45 · Score: 1

Right, but nothing is "hidden." Fuckin' duh.
Yeah, if you can't comprehend what features are on an integrated circuit, then you don't know what it does and shouldn't talk about it.
And if you don't fucking know, then you also don't fucking know and you don't even have to worry about if it is an integrated circuit or a toaster.
OTOH, if you know about IME and what it does, then there would be no surprise to find it on CISC CPUs intended for both servers and workstations. You would not tent to find those features on a RISC CPU because they're not being designed for server or desktop operating systems. You're not going to have sysadmins who have to manage PEBCAK needing it at all on RISC systems, even when on the same network, because the RISC systems are going to be appliances.
The features aren't about tinfoil, they're actually about how stupid the average IT employee is and the fact that they can't be trusted with control of their own workstation. Just look at the idiots on slashdot; half of them are this stupid for a living, using a computer.
Re: One more time, my friends! by Brockmire · 2017-06-09 07:54 · Score: 1

The simplest answer is that it detected modified hardware and shut down as a precaution. I think this is reasonable.
Re: One more time, my friends! by Anonymous Coward · 2017-06-09 08:46 · Score: 0

Cool, but that is wrong. Go check out puri.sm and openboot for more about the 30 minute timeout, from engineers attempting workaround with varying degrees of success.

Good selection by erapert · 2017-06-08 08:18 · Score: 5, Insightful

Workstation class machines are the ones that usually have the ME installed and enabled and these machines are also the most likely to have juicy information on them compared to sally-sue's facebook machine.

Also, Stallman was right all along.

Re:Good selection by Anonymous Coward · 2017-06-08 08:22 · Score: 0, Funny

Stallman has always been wrong about hygiene
Re:Good selection by thegarbz · 2017-06-08 08:40 · Score: 1, Interesting

Also, Stallman was right all along.
About what? About a feature which is controlable in the BIOS that offers power users a choice of network administration being a possible attack?
Oh you didn't realise this was something you could disable and has nothing to do with any hidden code did you?
Re:Good selection by myrdos2 · 2017-06-08 08:43 · Score: 3, Interesting

Also, Stallman was right all along.
He usually is: Intel's chips contain a security hazard
As I recall, Intel came out with a rebuttal that went something like: "It's perfectly secure and a standard computer management feature, you bunch of dunces." I hope they like that crow they're eating.
Re:Good selection by Anonymous Coward · 2017-06-08 09:08 · Score: 0

Except that when disabling AMT via BIOS, the SOL port is still open on many computers. So, how much control do you really have?
Re:Good selection by Aighearach · 2017-06-08 09:38 · Score: 1

That will still be their response, and you should be able to detect by it if they're eating crow at all, or if you're just daydreaming.
It may be that it is secure and it is a standard feature that many companies want, and that the people complaining are in fact not only dunces but clear ignoramuses.
You can turn the feature off. And it isn't an obscure feature; it is an enterprise feature. There is actually a difference.
Everybody who knew said all along that if you add enterprise-level management software, it becomes an attack vector. Nobody disagreed with that. It is also a security vector, and for the same reasons. Yes, having a more powerful management tool enhances the power of whoever is controlling it, and malware on the network does happen in practice. It isn't perfect.
But lack of perfection does nothing to show that there is a problem, or that they'd be more secure without the feature. Obviously individuals and small business are better off without it, but any workstation or business computer comes with those settings in the BIOS. The only computers without the settings are the cheapo consumer stuff that don't even have these features anyways.
Re: Good selection by Anonymous Coward · 2017-06-08 09:46 · Score: 1

Einstein didn't care much about it either.
Re:Good selection by cfalcon · 2017-06-08 10:13 · Score: 4, Informative

> You can turn the feature off
You can't, though. In fact, if you actually remove the ME code, the Intel chip enters a halt state after 30 minutes. AMD is worse: the cores are held in reset until released by the PSP.
Your pedantry relies on the fact that you can disable the particular feature that a vulnerability was discovered in. But that doesn't solve the problem, because there's still all that spooky code running in an unauditable way. This is at least the THIRD ME vuln in the last year or so.
> Everybody who knew said all along that if you add enterprise-level management software, it becomes an attack vector
Why is the ME present on every machine, no matter how small? Why is it in every laptop, desktop, tower, workstation, and server? Why all that ubiquity, if the only people who could ever make use of it are enterprise guys who pay for support and have a conformant BIOS and MOBO and turn it on? WHY IS IT EVERYWHERE????
Re: Good selection by Anonymous Coward · 2017-06-08 10:47 · Score: 0

That's why we have indian h1b's. To keep the scent of genius fresh.
Re:Good selection by networkBoy · 2017-06-08 11:05 · Score: 3, Interesting

Why is the ME present on every machine, no matter how small? Why is it in every laptop, desktop, tower, workstation, and server? Why all that ubiquity, if the only people who could ever make use of it are enterprise guys who pay for support and have a conformant BIOS and MOBO and turn it on? WHY IS IT EVERYWHERE????
You really want to know why?
Efficiency of development.
AMT and it's components are where all the vulns have been found (so far).
ME is a kernel that these other applications run on.
Among other applications that run on the ME kernel (and that were formerly separate firmware processes on separate chips [thus higher hardware and maintenance costs]):
PMC (power management controller, the ability to suspend and hibernate)
PECI (CPU thermal management, keep you from smoking your i7 when the FAN dies)
PMX (reset controller)
PowerGate (lower power consumption on NOPs)
QST (Fan controller, so your fans aren't always at max RPM)
SmBus (DIMM timings and battery monitoring, along with other system health info)
I'm sure there's more, but I simply no longer remember everything stuffed in the CSME.
Long and short of it is:
ME is the SystemD of chipsets. It's a lot easier to use common code and a common hardware to do all these things than it is to maintain each one separately. I wouldn't expect it to change anytime soon either, but an easy mitigation would be removing any world facing interface from the ME connected systems (E.g. AMT).
If you're really worried about it get a "Min SKU" part. these only have what's needed for the machine to actually boor and run safely, none of the "value added" stuff, and if you're extra paranoid never use the on-board LAN (port 16992 BTW if you want to talk to AMT).

--
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
Re:Good selection by Anonymous Coward · 2017-06-08 11:12 · Score: 0

This comment doesn't disturb me - the joke's old and tired but whatever. What disturbs me is that some imbecile modded it "insightful" rather than "funny".
Re:Good selection by Trogre · 2017-06-08 12:49 · Score: 1

No, I didn't realise that choosing to disable AMT in a BIOS disabled every single component of AMT, including SOL, which is what this story is about.
Please, tell me more.

--
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
Re:Good selection by Aighearach · 2017-06-08 13:27 · Score: 1

That's a bunch of nonsense, it comes turned off. You don't "actually remove" part of the CPU, and you don't know how quickly it would fail because you've never spent the time to xray the chip and find the part you want, and lase it out while the chip is running. And then repeat until you get the process working. Nobody would do that.
You can't get around the fact that if you want a CISC computer, which includes any computer with significant branch prediction and CPU cache (required for to run any sort of neckbeard games) then your CPU doesn't even implement the hardware that is exposed to the user. With a RISC CPU the registers are probably real hardware registers, actual analog switches. In a CISC CPU, who knows what the registers are, they're probably just memory locations. The analog switches are multiple levels of abstraction below what you can interact with. You can't give the programmer access to what is really going on, and also provide the features that programmers want. Everybody who actually does the work want the CPU to expose an interface that acts like it is real old-school hardware, but no CPU could actually be built that way and have high performance.
Just pointing at complexity and asserting that it is pedantry isn't very interesting. There are real reasons why CISC CPUs must use microcode, and why the programmer won't have access to that layer. If you don't like it, just stick to RISC CPUs and don't ask for fancy graphics, branch prediction, or high IO bandwidth. Also, don't use any built-in CPU peripherals like DMA or I2C support, you're going to have to bit-bang that stuff to avoid accidentally using a peripheral IP block running mystery code.
Re: Good selection by Anonymous Coward · 2017-06-08 14:22 · Score: 0

Dude, fuck off with your CISC and microcode shit, AMT has nothing to do with that.
Re:Good selection by cfalcon · 2017-06-08 18:24 · Score: 1

Your post is badly misinformed.
First, lets get to the meat of it: you don't need an ME, except that the chip will stop working (again, after 30 minutes) if the ME code is removed. There are certain machines on which the ME has been successfully neutered, but this physical hack (which involves reflashing, certainly no CPU modifications) is limited to a few motherboards. Still, it should trivially debunk your claim. Further evidence includes the fact that the ME wasn't included (or mandatory) until a few years ago, and prior versions worked just fine without it. In any event, the fact that any intel chip will work for exactly half an hour before entering HLT state should prove that it is not in any way necessary to run- except that Intel has applied a kill switch.
It doesn't "come turned off". The specific settings needed for THIS vulnerability do come disabled: I said as much. The problem is that the entire AMT / ME system is a giant mess of impossible to debug code only known to a handful of Intel engineers, who have at this point made MULTIPLE mistakes. There's one that lets you log in to any system with it active, and this new one is a vulnerability to a different feature. It's possible that ALL features have bugs, backdoors, or both. The fact that this is wildly privileged ( runs at a more privileged permission set than level 0, "-1", or even "-2") and has access to ethernet and RAM should be enough to be concerned: the fact that this code is unauditable, omnipresent, and has multiple known bugs should be enough to be angry: the fact that the code is mandatory should make you deeply suspicious of bad acting.
Ok, second, on to the dessert.
> if you want a CISC computer
Irrelevant. CISC CPUs do not require this. They existed before this: they run without this. This has nothing to do with microcode.
> With a RISC CPU the registers are probably real hardware registers
Intel chips have physical registers, but the architectural registers differing from the physical registers (and having a lot more physical registers) is a reasonably old optimization trick that all modern x86s use. But HEY, so does ARM, a supposed "RISC" architecture, and the first machine to implement this was a RISC chip as well, IBM's POWER series. There's not much difference between modern RISC and modern CISC. "CISC" was mostly invented to slam RISC in the first place. It's not a real distinction in modern computing, and is a bit debatable historically anyway. Games, and other things, work just fine when compiled for "RISC" chips.
>There are real reasons why CISC CPUs must use microcode
Which is offtopic: nothing about Intel's management engine involves microcode.
> If you don't like it, just stick to RISC CPUs
Offtopic and wrong: a RISC chip can have something like this attached, or not.
Re:Good selection by cfalcon · 2017-06-08 18:30 · Score: 1

> If you're really worried about it get a "Min SKU" part.
Name one that doesn't have ME.
>if you're extra paranoid never use the on-board LAN
I don't, but I shouldn't have to.
The concerns with ME are in two categories: one, it could have bugs in it. That's proven beyond a doubt: it has wildly exploitive bugs that live at a level you simply can't detect. That was a theory for years, now it is proven beyond ANY doubt. Two, it could have backdoors. You could argue that any bug that gives access like these is already these things. We shouldn't have to rely on faith, smoke, and mirrors to be sure that the digital infrastructure we've built every goddamned thing on isn't corrupt at its core. If Intel wasn't hostile, they would disable the 30 minute timeout. If AMD wasn't hostile, they would allow cores to process instructions with no PSP present, or be open source (as they are reportedly considering). We simply should not be in this position, and there's no opt out that I'm aware of.
Hoping that the BIOS, the motherboard, and the choice of PCI network adapter aren't compatible (to prevent a possible bug or backdoor) isn't really a great way to live bro.
Re:Good selection by rastos1 · 2017-06-08 19:47 · Score: 1

While I mostly agree with you, I found no traces of ME on my desktop machine at home (admittedly it is several years old) and neither on three desktops at work (one of them being at about 2 years old). And yesterday I checked one laptop that is only several months old and found no traces either.
Re:Good selection by thegarbz · 2017-06-08 20:13 · Score: 1

It doesn't. What it does do is disable a lot of the common run of the mill remote access things like SOL which is what this article is about.
Re:Good selection by Anonymous Coward · 2017-06-08 23:52 · Score: 0

What it does do is disable a lot of the common run of the mill remote access things like SOL which is what this article is about.
No it doesn't. The SOL port remains open, leaving it vulnerable to attacks, which is what this article is about.
Re:Good selection by Anonymous Coward · 2017-06-09 04:51 · Score: 0

you're an idiot.
Re:Good selection by rastos1 · 2017-06-09 07:30 · Score: 1

Thank you, that was very enlightening.
Re:Good selection by Aighearach · 2017-06-09 07:55 · Score: 1

Well, sure, if you don't understand what topics are included in a post, it will look wrong to you in various ways. But it would be more effective to understand what you're replying to, so your reply is on-topic.
Most of what you say is just some version of reality, twisted and spun really hard, the details forgotten. Like, IBM POWER series. It is true that its history and original instruction set were RISC, an instruction set created a decade before the thing that was actually implemented. So the books generally list it as RISC. And it is certainly true that you write code for that style of big iron that uses it in that way, and get really high performance. But they suck as workstations. The only reason it is nice as a user is because if you had that sort of thing, they spent 10x more for it and so it truly is 5x faster even at a desktop workload. Especially the later ones that would be most relevant, since they had pipelining and microcode and native CISC features even including x86 instruction support. It is kind of hilarious if that is the example of RISC system.
Also, you say IME doesn't come turned off, except it does come turned off, because you don't have access to Intel's microcode. That is logic salad, a total fail. This vulnerability is from the operating system driver being able to write to the IME. The ability to do that, the user-facing part of the hardware, is controlled in the BIOS by the user and it comes disabled. The OS cannot talk to the IME chip. That the IME chip has other code on it is not relevant. If you want a modern CISC system, and you want the fast fancy computer that can play neckbeard games, all the hardware is actually going to be microcode. And they won't tell you the details. If you want an x86 instruction set, guess what? It will not exist in hardware. When you buy an x86 from any vendor you're buying a black box x86 emulator. The only way around that, the only way to know what is really going on, is if you're running RISC hardware where the instruction set is actually implemented using physical registers and logic units that match what is described in the datasheet. And you won't be playing fancy games.
You will not know what is running on the other parts of the CPU, so why try to single out the IME as if you could know what is running on it? We're talking about a black box emulator. You don't know what it is "really doing." You have to trust the hardware vendor if you want to use the product.
Re: Good selection by Brockmire · 2017-06-09 08:03 · Score: 1

You misunderstand. If ME is disabled, so is SOL. They are finding it active already. "Microsoft can't say if these state-sponsored hackers found a secret way to enable this feature on infected hosts, or they just found it active and decided to use it."
Re:Good selection by networkBoy · 2017-06-12 07:59 · Score: 1

ME will be present on all systems, as it is now what runs what used to be separate sub systems.
*most* of said systems have no I/O to the rest of the world and the MinSKU parts are the ones that have only what's needed of those systems to keep your platform stable. Pretty sure you don't want to run a system without a PMC or with no support for SPD timings.
The higher level junk is where the proven vuls are (and yes you are absolutely correct there, as well as that you *shouldn't* have to worry about the LAN being an issue).
As someone who's worked on CSME for 6 years and has seen the codebase for the kernel (not AMT, my specialty was power management) I would still be confident in having it on my system in a MinSKU config.
I no longer work for Intel, and likely never will again given my reasons and conditions for leaving, but even at that I can't condemn the kernel on this thing. ME 10 and older, I won't trust the later kernels. FYI the team responsible for the AMT vulns killed off the team that developed the rest of the platform over the last couple years and now owns the entire ME, so the team with the proven vulns is now the team in charge. :'(

--
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump

That's what you get when you use LUDDITE software! by Anonymous Coward · 2017-06-08 08:18 · Score: 1, Funny

Modern app appers only use App Runtime Modules (ARM), NOT LUDDITE Intel processors with LUDDITE software!

Apps!

And this is the problem... by TWX · 2017-06-08 08:18 · Score: 1

...with the computer-within-a-computer model. Instead of doing one thing and doing it well, and to use a cliche, putting all of one's eggs in one basket and then watching the basket, a fragmented model means that inevitably pieces get missed, as the proliferation of extra and possibly extraneous systems makes it impossible to keep-up with everything going on.

More and more layers are piled-on, and more and more points are created for there to be problems.

--
Do not look into laser with remaining eye.

Re:And this is the problem... by rjmx · 2017-06-08 08:47 · Score: 5, Funny

You're talking about systemd, aren't you?
Re:And this is the problem... by ColdWetDog · 2017-06-08 08:48 · Score: 1

mmmm omelettes.

--
Faster! Faster! Faster would be better!
Re:And this is the problem... by rahvin112 · 2017-06-08 11:42 · Score: 1

And pretty soon you have a bone Vampire breeding like a rabbit and your overflowing with boneless sheep.

Please... by Anonymous Coward · 2017-06-08 08:19 · Score: 0

... make the font in the PDF thinner and even more light-grey.. it has too much contrast...

/sarcarsm

AMT by sexconker · 2017-06-08 08:19 · Score: 2

Fuck AMT (and AMD's PSP).

They have almost zero real world benefit, and are just absurdly dangerous.

Re:AMT by DontBeAMoran · 2017-06-08 08:23 · Score: 1

I thought the PSP was made by Sony.

--
#DeleteFacebook
Re:AMT by Anonymous Coward · 2017-06-08 12:29 · Score: 0

Then start educating yourself on "trusted computing". Never again will you think of a toy when reading PSP
Re:AMT by tepples · 2017-06-08 13:47 · Score: 1

True, there's a Platform Security Processor in the 64-bit AMD Jaguar processor in Sony's PlayStation 4 console. But PaintShop Pro is Corel, and Program Segment Prefix is Microsoft, cribbing from Digital Research.
Re:AMT by DontBeAMoran · 2017-06-09 02:34 · Score: 1

Paint Shop Pro?

--
#DeleteFacebook

noooo... not AMT by Highdude702 · 2017-06-08 08:19 · Score: 1

I thought they said it was 100% secure, and this would never happen.. lol fools they are.

Re:noooo... not AMT by currently_awake · 2017-06-08 08:33 · Score: 1

It's 100% secure against YOU. The Government (that probably paid for it to be installed) had the keys from the start.
Re:noooo... not AMT by Highdude702 · 2017-06-08 08:42 · Score: 1

LOL that sounds good. but anybody with money to waste on a few cpu's could RE the thing with the skilled help of others(available on the internet if you know where to look) If I had the money and the will, I guarantee somebody I know would know the proper person to contact to get the information needed to access said backdoor. And obviously somebody has already done this(see article). I fully understand where you're coming from, Intel even went as far as to say it was impossible for somebody to hack. But nothing is impossible to hack given the correct amount of time, and money. That is why we are where we are when it comes to network security, or lack there of. This is why open hardware is a good idea. Same for open software. At least then you hope that the good guys find it before the bad guys, and quicker return time for high level exploits being fixed if the bad guys do find it first. But given Intels past shady practices I personally would not put having a backdoor for governments past them.
Re:noooo... not AMT by Aighearach · 2017-06-08 09:40 · Score: 1

I thought they said it was 100% secure...
I don't believe either half of that; you didn't really think about it, and they didn't actually say that.

AMD for the win! AMD for the max pci-e in each cpu by Joe_Dragon · 2017-06-08 08:20 · Score: 0

AMD for the win! AMD for the max pci-e in each cpu! Intel next round better be cheaper / better and no more of this cut down BS. Intel even tried cpu DLC windows only and it failed

Obligatory:Intel CPU Backdoor Report (May 5 2017) by Anonymous Coward · 2017-06-08 08:22 · Score: 5, Informative

The goal of this report is to make the existence of Intel CPU backdoors a common knowledge and provide information on backdoor removal.

What we know about Intel CPU backdoors so far:

TL;DR version

Your Intel CPU and Chipset is running a backdoor as we speak.

The backdoor hardware is inside the CPU/Bridge and the backdoor firmware (Intel Management Engine) is in the chipset flash memory.

30C3 Intel ME live hack:
@21m43s, keystrokes leaked from Intel ME above the OS, wireshark failed to detect packets.
[Video Link] 30C3: Persistent, Stealthy, Remote-controlled Dedicated Hardware Malware
[Quotes] Vortrag:
"DAGGER exploits Intel's Manageability Engine (ME), that executes firmware code such as Intel's Active Management Technology (iAMT), as well as its OOB network channel."

"the ME provides a perfect environment for undetectable sensitive data leakage on behalf of the attacker. Our presentation consists of three parts. The first part addresses how to find valuable data in the main memory of the host. The second part exploits the ME's OOB network channel to exfiltrate captured data to an external platform and to inject new attack code to target other interesting data structures available in the host runtime memory. The last part deals with the implementation of a covert network channel based on JitterBug."

"We have recently improved DAGGER's capabilites to include support for 64-bit operating systems and a stealthy update mechanism to download new attack code."

"To be more precise, we show how to conduct a DMA attack using Intel's Manageability Engine (ME)."

"We can permanently monitor the keyboard buffer on both operating system targets."

Backdoor removal:
The backdoor firmware can be removed by following this guide using the me_cleaner script.
Removal requires a Raspberry Pi (with GPIO pins) and a SOIC clip.

Decoding Intel backdoors:
The situation is out of control and the Libreboot/Coreboot community is looking for BIOS/Firmware experts to help with the Intel ME decoding effort.

If you are skilled in these areas, download Intel ME firmwares from this collection and have a go at them, beware Intel is using a lot of counter measures to prevent their backdoors from being decoded (explained below).

Useful links:
The Intel ME subsystem can take over your machine, can't be audited
REcon 2014 - Intel Management Engine Secrets
Untrusting the CPU (33c3)
Towards (reasonably) trustworthy x86 laptops
30C3 To Protect And Infect - The militarization of the Internet
30c3: To Protect And Infect Part 2 - Mass Surveillance Tools & Software

1. Introduction, what is Intel ME

Short version, from Intel staff:

Re: What Intel CPUs lack Intel ME secondary processor?
Amy_Intel Feb 8, 2016 9:27 AM

The Management Engine (ME) is an isolated and protected coprocessor, embedded as a non-optional part in all current Intel chipsets, I even checked wit

Obligatory:Intel CPU Backdoor Report (May 5 2017) by Anonymous Coward · 2017-06-08 08:24 · Score: 5, Informative