Researcher Finds A Hidden 'God Mode' on Some Old x86 CPUs (tomshardware.com)

"Some x86 CPUs have hidden backdoors that let you seize root by sending a command to an undocumented RISC core that manages the main CPU," Tom's Hardware reports, citing a presentation by security researcher Christopher Domas at the Black Hat Briefings conference in Las Vegas. The command -- ".byte 0x0f, 0x3f" in Linux -- "isn't supposed to exist, doesn't have a name, and gives you root right away," Domas said, adding that he calls it "God Mode." The backdoor completely breaks the protection-ring model of operating-system security, in which the OS kernel runs in ring 0, device drivers run in rings 1 and 2, and user applications and interfaces ("userland") run in ring 3, furthest from the kernel and with the least privileges. To put it simply, Domas' God Mode takes you from the outermost to the innermost ring in four bytes. "We have direct ring 3 to ring 0 hardware privilege escalation," Domas said. "This has never been done.... It's a secret, co-located core buried alongside the x86 chip. It has unrestricted access to the x86."

The good news is that, as far as Domas knows, this backdoor exists only on VIA C3 Nehemiah chips made in 2003 and used in embedded systems and thin clients. The bad news is that it's entirely possible that such hidden backdoors exist on many other chipsets. "These black boxes that we're trusting are things that we have no way to look into," he said. "These backdoors probably exist elsewhere." Domas discovered the backdoor, which exists on VIA C3 Nehemiah chips made in 2003, by combing through filed patents.
"Some of the VIA C3 x86 processors have God Mode enabled by default," Domas adds. "You can reach it from userland. Antivirus software, ASLR and all the other security mitigations are useless."

Comments

Is it on the die?

[BigDukeSix]

Is the separate RISC core actually on the silicon or just in the patent? Time to get out the fuming sulfuric acid.

Re:Is it on the die?

[dunkelfalke]

It is real alright. Same with the Intel management engine and the AMD PSP.

Re:Is it on the die?

[sjames]

If you RTFA you will see that the patent hinted at it's presence and then he found it on real hardware by fuzzing.

Re:Is it on the die?

[Megol]

Lot of work to find something (partially) documented. Sandpile lists the instruction as ALTINST, the code is documented by VIA as used for testing with an MSR (Machine Specific Register) bit to enable it. If not enabled I assume it would be treated as an illegal instruction.

That some machine with a C3 processor didn't set the correct machine configuration is bad but not the end of the world - just set it correctly in the OS instead.

Re:Is it on the die?

[jarkus4]

And he could save a lot of time by reading the manual for the processor as its a documented feature (ALTERNATE INSTRUCTION EXECUTION )...

Re:Is it on the die?

[BigDukeSix]

I did read the Fine Article, thanks. A quick search of 'fuzzing microcode' doesn't immediately explain what it means in this context. That's why I asked. Help a brother out?

Re:Is it on the die?

[Anonymous Coward]

It is highly unlikely to be a separate core. It is a separate instruction decoder, allowing access to the underlying pipeline. The fact that the data sheet says the x86 state may be different is a dead giveaway.

Most CISC style machines are something else RISC like under the hood, with the CISC ISA ‘interpreted’ by a complex instruction decoder / sequencer and microcode. In this case, there are ‘just’ extra decodes (and likely microcode lines) that are a available when the control reg bit is set.

Auditable hardware and microcode, if you really care about security.

Re:Is it on the die?

[Aighearach]

Try "fuzzing code" instead. Or if you weren't sure and you said it like "Fuzzing (programming)" or "fuzzing computers" it would also work. Never say "microcode." Just know that microcode is a type of code, and use the word "code" until and unless you understand the difference and have a good reason to say microcode. If differentiates between things that only need to be differentiated if you have an additional use case related to the technology.

Re:Is it on the die?

[TheRealMindChild]

Aighearach for some reason won't answer you directly, but I will. Fuzzing is when you essentially throw piles of random data at something, usually to try to get it to break. Like if you were building a web browser, you know it works when the HTML is valid, but what if it isn't? What if it not only isn't but what if it is total random garbage? What if it is total random garbage that is 100MB large? You throw "fuzz" at it and see if it triggers any problems. In this case, they probably tried all sorts of invalid opcodes and used all sorts of random data in the registers until they found this

Re:Is it on the die?

[BigDukeSix]

Thanks, that makes sense.

Re:Is it on the die?

[Anonymous Coward]

I wouldn't worry about it.

this backdoor exists only on VIA C3 Nehemiah chips made in 2003 and used in embedded systems and thin clients

The "article" is pure FUD.

Re:Is it on the die?

[mikael]

With fuzzing, you just send random data to whatever input stream you are trying to test. This could be text processing, TCP/IP packets sent to a server socket, or machine-code instructions to a CPU. In this case, every bad instruction should be trapped and good instructions should be processed.

Re:Is it on the die?

[Anonymous Coward]

Bullshit, you got that from the wikipedia which was written 10 august 2018 ! HAHA.

Re:Is it on the die?

[tlhIngan]

Is the separate RISC core actually on the silicon or just in the patent? Time to get out the fuming sulfuric acid.

I don't think it's a separate RISC core. It's likely the main RISC core running x86 code. You see, for every processor of Pentium Pro era and afterwards, the "CPU" doesn't execute x86 instructions. Instead, there's a RISC core and a dynamic instruction translator that converts x86 instructions into RISC instructions.

On Intel at least the x86 "front end" consists of around 3-4 "instruction crackers" that can take relatively simple x86 instructions and emit up to 2-3 RISC instructions every clock cycle. There is also a more complex instruction unit that handles the complex x86 instructions. Attached to this is a cache so if the same instruction comes around again, it's not translated but simply re-issues the instructions again.

This is one reason why Spectre and Meltdown were particularly bad on Intel - as the core is relatively independent it will cache things that architecturally it shouldn't but the core didn't know any better.

And no, no x86 natively runs x86 code anymore - it's all dynamically translated into an underlying RISC machine. Nonetheless, Spectre attacks are on general optimizations made which affect all architectures using those optimizations.

As for why this processor allows this mode, I can think it's for special software implemented features - instead of implementing things in hardware, sometimes it's done in software and drivers can use this gateway to turn off the x86 translator and run native RISC code directly for performance reasons. Centaur is not a particularly fast chip, so being able to optimize heavy media applications by dropping into the native RISC mode can speed up things at the driver level.

Re:Is it on the die?

[BigDukeSix]

Hugely informative. Thanks.

Re:Is it on the die?

[jarkus4]

Nope.
http://datasheets.chipdb.org/V...

Not always a bad thing

[davidwr]

Ok, this IS always a bad thing for the typical end user, but I can see two rwal-world use cases:

* For debugging. In this case, the customer wants the fearure. For the general case, there are better, safer ways of debugging, but there nay be cases where this is preferable.

* Espionage, in which case tge real customer - your aversary - wants the feature.

Beyond this, there isn't much point.

Re:Not always a bad thing

[mmmVenison]

I would be surprised if there wasn't a backdoor in any complex system, hardware or software.

Re: Not always a bad thing

[Anonymous Coward]

In tge rwal warld, I like to use a spelings checker and proofs read my grammer before spending.

Bekause;

A) its a great feature !
2) its my preferable way to debuggings
4]. It stops tge aversary rite in there tracks!?

* More, over its less RISK than x86, AND, an nay SPARK's CPU.

,

Re:Not always a bad thing

[Anonymous Coward]

I would be surprised if there wasn't a backdoor in any complex system, hardware or software.

^ This. It's naive to imagine that the NSA hasn't pwned every significant CPU and OS that sees more than niche uses.

That's the bad news. The good news is they don't care about you. (Unless you're a "person of interest").

Re:Not always a bad thing

[BronsCon]

Yeah, Cisco is, truly, a small company.

Re:Not always a bad thing

[grep -v '.*' *]

Over a decade ago I remember an article where ARPA? DoD? (someone with the resources and interest to do this) created a special limited CPU chip with "problems" and undocumented features. They gave them to different companies, and had their techs test to see if they could locate the problems.

I understand one was a root-escalation feature, and there were supposedly many others. The point was to see how many could be discovered by "the tech community" -- I presume they military was trying to figure out their exposure to the CPUs that THEY were getting. (see initial fight in Battlestar Galactica TNG where the human fleets are remotely shut down.)

Re:Somehow

[Anonymous Coward]

You're right, it was part of the debuging core, which is present on most current cisc, risc and mips cpu's.
It could be disabled by sending a four byte sequence to the cpu during bootup, mostly done when the bios was in control, though it was better to leave it in and have an easy backdoor for when the pebkac.

greetings !

and

switch

Re: Backdoor to God?

[Anonymous Coward]

son of God and Mary

Doesn't that make God a rapist?

This has no name and is not supposed to exist ?

[Cochonou]

From the datasheet itself:

ALTERNATE INSTRUCTION EXECUTION
When set to 1, the ALTINST bit in the FCR enables execution of an alternate (not x86) instruction set. While setting this FCR bit is a privileged operation, executing the alternate instructions can be done from any protection level.
This alternate instruction set includes an extended set of integer, MMX, floating-point, and 3DNow! instructions along with additional registers and some more powerful instruction forms over the x86 instruction architecture. For example, in the alternate instruction set, privileged functions can be used from any protection level, memory descriptor checking can be bypassed, and many x86 exceptions such as alignment check can be bypassed. This alternate instruction set is intended for testing, debug, and special application usage. Accordingly, it is not documented for general usage. If you have a justified need for access to these instructions, contact your VIA representative.
The mechanism for initiating execution of this alternate set of instructions is as follows:
1. Set the FCR ALTINST bit to 1 using WRMSR instruction (this is a privileged instruction). This should be done using a read-modify-write sequence to preserve the values of other FCR bits.
2. The ALTINST bit enables execution of a new x86 jump instruction that starts execution of alter- nate instructions. This new jump instruction can be executed from any privilege level at any time that ALTINST is 1. The new jump instruction is a two-byte instruction: 0x0F3F. If ALTINST is 0, the execution of 0x0F3F causes an Invalid Instruction exception.
3. When executed, the new 0x0F3F x86 instruction causes a near branch to CS:EAX. That is, the branch function is the same as the existing x86 instruction
jmp [eax]
In addition to the branch, the 0x0F3F instruction sets the processor into an internal mode where the target bytes are not interpreted as x86 instructions but rather as alternate instruction set instructions.
4. The alternate instructions fetched following the 0x0F3F branch should be of the form
0x8D8400XXXXXXXX where 0xXXXXXXXX is the 32-bit alternate instruction
That is, the alternate instructions are presented as the 32-bit displacement of a
LEA [EAX+EAX+disp]
instruction. This example assumes that the current code segment size is 32-bits, if it is 16-bits, then an address size prefix (0x67) must be placed in front of the LEA opcode.
5. Upon fetching, the LEA “wrapper” is stripped off and the 32-bit alternate instruction contained in the displacement field is executed.
6. The alternate instruction set contains a special branch instruction that returns control to x86 fetch and execute mode. The x86 state upon return is not necessarily what it was when alternate instruction execution is entered since the alternate instructions can completely modify the x86 state.
While all VIA C3 processor processors contain this alternate instruction feature, the invocation details (e.g., the 0x8D8400 “prefix”) may be different between processors. Check the appropriate processor data- sheet for details.

Re:This has no name and is not supposed to exist ?

[cleerline2.0]

This seems pretty heavy stuff. I understand that bad actors could make use of this and there could be lots of conspiracy theories about why its in there, but is this level of control really nessesary for debugging or is it just for convenience or does it look suspicious?

Re:This has no name and is not supposed to exist ?

[Anonymous Coward]

It is a much cheaper version of what exists on Intel. But the Intel one requires hardware access, and it is disabled in hardware by grounding the appropriate pins used to access the feature in every non-development motherboard.

Or so it was. It is now possible to access it through USB nowadays (cheaper than wiring a development board), if the vendor screwed it up in the firmware... That said, it is not something a program in the host cpu can access, it *STILL* requires the appropriate hardware. So, it is not nearly as dangerous as the VIA one.

Mind you, disabling the VIA god mode by default is a three-instruction patch we can add to every OS kernel, now that it is clear there would be a benefit from it. But you can *still* enable it if you get root and that damn /dev/msr security-hole-from-hell-device is present -- but then, we can also patch it to forbid that braindamage. You can always enable it from the kernel/ring 0, but at that point, you no longer need to, anyway.

Re:This has no name and is not supposed to exist ?

[Anonymous Coward]

So then this whole article is BS?

I was wondering why all of the code after the 0x0F, 0x3F was just "bound" statements with arbitrary numbers after them. He wrote the exploit code in this alternate instruction set. Meanwhile the article makes it sound like he spent weeks just fuzzing out the byte sequence "0x0F, 0x3F" and says nothing about how he determined that it needed to be followed by LEA instructions with offsets that were a completely different instruction set. Just imagine how many useless byte sequences he would have had to test before figuring out that only LEA did anything useful, and that it was the offset used that determined what it did. And then he still has to figure out what different offsets do.

There's no way he just figured all of this out. He had to have read the documentation and so this is just another BS article meant to get everyone worked up over nothing. Which is pretty much the entirety of the internet (and slashdot) these days, so I guess I shouldn't be surprised.

Re:This has no name and is not supposed to exist ?

[SEE]

Obviously they used this backdoor to retroactively insert documentation of the backdoor after our brave microcode fuzzer discovered it.

Re:This has no name and is not supposed to exist ?

[jittles]

It is a much cheaper version of what exists on Intel. But the Intel one requires hardware access, and it is disabled in hardware by grounding the appropriate pins used to access the feature in every non-development motherboard.

Or so it was. It is now possible to access it through USB nowadays (cheaper than wiring a development board), if the vendor screwed it up in the firmware... That said, it is not something a program in the host cpu can access, it *STILL* requires the appropriate hardware. So, it is not nearly as dangerous as the VIA one.

Mind you, disabling the VIA god mode by default is a three-instruction patch we can add to every OS kernel, now that it is clear there would be a benefit from it. But you can *still* enable it if you get root and that damn /dev/msr security-hole-from-hell-device is present -- but then, we can also patch it to forbid that braindamage. You can always enable it from the kernel/ring 0, but at that point, you no longer need to, anyway.

Are you referring to Intel DCI? That does not require a CCA or anything like that in newer hardware. You just need a motherboard that hasn't used one of the many ways to disable to functionality and a USB 3 A-A cable that does not have the power lines connected. If DCI is disabled in hardware at the End of Manufacturing (like it is supposed to be), then you cannot enable it even with a CCA.

Re:Should the government require audit of designs?

[ArchieBunker]

I don't trust the government to properly fill potholes in the streets let alone have a design review of CPU silicon.

Re:Doom

[Rewind]

No, you looking for IDDQD.

Re:did VIA ever do anything right?

[vadim_t]

VIA is cheap. Back in the C3 days they had a bit of popularity among the people who wanted a compact server, firewall or media box. Decently fast but cool running CPUs, and good silent fans were all a pretty new development back then, so there wasn't that much choice.

So I tried.

The Nehemiah CPU was a dog. The network card corrupted some of the outgoing packets, and it was visible by naked eye by just refreshing a page served by the box and seeing how a character was wrong somewhere. Sticking a system in a small box looked pretty, but the tiny fan was noisy as hell, and it killed the hard disk from the overheating after a while. There was some kind of trouble with the power supply. Accounting for the time I spent screwing around with that junk, it would have been far cheaper to just buy a normal board with a normal CPU.

With the luck I've had with this specific product line, I'm amazed some of it is still alive today.

Re:Should the government require audit of designs?

[iggymanz]

riiiight, last I checked the USA government wanted a backdoor in everything because citizens are to be treated like criminals by default.

Surprise Re:Not always a bad thing

[davidwr]

There are plenty of complex systems with no "backdoors."

I assume "backdoor" means an intentional feature, not an unintentional security bug. If you meant an unintentionall bug, then we agree.

I also assume "the complex system" as the part that was built, not the hardware or software levels below "the system.". That is, if you claim all complex OSes that are sold independently of hardware have backdoors, you are claiming that these backdoors exist regardless of which hardware they run on, as long as the hardware works as advertised.

Re:Surprise Re:Not always a bad thing

[mmmVenison]

I take backdoor to mean an undocumented thing that allows the developers to access something that the end user isn't supposed to be aware of. So by that definition it would be intentional yes. It may not be malicious in nature, or may even be considered an inside joke or easter egg, or maybe I am paranoid.

Re:Why research a 15 year old chip?

[Anonymous Coward]

Espousing a 2003 chip to a backdoor now is useless information.

Not really. That was about the point where CPUs became "good enough" for most non-gaming uses. I am typing this on a 2004 vintage CPU (not a Via though), running a 2018 Linux distro, and it's perfectly fine. There are still many CPUs from that era in active use.

Plus, this will let him practice for finding similar issues in more modern CPUs.

"monster" CPU Re:Is it on the die?

[davidwr]

I run this. No microscope required. :)

Re: "monster" CPU Re:Is it on the die?

[Anonymous Coward]

No you don't.

Re: "monster" CPU Re:Is it on the die?

[kenh]

At a clock speed of 60 KHz? I guess that pretty much rules out a GUI, LOL...

I wonder,

[ReneR]

, whether my IDT WInChip 2 is also affected: https://www.youtube.com/watch?... .o?

Re:I wonder,

[kriston]

Could be. I am a Centaur/VIA/WinChip enthusiast. Today I still run a VIA Esther, which is also known as the VIA C7. It is essentially an enhanced C3 and it would be interesting to see what's going on there. They're still a RISC core emulating x86 and I would guess that this exploit is probably still present.

These Centaur-derived VIA processors continue to be produced by VIA. When VIA bought Centaur and Cyrix, they ditched Cyrix and continued to evolve the Centaur platform. Some of the personnel from both companies stayed at VIA to work on the Centaur platform. VIA went on to sell the Cyrix IP to AMD who continues the Cyrix platform. The code names of the chips get blurred here when VIA worked on a couple of Cyrix chips that had Jewish code names which are assigned to Centaur chips.

Fun things to know and tell: Cyrix was a reverse-engineered CISC re-implementation of the Intel architecture, starting with math coprocessors and moving on to CPUs. In contrast, VIA/Centaur was an emulation of the Intel architecture actually running on a RISC core.

History says both approaches were right.

Re:did VIA ever do anything right?

[squiggleslash]

I'm not saying the network card might also have had problems, but if you're seeing corrupted characters on a webpage, then that hints at problems beyond the network. Web pages are delivered via TCP, and TCP packets are error checked by the operating system, not the network card.

you can bet your last dollar

[FudRucker]

that they can do that with EVERY CPU built, even modern ones out there today in new desktops & laptops, and tablets & smartphones, they obviously have their own key to open root but its still there waiting for the right person to open, people like the NSA and various other high level government goons and spooks, and corporate top dawgs too

Re:you can bet your last dollar

[Megol]

If you think so you are very religious.

Re:you can bet your last dollar

[AHuxley]

Some sort of remote testing thats open source for people who want to help around the world?
They all buy the same hardware and network the needed testing?
So a person/ small team working on todays average CPU can have 100, 1000's of networked systems to run the tests on around the world?
Use something like Wake-on-LAN to power the computers getting tested.

Worse than they let on.

[Gravis Zero]

It is thought that only VIA C3 CPUs are affected by this issue. The C-series processors are marketed towards industrial automation, point-of-sale, ATM, and healthcare hardware, as well as a variety of consumer desktop and laptop computers.

Forget thin clients, if this shit is (still) controlling SCADA stuff then this is worse than the meltdown vulnerability.

Re:Worse than they let on.

[OrangeTide]

Boards with this CPU are almost certainly still out there. They probably are behind firewalls and not directly connected to the Internet so people aren't going to take the threat seriously. But we know that hackers can still sometimes get their fingers into machines on private networks. It will only take the tiniest bit of shell code ran by an innocuous service daemon to crack one of these systems wide open.

Re:did VIA ever do anything right?

[Megol]

First this chip was designed at Centaur Technology in the US, a subsidiary of the main VIA. They design x86 processors, don't blame other crap on them.
Second this isn't a problem with the chip - it's a problem in software not configuring the chip correctly according to the documentation.

Third their x86 processors were designed for a specific market for which they are/were a good fit.

Re:did VIA ever do anything right?

[Anonymous Coward]

... unless the card tells the kernel that it has receive TCP checksum offload, and then fucks it up to match. :-)

Re:did VIA ever do anything right?

[TeknoHog]

Sticking a system in a small box looked pretty, but the tiny fan was noisy as hell, and it killed the hard disk from the overheating after a while. There was some kind of trouble with the power supply.

I had a Nehemiah for a few years as I wanted a silent, low-power system. It was fine in an open case with a large passive heatsink. Those tiny-whiny fans on Mini-ITX systems are idiotic as they basically maintain the same power density. You can get completely silent systems in a regular ATX size if you choose these "mini" components and let them breathe.

For stronger systems with discrete GPUs, it's hard to get completely fanless, but third party coolers with large fans can get asymptotically close to silence. It's the same idea about reducing power density. I've never understood the need for extreme small size in home/desktop hardware, to me silence is much more important.

Re: did VIA ever do anything right?

[Anonymous Coward]

So you're saying that how Nehemiah did its Job led to Lamentations?

Re:did VIA ever do anything right?

[vadim_t]

The TCP checksum is literally a sum. It's not a MD5, CRC or anything fancy like that. As a result it's not that hard for something to slip past it.

It's been a long time since then, but recall the network performance was awful, which would be consistent with packets that are detected as bad being dropped by the kernel and causing a retransmission.

The error rate was absolutely awful too, I'm not talking about something that happened once a month. I think the error happened pretty much always and in a consistent spot.

Re:did VIA ever do anything right?

[Anonymous Coward]

TCP's error detection is fairly weak. A 16-bit CRC can only hope to catch 1 out of 65536 errors. At modern speeds, with flaky hardware that's barely working, it doesn't take long to accumulate 65536 errors, and then one of them is slipping through undetected. For the most part, the only reason we don't see a lot of errors with TCP is because our hardware is quite reliable and rarely generates any.

slight delta

[Ungrounded Lightning]

Fuzzing is when you essentially throw piles of random data at something, usually to try to get it to break.

Note that, though throwing random junk may be productive, the data is typically mostly valid stuff with some pseudo-random ignoring-spec-limits modifications. That way you get into the guts of the responding system where the violation may trigger a bug that you otherwise can't get near.

Total junk tends to hit some bail-out before it gets deep enough to be useful. You try that, too, because you never know whether there's some bug in the outer layers. But just throwing random noise at a system in hopes of hitting a bug is akin to throwing it at a text editor in hopes of getting Shakespeare, or a vaild authentication certificate.

Re:slight delta

[TheRealMindChild]

I agree. You are correct. I was trying to be somewhat apt and keep the explanation simple

Seems like good news to me

[TomGreenhaw]

My impression is that the security community is scraping the bottom of the barrel if an obscure old chip from a minor bit player is the biggest hypestorm on the horizon.

Re: REMEMBER

[c6gunner]

We should kill the guy who killed Ian!

Oh ... wait ...

Re:Should the government require audit of designs?

[mikael]

These days, the processors come as the actual silicon with firmware (microcode and nanocode) uploaded on power up. These can be changed at any time, so it wouldn;t matter.

Re: Backdoor to God?

[bn-7bc]

Well 2 questions was Mary legal at the time ( according to the laws on the books at that time) and did she concent?

Re:did VIA ever do anything right?

[drinkypoo]

First this chip was designed at Centaur Technology in the US, a subsidiary of the main VIA. They design x86 processors, don't blame other crap on them.

I'll tell you the same thing I tell people when they say the same thing about Sony. If they don't want me to look down on all their products, they can stop putting one name on all their products. VIA wanted their name on that CPU, they can deal with the fallout now.

Re:What are the other two?

[UnknownSoldier]

Looks like sloppy editing in the original article?

The demo only shows 2 bytes: 0xF, 0x3F -- as you mentioned.

Re: Backdoor to God?

[kenh]

God didn't 'penetrate' Mary, God impregnated her - humans have to 'penetrate' (personally or mechanically) to impregnate a woman, God not so much.

Don't confuse what God did to Mary with what you and your distant cousin did on that family camping trip in the tent.

Re:Why research a 15 year old chip?

[AHuxley]

The paperwork discovered the chip has something special AC.

Re:did VIA ever do anything right?

[Carewolf]

I often have to do run a check on downloaded Steam games. With several gigabytes of data, I guess the chance of something being off is small but not insignificant.

Re:did VIA ever do anything right?

[Anonymous Coward]

TCP's error detection is fairly weak. A 16-bit CRC can only hope to catch 1 out of 65536 errors.

That is not how CRC works. Maybe you are thinking about hash collisions?

A 1-bit CRC (Also known as a parity bit) is guaranteed to catch any single bit errors in a packet.
For a 16-bit CRC you can pick a polynomial that is guaranteed to detect any combination of 3 bit errors in a 64 kbit sequence or another that will catch up to 4 random bit errors in a 32 kbit sequence.

No algorithm can catch an arbitrary number of bit errors.
Some algorithms are made so that they are better at catching "burst errors" (Several bit errors in a sequence.)

A 16 bit CRC will catch single bit errors in a packet every single time. Not just 1 time out of 65536.

However, TCP doesn't use a CRC. It uses a checksum.
It is cheaper to calculate and allows for quick packet modification but is worse at catching more than one bit error.
For the cases where there only is a single bit error in a packet the TCP checksum is still as good as whatever 256-bit CRC you can come up with.

Re:did VIA ever do anything right?

[drinkypoo]

VIA used to make decent, inexpensive motherboards back in the 90s.

I had nothing but problems with them, so I'm going to call shenanigans there. That was a big problem with AMD back in the day before they made all their own chipsets. Intel made their own, and they cost a lot more than VIA, but they were a lot better, too. Intel on Intel, solid. AMD on AMD, solid. Either on VIA, terrible.

Who Done It?

[JimSadler]

Is there any entity other than government who had the power to create this vulnerability and also keep it secret for a long time? This back door could not be accidental.

OP trips over back door

[speedlaw]

Doesn't every chip have one. Kudos to the researcher, but he found last year's NSA hack.

Re:Should the government require audit of designs?

[Agripa]

riiiight, last I checked the USA government wanted a backdoor in everything because citizens are to be treated like criminals by default.

Citizens are criminals which have not been arrested, charged, or convicted yet.

Re:did VIA ever do anything right?

[toddestan]

Inexpensive, yes. Decent? No way. VIA's stuff is garbage.

I won't even deal with VIA anymore. If I find/get an old PC and it has a VIA chipset, I just scrap it for parts. Not worth the hassle.