Idiots. A user should be forced to make a physical action to enable special code or processors, not just write 20 lines of C.
The off-brand 'military-grade' x86 processors, in the library, with the root-granting 'backdoor'
A forgotten family of x86-compatible processors still used in specialist hardware, and touted for "military-grade security features," has a backdoor that malware and rogue users can exploit to completely hijack systems. The vulnerability is hardwired into the silicon of Via Technologies' C3 processors, which hit the market in …
COMMENTS
-
Saturday 11th August 2018 00:49 GMT John Savard
Different Viewpoint
Since even when the feature is enabled in the BIOS, it can only be used from ring 0 code, it isn't a security flaw that enables entry into the system; it's just a feature that makes it a bit easier to do serious damage (or, more importantly, do it without getting caught) after one is in a position to do nearly everything anyways.
What bothers me is that this potentially useful feature, because it only allows the use of augmented instruction sets if all security features are turned off, is therefore nearly useless. So firstly it's a waste of silicon; secondly, given that it somewhat weakens security, it definitely shouldn't be there if it isn't there for any sensible reason.
-
Saturday 11th August 2018 08:49 GMT JulieM
Re: Different Viewpoint
It's not a waste. It would have been insanely useful during design and testing. It could potentially be used for some niche application IRL, and their major customers were specialists. I can see why it made sense as a feature, at least in some circumstances.
Obviously, like all sharp-edged tools, it also has the potential to be dangerous if misused. It's effectively a Multiface for the PC .....
-
Saturday 11th August 2018 14:42 GMT Anonymous Coward
"It would have been insanely useful during"
Design of testing of what? The silicon itself? No need of such features to design or debug a kernel. They added a feature that fully bypass x86 security. I understand some developers find security features a pain in the ass because they block wrong code, which is exactly the reason they are there.
And this is not an out-of-band monitor executing fully separated code, you can command it from the same code running on the main CPU. A very bad design. Maybe some very strange and unsecure application may find it useful, but it's still a huge backdoor.
-
This post has been deleted by its author
-
Sunday 12th August 2018 07:09 GMT Konk
Re: "It would have been insanely useful during"
It's not really a backdoor when it's in the documentation for everyone to see and you can turn it off.
It might be strange but people buying this processor for embedded applications would have had the opportunity to know about it and disable it.
-
Sunday 12th August 2018 16:52 GMT Roland6
Re: "It would have been insanely useful during"
>It's not really a backdoor when it's in the documentation for everyone to see and you can turn it off.
Agree, this does have some parallels with the 'backdoor' that Intel chips possessed, that Joanna Rutkowska exploited with her Blue Pill rootkit.
-
-
-
-
-
-
Saturday 11th August 2018 08:52 GMT John Smith 19
Yet Another case of "Security by obscurity"
That doesn't work.
And if I'm reading that "Invocation code" right that's 6 hex digits, IE a 24bit binary number.
Shouldn't be too tough to brute force all of the actual wake up codes in that list.
A system that grants nearly unlimited access (potentially remotely) to your processors.
It's not the idea, it's the security chain that should exist around it that prevents the wrong people using it.
The simplest option is of course, not to have it in the first place.
-
-
Monday 13th August 2018 10:44 GMT phuzz
Well, it's similar, in that it was added to chips as a feature for certain users, but it's very much un-useful for consumers.
These Via chips weren't intended for home PCs, they were for industrial applications where having a RISC co-processor might have been handy. Intel's ME was designed so that large companies basically had lights-out management on their desktop machines. Both were fine for their intended purpose, but in the case of Intel, they included it in consumer machines for some reason where it was very much not a good thing.
-
-
Saturday 11th August 2018 10:28 GMT Steve Graham
I was running a Nehemiah-based system last week! Waiting for a part to arrive for my poorly "home server" (an old Thinkpad) I resurrected an ITX board as a stand-in. It's gone back in the cupboard now, and I don't think I can be bothered to set it up again to try this trick, neat as it is.
-
Saturday 11th August 2018 15:58 GMT EveryTime
This is a documented feature that should be disabled on systems that don't use it.
The only obvious bug is that a few deployed systems fail to disable the co-processor feature. That is strictly a software bug, not a processor bug.
There is a lesson here, but it's not the one publicized. It's very difficult to extend a processor's instruction set with general-purpose programmable feature and retain the original security model.
The original 8086 had a general co-processor interface. The 8087 floating point co-processor was the only Intel chip that used the interface, and it limited its set of operations to safe ones. But the interface allowed much, much more. At the time, with no protection rings, that wasn't an architectural mistake. As soon as protection was added, allowing a general coprocessor was a Bad Idea.
Now consider how that lesson applies to FPGA acceleration. That interface design has to be done very carefully.
-
Saturday 11th August 2018 17:16 GMT Irongut
"GOD MODE UNLOCKED: hardware backdoors in some x86 CPUs"
This kind of sensationalist bullshit is not helping the security industry. Every bug, exploit or malware is publicised as if it is going to cause the end of the world. Any reasonable person reading that tweet would expect the problem to affect chips from Intel and maybe AMD, no one is going to think "you know what I bet this is those chips VIA bought from Cyrix."
This is why the rest of the world doesn't listen when a real problem is found and thinks OS updates are just a pain in the ass to be avoided if at all possible.
-
-
Monday 13th August 2018 11:19 GMT PM from Hell
It may have been built by the lowest bidder but it was the lowest bidder to offer the MIL spec. I managed a roll out to gas and electricity network engineers, the guys who work on the high tension services and high pressure mains. They could destroy an ordinary laptop in days (being thrown around the van, used in wet conditions etc. The MIL grade laptops we replaced them with were just about indestructible and the guys loved the fact that they were washable. I can appreciate that battlefield use is an order of magnitude more extreme whilst our guys needed a lappy that could be perched on the edge of a trench so they could look at valve diagrams etc, drop it in the trench then carry on, no-one was shooting at them .
-
-
Monday 13th August 2018 17:36 GMT Claptrap314
Bad idea, done badly.
This chips dates from the period that I was doing microprocessor validation at AMD and IBM.
First, such a facility has 0 added value to a competent validation team. All of these chips have a special debug (JTAG) interface that allows direct access to the register file and every level of cache (including otherwise hidden state machines) on the part, plus a few other things. This interface is used to test EVERY chip BEFORE they are cut and placed into the dies. It is again used after they are died. While the chip is still in development, this interface is used to load test code (like the code I wrote) directly into the processor.
Moreover, the job of the validation team is to test all supported features of the part. The addition of such a facility creates a HUGE space of processor state transitions that have to themselves be tested.
Yes, exposing the RISC core that is behind every x86 processor since Intel's Pentium (and maybe before) can have tremendous performance benefits for specialized applications. When I was there, I wanted AMD to open up such a facility. I was brushed off by people who knew way, way more than I did about such things. In particular, I did not understand the architecture well enough to instinctively grasp the implications for things like ring-0 verses ring-3. In retrospect, it does not surprise me that the C3 simply bypassed all of that. The facilities would be operating at different levels.
So, yeah. It's probably with excellent cause that I was brushed off.
-
Tuesday 28th August 2018 23:06 GMT Anonymous Coward
Not the same
What Domas has disclosed here are instructions not previously disclosed which allow one to completely bypass all security features within the CPU, to access things normally restricted to RING-0 from RING-3, and in a major way so that all kernel memory could be read, the full CPU state could be altered. It would allow an attacker, for example, to completely take over the CPU and gain access to anything they wished.
This is a major finding, and one that hints of similar things existing in AMD and Intel, and may be the follow-on of a tweet by Domas last year, one which he never followed-up on, that he had previously found hints of this technology through his sandsifter application back then.
--
Rick C. Hodgin