Intel chips that have AMT are running MINIX

[6502coder]

http://www.zdnet.com/article/minix-inte ... ng-system/

I post this w/o comment, as it is well outside my areas of expertise.

[8Geee]

over my head also, but at leeast the BEAST has a name and a number. There has been previous warning/discussion here.

Atom N270's anyone?

Regards
8Geee

[jamesbond]

That's interesting. The only thing that matters is this:

x86-based computers run their software at different privilege levels or "rings". Your programs run at ring three, and they have the least access to the hardware. The lower the number your program runs at, the more access they have to the hardware. Rings two and one don't tend to be used. Operating systems run on ring zero. Bare-metal hypervisors, such as Xen, run on ring -1. Unified Extensible Firmware Interface (UEFI) runs on ring -2. MINIX? It runs on ring -3.

The principle is this - a higher-level ring cannot see and cannot control what happens on the lower ring. Days past ring zero is the lowest of the ring. How much in the past? During the original 80386 days (no such crap as i386, ia32, x86, or whatever else naming. Just plain 80386 - a nice number). That's right, on or before 1986.

You, as root, runs in ring 3. If you are non-root, you also run in ring 3. The Linux kernel runs at ring 0. People makes a big noise when there is a kernel security problem, but the fact is the Linux kernel can't even see what's going on ring -1, -2, or -3; a security problem there is practically undetectable and unfixable because those rings are never meant for use by "end-user" code. End-user as in, everyone else except Intel or the motherboard manufacturers. And the problem is those rings can't even be disabled.

The fact that it runs MINIX is just an indication of the scale of the problem.

People (me included) previously thought that those rings only run minimally, tightly bound code (perhaps assembly or at most bare-metal C programs). Small programs can be audited more easily and (in theory) has smaller attack surface. But now we know this is not the case. Apparently those rings runs a full-blow operating system (MINIX is a full-blown OS just like Linux, Windows, or FreeBSD); and there are programs and services that runs there. The complexity difference of a bare-metal C program vs a full-blown OS + programs, is beyond comparison.

EDIT: Typo

[Flash]

I thought Minix was the predecessor of Linux.

[jamesbond]

I thought Minix was the predecessor of Linux.

Not quite. Linus was inspired by Minix when he created Linux. Linus used Minix system as his host platform (platform that has editors, compilers etc) when he made Linux; but Linux itself is neither derived nor forked from Minix.

Minix still exists today, and that's the point the original post tried to make: that another independent, full-blown operating system is running, hidden from sight, having access to **everything**, without any supervision from anyone.

[Flash]

Wouldn't the Minix inside need the appropriate (and proprietary) drivers to be able to control or even access hardware outside the Intel chip? It seems to me that the Minix inside would pretty much be unable to do anything but whatever its job is inside the chip. Housekeeping, I suppose. Whatever a basic OS is supposed to do.

[prehistoric]

Just to contribute a little light to the subject, I'll link an article on the original debate between Tannenbaum and Torvalds.

I am also interested in the microkernel approach for hard real-time systems, but want to avoid the copying that took place in early MINIX. Avoiding this takes a radical departure in kernel design. I no longer believe the Linux kernel should be considered a kernel at all, it has simply grown out of control, to the extent it can never be debugged. (How many individuals have read all the source code themselves?)

On the subject of drivers, the microkernel would have access to the entire address space, both physical and logical. In principle the drivers you normally consider kernel-level could be written as user programs, not that I would want to try. The mess of timing restrictions in typical computer interfaces makes it nearly impossible to write logically sound I/O code. I've been waiting for an alternative since about 1990.

This is not the first iteration of the problem. The IBM 360 I/O primitives were supposed to unify operations, and dealing with lapses in those designs caused a lot of grief. We went through a new cycle with minicomputers and microprocessors. Generally, people copied what they had been used to doing in the previous generation of computer architecture, along with inherent problems.

The most interesting alternative I've seen is the exokernel approach, which has been a research project since 1994. Unfortunately, as soon as those who work on this research leave graduate school they have to conform to the present baroque designs for both hardware and software if they want jobs. We keep throwing manpower at problems that are fundamentally ill-posed, because it is impossible to start over.

[jamesbond]

Wouldn't the Minix inside need the appropriate (and proprietary) drivers to be able to control or even access hardware outside the Intel chip?

No.

The easiest way to explain this is with a graphic but I'm lazy today.

But imagine this. You have a few train stations and shared rail track between them. How does the station-master ensure that a train goes from station A to station B and not to station C or D? By telling the signalman to switch the track at the appropriate junction. Does the signalman needs to know anything about the train? No. He only needs to understand that the station-master tells him, and be able to switch the track. That's it.

Now imagine if the signalman choose not to listen to the station-master, but instead, to somebody else. You can imagine the chaos that follows.

The station-master is the CPU. The train is the "data". The tracks is the "data-bus". The signal-man is the ICH controller. Now the signalman has a new boss. Its name is Intel ME (=Management Engine). It runs MINIX. Intel ME is buried deep inside the ICH chipset, it's part of ICH.

As you can see, the MINIX only needs drivers to control the signalman (=the ICH controller). It doesn't need to know how to control anything else. Because every train passes through the track switch junction. The signalman can tell the train to stop and then examine its contents. It can redirect trains to whatever stations it likes.

The real power of ME is even more powerful that the signalman analogy. It can power up devices even when power if official "off". It can turn on and turn off the CPU. It can hijack an ethernet port for its own use (to the point that the CPU won't know that this ethernet port exist).

All these are not meant for bad things. The "management" part of Intel ME is originally meant for managing "servers". When you need to reboot a hanging server, or turning on a powered-off server, instead of sending an operator to a particular server in a particular building of a 1-building (each having 10-storeys) data centre, you just connect to the "management agent" of that particular server, and issue the "reboot" command (or the "boot" command to that powered-off server).

Instead of depending on faulty and unreliable operating-system based network statistics (which gets wiped out on every reboot), you get this data from a "management agent" that never sleeps and runs even when the computer is "powered off".

It can do this, and more. From the article:

MINIX also has access to your passwords. It can also reimage your computer's firmware (translation: re-write your BIOS) even if it's powered off. . Let me repeat that. If your computer is "off" but still plugged in, MINIX can still potentially change your computer's fundamental settings.

and

And, for even more fun, it "can implement self-modifying code that can persist across power cycles". So, if an exploit happens here, even if you unplug your server in one last desperate attempt to save it, the attack will still be there waiting for you when you plug it back in. (translation: ideal hiding place for a root-kit)

There is no question that these functions are important, and even crucial for large-scale deployment.

The question is why these functions are even needed for home, personal computers. And the fact that these "management agent", just like anything else, can be hacked and controlled by the wrong people. The fact that it runs a large-scale OS (=MINIX) means the attack surface becomes much larger and it has higher chance of being hacked.

There is question why, to avoid all the above problem, they cannot be switched off.

It seems to me that the Minix inside would pretty much be unable to do anything but whatever its job is inside the chip.

Correct. But see what kind of job it can do inside the chip. See above.

Housekeeping, I suppose. Whatever a basic OS is supposed to do.

It does a little bit more than housekeeping From the article:

In addition, thanks to Minnich and his fellow researchers' work, MINIX is running on three separate x86 cores on modern chips. There, it's running:

- TCP/IP networking stacks (4 and 6)
- File systems
- Drivers (disk, net, USB, mouse)
- Web servers

________________


PS: The PC that I wrote this post with, is an ex-business PC. It does have AMT (=Intel ME). Fortunately, the BIOS allows me to turn it off. And that was the first thing I did when I saw that option in the BIOS. But this is a 5-year old PC. Apparently, according to the story, you can't do this anymore with newer PCs.

[8Geee]

Thanks Jamesbond +10

[upnorth]

It looks like there are even more exploits now, if these are in addition to what was patched in May.

https://security-center.intel.com/advis ... geid=en-fr


article
https://www.theregister.co.uk/2017/11/2 ... are_flaws/

ADDED:
Here is the writeup by Positive Technologies, the vuln discoverer, on some of the inner workings/analysis.
http://blog.ptsecurity.com/2017/08/disa ... el-me.html

[6502coder]

Here's a follow-up to my OP:

http://www.zdnet.com/article/computer-v ... nt-engine/