Intel's Remote Hijacking Flaw Was 'Worse Than Anyone Thought' (arstechnica.com)

An anonymous reader quotes Ars Technica: A remote hijacking flaw that lurked in Intel chips for seven years was more severe than many people imagined, because it allowed hackers to remotely gain administrative control over huge fleets of computers without entering a password. This is according to technical analyses published Friday... AMT makes it possible to log into a computer and exercise the same control enjoyed by administrators with physical access [and] was set up to require a password before it could be remotely accessed over a Web browser interface. But, remarkably, that authentication mechanism can be bypassed by entering any text string -- or no text at all...

"Authentication still worked" even when the wrong hash was entered, Tenable Director of Reverse Engineering Carlos Perez wrote. "We had discovered a complete bypass of the authentication scheme." A separate technical analysis from Embedi, the security firm Intel credited with first disclosing the vulnerability, arrived at the same conclusion... Making matters worse, unauthorized accesses typically aren't logged by the PC because AMT has direct access to the computer's network hardware... The packets bypass the OS completely.
The article adds that Intel officials "said they expect PC makers to release a patch next week." And in the meantime? "Intel is urging customers to download and run this discovery tool to diagnose potentially vulnerable computers."

Saturday Ars Technica found more than 8,500 systems with an AMT interface exposed to the internet using the Shodan search engine -- over 2,000 in the United States -- adding that "many others may be accessible via organizational networks."

Comments

I don't think you know what that word means.

[fahrbot-bot]

"Authentication still worked" even when the wrong hash was entered, Tenable Director of Reverse Engineering Carlos Perez wrote.

He and I have different definitions for the word "worked".

Re:I don't think you know what that word means.

[Anonymous Coward]

The tested passwords worked, so it works, right? Why, what's your perverted definition of "worked"?

Re:I don't think you know what that word means.

[chispito]

"Authentication still worked" even when the wrong hash was entered, Tenable Director of Reverse Engineering Carlos Perez wrote.

He and I have different definitions for the word "worked".

The best phrasing would be that authentication "succeeded" despite the wrong password. You still get the idea.

Re:I don't think you know what that word means.

[hey!]

Well, if you're going to pick semantic nits, how about it being "worse than anyone thought." That would, from a pedantic point of view, be a stroke of luck.

The worst case would be where the flaw persisted for some time with some people being aware of its severity.

Re:I don't think you know what that word means.

[K. S. Kyosuke]

He and I have different definitions for the word "worked".

Come on, Type I and Type II errors are so easy to mix up. ;)

Re:I don't think you know what that word means.

[msauve]

When there is no authentication, one can't claim that it worked in any sense.

Re:I don't think you know what that word means.

[JustAnotherOldGuy]

Well, if you're going to pick semantic nits, how about it being "worse than anyone thought."

It's more likely that this worked better than anyone thought. I mean, instant root access to any Intel-run PC? It's every intelligence agency's and hacker's wet dream. No way this was an accident.

Re:I don't think you know what that word means.

[Dunbal]

Except for the guys whose job it was to subvert the authentication process.

Re:I don't think you know what that word means.

[Anonymous Coward]

Authentication did not succeed. Authentication was bypassed when the response token was zero length (or any substring of the genuine response token, but the zero length one allows you to make a guess without prior knowledge and hit with 100% accuracy).

Re:I don't think you know what that word means.

[arth1]

It's more likely that this worked better than anyone thought. I mean, instant root access to any Intel-run PC?

Not any Intel PC. Only those that have vPro capabilities with AMT support, are from 2010 or newer, have AMT configured and enabled, and have the management port exposed.
Because it's not much use unless you've also purchased the remote management software from Intel that allows using the functionality, it's not all that common to find it enabled.

Re:I don't think you know what that word means.

[tlhIngan]

When there is no authentication, one can't claim that it worked in any sense.

Actually, there's a difference in this case.

First, if you're using a normal browser, you cannot actually facilitate this bug. It's impossible. So entering a blank password at the authentication prompt - it won't work.

The reason it works is because you need to modify the HTTP headers (which is probably why it hid for so long). Remember in HTTP authentication, what gets sent is a hashed value of the username, password, nonce, and realm. It's well known how it's done, so it's not terribly secure to begin with (unless you do it over SSL), but that's HTTP authentication.

The bug is that you need to send a HTTP authentication header with nothing. A normal browser won't do this because it will always send a hash, so you needed a proxy that strips off the hash from the header and passes everything else through.

Of course, the bug is in the way it compares the hashes - as in, comparing the entered hash with its length to a strcmp() style function - the blank header forces the compare two strings of zero length returning authenticated status.

Yes, it's a serious bug, no, it's not as stupid as entering a blank password. One does wonder if other web applications are just as vulnerable, though - since I'm sure this bug is present in many other things as well (after all, a blank authentication header doesn't happen in the normal case - a browser will return something).

Re:I don't think you know what that word means.

[smallfries]

You know that Intel processors without AMT still have the capability but it is disabled in software...

Re:I don't think you know what that word means.

[Anonymous Coward]

Promote that guy to the head of an application testing team.
The application works, even when the test is black on black or pink on a pink background.
Any password works. User friendly, tick.

Re:I don't think you know what that word means.

[lsatenstein]

You know that Intel processors without AMT still have the capability but it is disabled in software...

Every processor has to accept microcode updates. Pentiums, Skylakes, AMD's.
During the life of the cpu, bugs or buglets are detected. The cpu vendor provides a microcode update that the motherboard bios sends to the processor. The microcode update corrects instructions, or even activates or can add a limited amount of new instructions.
This will be the entry point for future hackers where the CPU is installed in non-uefi managed systems.

Re:I don't think you know what that word means.

[smallfries]

It's not always the bios. We have a problem at the moment with a lab full of Skylake machines. Originally it was supposed to run debian, but uploading the microcode binary blob didn't work properly. There are only two options: grab the raw updates from Intel and overwrite the init system to insert shortly after boot, or run Ubuntu which has the binary blobs already installed. For now we have to run with Ubuntu because nobody had time to sit and go through the Intel raw update to package it for the lab.

It's a shitty situation, and it will probably get worse. The microcode patch mechanism destroys any chance of building a reproducible environemnt in the lab, knowing that there is a whole other black-box sitting on the chipset makes the situation even worse...

There are no comments

[Anonymous Coward]

"There are no comments"

Says it all, doesn't it?

Re:There are no comments

[wonkey_monkey]

Err... no?

name next feature NIIT or PTC

[Anonymous Coward]

need inspiration from the 1040

Predictable outcome

[Anonymous Coward]

Putting Internet accessible code running over the operating system was a terrible idea and this is the predictable outcome.The implementation was totally brain dead and wasn't even tested beyond "works in correct usage cases." This is the reason projects like Libreboot exist.

Re: Predictable outcome

[Anonymous Coward]

Let's see a suit and a recall of millions of laptops. I'd love to see Intel out of business.

Re: Predictable outcome

[Anonymous Coward]

"Let's see a suit and a recall of millions of laptops. I'd love to see Intel out of business"
Apple laptops aren't effected, even if they run Windows in a VM. The chips that Intel ships to Apple don't have AMT enabled.
Of course if there is a massive revolt against the OEMs who implemented this because Corporate IT lazy-asses requested it, that means more MacBooks sold, which of course will continue to run on AMT-Free Intel chips.
Win-Win... but not for Windows.

Re:Predictable outcome

[Dogtanian]

Putting Internet accessible code running over the operating system was a terrible idea and this is the predictable outcome.

Coincidentally, around six weeks back, I bookmarked this article, originally written in 2016. Notably, it says that:-

Five or so years ago, Intel rolled out something horrible. Intel’s Management Engine (ME) is a completely separate computing environment running on Intel chipsets that has access to everything. The ME has network access, access to the host operating system, memory, and cryptography engine. The ME can be used remotely even if the PC is powered off. If that sounds scary, it gets even worse: no one knows what the ME is doing, and we can’t even look at the code. When — not ‘if’ — the ME is finally cracked open, every computer running on a recent Intel chip will have a huge security and privacy issue. Intel’s Management Engine is the single most dangerous piece of computer hardware ever created.

Pedantry; it doesn't appear to be on every Intel chip, only those with vPro enabled(?) Still a horrible idea.

Re: Predictable outcome

[sexconker]

"Let's see a suit and a recall of millions of laptops. I'd love to see Intel out of business"
Apple laptops aren't effected, even if they run Windows in a VM. The chips that Intel ships to Apple don't have AMT enabled.
Of course if there is a massive revolt against the OEMs who implemented this because Corporate IT lazy-asses requested it, that means more MacBooks sold, which of course will continue to run on AMT-Free Intel chips.
Win-Win... but not for Windows.

The chips that Intel ships to Apple don't have AMT enabled.

I'm destroying some mods on this thread by posting, but I need to correct your very wrong post.

It's still physically present. No one except Intel knows what is actually baked into it and what's actually turned on at any given point. That's the fucking problem. That's why we're in this mess to begin with.

Re:Predictable outcome

[sexconker]

It's still physically in every chip from the last decade or so. Intel just disabled features based on the SKU. Whether AMT is disabled or "disabled" is unknown.

Re:Predictable outcome

[Anonymous Coward]

The ME is in every chip. AMT is only deployed on the ME if you bought one with vPro in the feature list and licensed the AMT code for deployment in your organization.

Re:Predictable outcome

[Anonymous Coward]

I'm not sure about the licensing part - different sites say different things - some say you need a license to deploy AMT, others say you need a license to deploy the Enterprise version of AMT, which works with TLS certificates instead of insecure password authentication. So it may be possibly to enable AMT just by purchasing a chip with vPro in the feature list and enabling it in BIOS. But having checked some recently purchased Xeon, i7 and i5 chips all with the vPro feature, it does seem that it does not present the authentication challenge out of the box - it needs to be enabled in BIOS first, though there may also be some back door deployment method for the convenience of network admins bulk deploying to organizations.

Re:Predictable outcome

[Anonymous Coward]

Intel Management Engine doesn't work like that. It's not something that gets applied in the UEFI or BIOS firmware. It's a completely separate processor running a proprietary and trade-secret operating system with control over much of the system resources alongside the x86 boot chain. This is specifically for security reasons: Intel ME is sold as a remote-control solution for businesses that need to maintain control over their computers even if the x86-side boot chain has already been compromised by malware.

Oh and AMD did the same thing - AMD CPUs from 2013 onward include a PSP or Platform Security Processor whose source is closed and is a black box anyway. It will hold the x86 cores in RESET until it can find a valid and cryptographically-signed firmware blob to run. Oh, and both the AMD PSP and the Intel ME implement code-signing for the x86-side firmware, which specifically prevents Libreboot from working on those platforms. CPU manufacturers do not want anyone other than licensed-and-bonded motherboard manufacturers from writing firmware code.

Re: Predictable outcome

[Anonymous Coward]

"It's still physically present."

I never said that it wasn't physically present. I said that in Apple's case, (And to be fair, not only in Apple's case.), it's not enabled.
Sort of like Cars. For decades, Cars have had "Universal" Wiring Harnesses. Maybe a Top-Of-The-Line option was heated Arm Rests. Most people didn't want or order Heated Arm Rests. Yet the wiring in the Harness for them is still there. It is cheaper to have just one Wiring Harness, rather than Wiring Harnesses customized for any and all combination of dozens of options.
Many 'Chips with differing part numbers and Specs are exactly the same out off the Foundry. Options are enabled or disabled by such things as Software, Firmware, or Fusible Links, either by an OEM or by Customer Request afterwards.

"...but I need to correct your very wrong post."
At least you were reasonably polite about it. I wish that I had $100K to give you, just so that you could take a year or so off and reverse engineer AMT, ME, and all of that Corporate IT Lazy-Ass rubbish into a stock MacBook. I would even accompany you to Best Buy and pay for the one of your choice.
You don't seem to understand just _why_ Intel does things this way. It's simple: Some, but not all, Customers want it. And if you go all Conspiracies on this, and claim that it's all part of some NSA Master Plan... why are Macbooks, (And other Gear from other Vendors...), not effected?
Thank you for your consideration.

Re: Predictable outcome

[Anonymous Coward]

Actually, I've thought of a better analogy than Wiring Harnesses. Take Canon and Nikon, please.
They produce dozens of Digital Camera models every year. It takes quite a while determining which sets of features go with which Sensor and "Imaging Engine". One Camera does 720P Video at 30fps, another Camera does it at 60fps. This Camera writes to the SD Card at twice the rate of that Camera. This other Camera has eight stops of Dynamic Range at ISO1600, while this fourth one can go to ISO3200.
They all use the same 1/2.3-inch Sensors and "Imaging Engine", and in Canon's case, there is a little Underground of Hackers who take their $200 PowerShot, and re-enable features found only on the $250 PowerShot.
Just go to Google and put in the Search Term "Hacking Digital Cameras". I get 651,000 returns. A fair number of them involve Canons.
I still haven't found the Hack that enables Heated Arm Rests, but I'm sure that one is out there.

In this case, the Conspiracy involves Obfuscation. It's like that scene in "Moscow On the Hudson" when Williams faints from being given too many Shopping Choices. Same Coffee, Different Packaging.
Yes Canon and Nikon compete, but they have found it profitable here to compete with themselves as well. When faced with so many choices for Coffee, many don't even get around to considering Tea.

Re:Predictable outcome

[Anonymous Coward]

CPU manufacturers do not want anyone other than licensed-and-bonded motherboard manufacturers from writing firmware code.

This just in: The various hackers, criminals, and intelligence spooks, don't give a damn about the code-signing, or security through obscurity, and will happily try to get around it. When they do, CONGRATULATIONS! Now you have a backdoor baked into the hardware at such a level that it's impossible to remove without approval from the manufacturer, Lucky you! You may also be surprised to learn the manufacturer's fix is you paying to "upgrade" to the latest and greatest version by buying a brand new computer! Hooray!

Code-signing does nothing to protect a system. All it says to you is: "X says this is trustworthy." Where "X" is either the owner of the key that made the signature, a coerced owner who was forced to sign it, a malicious actor who has assumed control the the key that made the signature, or a malicious actor who found a weakness in the verification code / encryption scheme / failure in implementation, and is exploiting it. To the machine it means this:
If (y == x) then
exec (payload)
else throw error

There is no attempt by code-signing to prohibit an active attack. All it says is "X thinks these bits are safe." But not all bits are equal, and if "X" is wrong, you get screwed, to the point of the signature not existing in the first place. Worse because the verification code is likely to be privileged, it's an even bigger target for potential attackers. (Then they can use it to protect their successful exploitation.) Even if they can't exploit it, the verification code prohibits the "owner" of the machine from doing anything about the vulnerability that got them hacked. Even if a patch is available, unless "X" signed it, it's useless. Even if the "owner" knows exactly what's wrong and how to fix it, it's useless unless "X" approves of it.

TL;DR Security through obscurity is a horrible security model, but code-signing is an even worse security model. Especially for the end-users or the self proclaimed "owners".

Re:Predictable outcome

[lsatenstein]

Putting Internet accessible code running over the operating system was a terrible idea and this is the predictable outcome.The implementation was totally brain dead and wasn't even tested beyond "works in correct usage cases." This is the reason projects like Libreboot exist.

What are the chances that the NSA knew about this loophole and profited from it? Is it 100% ?

Dear Intel

[Anonymous Coward]

Dear Intel,

Why should I buy your wide open backdoor chips?

What are you going to do to prevent this problem in the future?

Re: Dear Intel

[muffen]

This is unlikely to be a deliberate backdoor, it's much more likely the result of a mistake. However, if you aren't going to buy anything that has had a remote code exec vuln, you should probably consider using pen and paper, exclusively!

Re: Dear Intel

[Anonymous Coward]

You know, a really well-crafted backdoor will look exactly like this. When they are found out they can still say "Oops! My bad" then.

Re: Dear Intel

[mikael]

This is what all backdoors look like. "Ooops, we accidently encrypt and decrypt the password and write it out at the end of the file". "Whoops, we missed out a break statement in the selection of the encryption algorithm, it always defaults to the legacy easily broken encryption method". "Oh, shooot, we forget to add the menu option to the router to filter out multicasts, anyone can send a SSDP multicast to that address and get a list of hosts returned."

Like Microsoft's Windows OS firewall doesn't allow blocking of Microsoft telemetry servers. Wonder why? What could be so harmful in blocking a data stream of a few hundred bytes/second?

Re: Dear Intel

[phantomfive]

However, if you aren't going to buy anything that has had a remote code exec vuln, you should probably consider using pen and paper, exclusively!

Uh, a computer with no OS installed should never have a vulnerability. Ever.
It's not a hard thing to do, there are plenty of models that have succeeded, even from crappy companies like Compaq.

If you're going to release something that allows hackers to have ultimate, undetectable control over the computer, you better give it a security audit. All indications are that Intel does not have proper security processes for their systems. This is just one example.

Re: Dear Intel

[Anonymous Coward]

"...you should probably consider using pen and paper, exclusively!"
One of the old Tropes in Adventure Stories is that of using Invisible Ink, usually Lemon Juice. Yet once the word got around that holding the paper above a candle flame caused the lettering to appear, the fad died out... if it ever was real...
Maybe it will make a comeback. LED Lamps won't reveal the Invisible Ink. You need a Flame.
What is Old is New again.

Re: Dear Intel

[Wootery]

This is what all backdoors look like.

And perfectly executed assassinations look like accidents, but it's still more likely that grandpa just had a heart-attack.

The point -- as to whether it's likely -- stands.

Ars story highest voted comment

[Anonymous Coward]

(What? I get that security is hard and that sometimes there are unforeseen vulnerabilities. But... you can enter any text as the password, and it accepts it? Did no one at Intel test a wrong password at any point? This isn't a bug, this is outright negligence.)

 

The article is a bit confusing regarding this, but no, you can't send an empty password. That's because when a browser does digest authentication it doesn't actually send the password, or even a password hash, to the web server.
 

The browser sends instead a response MD5 hash computed on a string composed of various items, including a variable nonce sent by the server, in addition to the password, for example:
 

response=MD5(MD5(username:realm:password):nonce:MD5(method:digestURI))
https://en.wikipedia.org/wiki/Digest_ac ... entication
 

This means a normal browser would never send an empty response, even when you enter an empty password. It would always send a 32 hex digit MD5 hash looking like this:
 

response="6629fae49393a05397450978507c4ef1"
 

The server would then compute the same hash, and compare them. If they are equal, it allows login, if they are different it denies login.
 

The bug was in the code to compare the two strings. It used the strncmp function that compares the first N characters of two strings:
 

strncmp(string1, string2, N)
http://www.cplusplus.com/reference/cstring/strncmp/
 

And applied it to the computed hash and the hash response received from the browser, with N set to the length of the response received from the browser, so something like:
 

strncmp(computed_hash, response, strlen(response))
 

So when it compared a real hash generated by a browser it would do something like:
 

strncmp("6629fae49393a05397450978507c4ef1","d3d4914a43454b159a3fa6f5a91d801d", 32)
 

This would work just fine for hashes sent by the browser, which are always 32 characters in length. Even if the password field is empty, it would compare the two strings, they wouldn't match, and it would reject the empty password or invalid password.
 

So anyone testing this from a browser would find it works perfectly.
 

The problem is what happens if you don't use a browser, but you generate an invalid request manually or using a proxy to alter the response, sending an empty string instead of the 32 character hash. Then the compare code does this:
 

strncmp("6629fae49393a05397450978507c4ef1","",0)
 

This means the function will compare the first 0 characters between the two strings. So it is equivalent to:
 

strncmp("","",0)
 

Of course, two 0 length strings are equal, so it wrongfully concludes the hashes are equal.
 

What the programmer should have done is check if the hash coming from the browser has the correct length, 32 characters, before attempting to compare the two strings.
 

Or even better, the programmer should have used the proper string comparing function, strcmp, that already does that for you and you don't need to supply a length parameter, like this:
 

strcmp(string1, string2)
http://www.cplusplus.com/reference/cstring/strcmp/

Re:Ars story highest voted comment

[Anonymous Coward]

Not only that, but using those kind of string comparisons also opens the door to timing attacks.

Re:Ars story highest voted comment

[Ungrounded Lightning]

The bug was in the code to compare the two strings. It used the strncmp function that compares the first N characters of two strings:

strncmp(string1, string2, N)

And applied it to the computed hash and the hash response received from the browser, with N set to the length of the response received from the browser, so something like:

strncmp(computed_hash, response, strlen(response)) ...

What the programmer should have done is check if the hash coming from the browser has the correct length, 32 characters, before attempting to compare the two strings.

Or even better, the programmer should have used the proper string comparing function, strcmp, that already does that for you and you don't need to supply a length parameter, like this:

strcmp(string1, string2)

That's indeed the correct solution.

But he also could have used strncmp() properly. The strn*() routines' N argument is primarily to keep the routines from overrunning buffers (secondarily look at a subset of a string). So N should have been the expected number of characters for the hash:

strncmp(computed_hash, response, 32) // (Or a suitable manifest constant.)

Just taking the string length from the good string, instead of the argument, would work, too:

strncmp(computed_hash, response, strlen(computed_hash))

Or sizeof(the computed_hash buffer) - but for that one you have to watch out that you don't get the size of a pointer. That would also break it by only comparing the first few bytes (which would make it difficult, but not impossible, to exercise).

Re:Ars story highest voted comment

[Anonymous Coward]

strcmp will read out-of-bounds memory if the strings aren't null terminated which is why it's safer to use strncmp or one of the equivalents. This programmer, like most, just didn't know what they were doing. Probably a hardware engineer that thinks he can write software (for some reason they all do and we end up with shit like this and AMD drivers/software).

Re:Ars story highest voted comment

[140Mandak262Jamuna]

strcmp() has its own vulnerability. By sending a string without the terminating '\0' you make the strcmp() function read past the buffer. So the right thing to do is switch the arguments around, so that the length is computed from a known valid string, not from the untrustworthy response string.

strncmp(response , computed_hash, strlen(computed_hash)) would be good. Or, hardwired a lower limit to avoid comparing strings less than 32 bytes.

Re:Ars story highest voted comment

[Ungrounded Lightning]

strcmp() has its own vulnerability. By sending a string without the terminating '\0' you make the strcmp() function read past the buffer.

Only if the string you are comparing it to, which was generated locally, is ALSO not null terminated.

Regardless, the right thing to do with strncmp() is to use either the proper number of digits for the hash (which you can also expect to get with strlen(computed_hash)) or the size of the buffer that received the response.

Re:Ars story highest voted comment

[Anonymous Coward]

> strcmp
why would a hash be a string?

Re:Ars story highest voted comment

[mikael]

Visual Studio complains about the use of strcpy, strncmp, and insists on Microsoft's strcpy_s, strncmp_s variants, which seem mostly to insist on an additional maximum length to be specified.

Re: Ars story highest voted comment

[Anonymous Coward]

Because it's sent that way in HTTP.

Re:Ars story highest voted comment

[Eluan]

That is exactly the same bug that allowed the Nintendo Wii to be hacked in 2007. This makes me think about how long this has been abused in the wild.

Re:Ars story highest voted comment

[ooloorie]

What the programmer should have done

You're assuming that this was an accident rather than a backdoor.

Re:Ars story highest voted comment

[Skuld-Chan]

This whole story I think is a bit overblown. We use AMT where I work - recently I went to a client management event called "midwest management summit" - clients being PC/Mac devices.

Anyhow in one of the AMT seminars I was the only one who raised my hand when asked who uses this (there were customers as big as Sprint, and Wells Fargo in the same room).

The other thing - its not totally clear if this affects "Admin Control Mode" or "Small Business Mode" - most enterprises use admin control mode - as far as I know without the private key you're still not getting into the machine.

Because of the first mention that no-one uses this - most of these articles are rather sensationalist and really have no idea what the capabilities are of AMT. Its essentially just a lights out controller - some (quite a few) devices don't even have working KVM support (unless your using intel integrated gfx entirely). At must it will get you whatever the customer see's on the screen (Ars Technica claimed it would get you local admin - which isn't true).

Lastly - all machines come from the factory (assuming you paid the $8 license - otherwise its not included and there's no way to enable it) in "factory mode" - its off, and unless you have LMS installed - its not being turned on anytime soon.

Re:Ars story highest voted comment

[Anonymous Coward]

So it's very similar to the Nintendo Wii's crypto problem.
http://wiibrew.org/wiki/Signin...

Re:Ars story highest voted comment

[enrique556]

I agree ooloorie, this couldn't be an accident.

This bit of code would've been identified as super-important when Intel (or whoever) was writing it, and it's too obvious a bug to have been unintentional. It's made to _look_ like an accident.

To Intel: What's the name of the programmer who made the mistake? What does their other authentication coding look like? Are they a junior developer? Can we scour their github history (if any) and see if they really are that stupid? Who was the project manager for this software, and who was this idiot's supervisor? Who was responsible for reviewing their code?

Intel's customers should consider this malicious until proven otherwise.

Re:Ars story highest voted comment

[dejaniv]

The reason why programmer used strncmp() is probably because static analysis tool complained that strcmp() is insecure. This one and other string functions that do not take the size of the input/output buffer (strcpy(), strstr(), etc.) would trigger that warning because they are considered insecure by most standards. This is because lack of null termination in the strings could cause buffer overrun when these insecure functions are used, leading to arbitrary code execution or data corruption. Having an extra parameter for this doesn't inherently solve the problem but at least it makes programmer thing about security implications.

What the programmer had to do as one of the steps in writing secure server code was sanitizing the input. Any information coming from client that is used in the server's code must be checked for validity before use. Failing to do so is also something that can be caught by static code analysis. At very least I would expect code like this to had been reviewed by security experts at Intel before shipping.

Re:Ars story highest voted comment

[paazin]

if the hash is constructed using a nonce and each subsequent request uses a new nonce, the timing attack wouldn't get much useful

Re:Ars story highest voted comment

[Anonymous Coward]

It's a header. The web server sets the null terminator, not the client.

Re:Ars story highest voted comment

[Anonymous Coward]

Intel's customers should consider this malicious until proven otherwise.

Disagree. This bug is too likely to be found by chance sooner or later to have been inserted at the request of . Something a bit more subtle (e.g. a 'special' hash value/length combination) which could not be generated by the browser function and was almost impossible to ever be discovered by chance would be much more useful to .

Re:Ars story highest voted comment

[Raenex]

I agree ooloorie, this couldn't be an accident.

This bit of code would've been identified as super-important when Intel (or whoever) was writing it, and it's too obvious a bug to have been unintentional. It's made to _look_ like an accident.

*snort* Shit like this happens all the time, in companies big and small. There's no guardian angel sitting over people's shoulders making sure code is identified as "super-important" and knowledgeable about all the ways C can fuck you over.

If you wanted to put a back door in, making it so trivial to activate would be just as incompetent.

Re: Free tool "openSORES" too to disable AMT

[Anonymous Coward]

Downloading a random binary file and executing it seems like a good idea. Fucking idiots...

Responsibility for such flaws

[NuclearCat]

When companies will bear responsibility for flaws in such features, as AMT encrypted and obfuscated from 3rd party analysis and management, and enabled by default, and for such screw ups they will pay hefty fines, they will think twice, before making features work such way.

Re:Responsibility for such flaws

[GrumpySteen]

You say that as if there's any chance in hell of companies taking any real responsibility for shitty products. Fines are viewed as a cost of doing business and profit margins are adjusted accordingly. If the company doesn't get caught, it just means their profits are higher than expected due to the cost savings.

It's time to hold engineers liable

[Anonymous Coward]

It is time to finally star holding engineers criminally and civilly liable, in addition to their employers, for these obviously reckless, negligent, and possibly even intentional "features."

When it's YOUR ASS that is going to get strung up, you'll pay a lot closer attention to what the fuck you're doing.

Re:It's time to hold engineers liable

[Ungrounded Lightning]

It is time to finally star holding engineers criminally and civilly liable, ...

Force them to chose between risking jail for a bug or being fired for not following the Pointy Haired Boss' instructions to skip the tetsting and get the damn thing delivered?

What a great idea. Put most of the engineers who would actually do what you want out of work and leave the field to those to dumb to notice or too psychopathic to care.

Re:It's time to hold engineers liable

[sjames]

The employers aren't currently held responsible either.

The problem is that the developers have no power over management to make them do the right thing. Unless and until they do, it isn't reasonable to hold them responsible. They can't make their employer do QA tests, they can't make the employer push the schedule back, and they can't prevent the premature release of a product.

Re:It's time to hold engineers liable

[Anonymous Coward]

This is how civil works. You think a certified civil engineer will design a faulty bridge because his boss tells him to?

Re:It's time to hold engineers liable

[Anonymous Coward]

If only they were engineers...

Re:It's time to hold engineers liable

[upuv]

Programmers are not considered "professionals" by standard bodies. They do not have the power or responsibility to reject or overrule management. If management wants to cut corners, reduce testing, end run around process etc. Then there is basically nothing they can do about it other than quit.

To make programmers liable would result in a massive change in the industry. With the most noticeable impact being a dramatic increase in TTM and a massive blowout in costs. The industrial lobby would never allow this to happen. Nations that do not subscribe to these responsibility requirements will almost instantly become the new IT super shops.

By making the company and not the developer liable you enable countries to actually have an IT industry.

Civil engineering must occur in each nation. Software development does not. This simple fact makes liability very difficult to implement. Second reason is the calculation of damages. With civil engineering the cost of a problem is relatively easy to calculate. In IT systems where most companies hide the impact of a fault the ability to calculate impact cost is near impossible. Thus to compare civil eng with software dev is not a good comparison.

Re:It's time to hold engineers liable

[LordWabbit2]

Agreed, it's pointless blaming the developers when they are not the ones calling the shots. I have worked at a couple companies where the deadline for release was set in stone, regardless of ANYTHING else. The project went live and our currency ended up taking a bit of a dip because of the fvck up it caused on the stock exchange (and no, I was not part of THAT project thank god!). Also programming is NOT the same as engineering. Most engineering projects are planned WAY WAY better than 99.999% if I.T. projects, which makes it easier to hit the dead line etc. Now I am not an engineer (well, I was studying for it many moons ago, but I got sidetracked into software) so I may stand corrected, but I am pretty sure most engineering tasks don't hit a snag and grind progress down to a crawl. Look I am sure there are exceptions, but I have encountered weird ass bugs that take forever to hunt down, that was not part of the original project plan!

Re:It's time to hold engineers liable

[sjames]

Perhaps more to the point, employers aren't willing to pay for the planning stage. It's even worse for contract programming where they want a time table and a firm price before they've even hired you. There's no way that what should be 50 to 90 percent of the total project is going to be done for free up front and not get corners cut. If you add in enough fudge factor to get the planning in after signing, someone will inevitably undercut your bid and do a crap job of planning.

We've known for years that AMT was a risk

[Anonymous Coward]

see e.g. https://hardware.slashdot.org/story/15/01/29/2241214/fsf-endorsed-libreboot-x200-laptop-comes-with-intels-amt-removed

Moneyquote:

"The ME and its extension, AMT, are serious security issues on modern Intel hardware and one of the main obstacles preventing most Intel based systems from being liberated by users."

But hey, the FSF and Stallman are just overreacting hippies right? RIGHT?

Re:We've known for years that AMT was a risk

[Anonymous Coward]

Why can't both things be true?

Re:We've known for years that AMT was a risk

[Tough Love]

Why can't both things be true?

Because one of them is nonsense promulgated mainly by special snowflakes with vested interests.

Re:We've known for years that AMT was a risk

[Anonymous Coward]

Why can't both things be true?

Because one of them is nonsense promulgated mainly by special snowflakes with vested interests.

Yes. So far as I can determine, most of the flak and hatred directed at FSF/RMS comes from the huge crowd who just want to say "oooh so SHINY!" RMS is asking them to actually *think things through* - you know, like adult responsibilities, not like children at Christmas - and actually doing that "spoils" their shiny.

Computing is harmed by large numbers of users who want a general-purpose machine to be an appliance because they can't understand that these two things are not really compatible. They are easy to identify. They're the users who can use the same kind of systems for years and years, yet never develop any skill or knowledge beyond the bare minimum necessary to complete a specific task (not even accidentally picking up new information - that really takes work heh). They're the ones who won't even try to Google a question, not even when it's easy to find and the answer is dead simple.

In general they resent the idea that they should ever, under any circumstances, invest the slightest bit of effort towards their own experience. The very suggestion pisses them off, even when it really is both the easiest and simplest solution. They say things like "I am not a computer expert!" when nothing even approaching expertise is needed, only basic literacy.

They're helpless (not just with computing) and they like being that way. They don't want to taste solid food because they like the attention of having "Mama" spoon-feed them. The vested interests you mention encourage this through marketing that focuses on "ease of use" over robustness. Dumb consumers are an ideal audience for them -- marketing and PR work most effectively on an uninformed audience that cannot think critically.

So to tell them that their special shiny not only has serious flaws, but that these flaws were easily predictable years before they were ever implemented, well they don't perceive that as useful information that assists in good decision-making. No, they perceive that as a bucket of ice-water dumped on their heads. They react to inconvenient facts the way all small-minded people do: by getting upset. This mentality resists correction and your best bet is to minimize interaction with such people.

And people wonder why . . .

[Anonymous Coward]

Russian and Chinese government agencies have been passively or actively promoting the development of a domestic semiconductor industry.

Disable

[itamihn]

Any way to disable this in Linux?

Re:Disable

[Carewolf]

Any way to disable this in Linux?

No it exists above the normal operation of the computer, it is basically a separate secret computer inside your computer to remotely control and monitor you, and will run even when the computer is turned off (same sub-system as wake-on-lan). You need to disable it in the BIOS.

Re:Disable

[Anonymous Coward]

I even wonder how to detect it in Linux. The detection guide in the PDF had "Windows" as a requirement.

Re:Disable

[mikael]

http://web.archive.org/web/201...

Re: Disable

[Anonymous Coward]

My Intel motherboard has it on a separate Ethernet port so you could just not use it. No vulnerability test for Linux and no fix from the manufacturer available yet.

Re: Predictable outcome (only in windows?)

[Anonymous Coward]

Does this only give control of hardware aflicted by windows?

Thanks for the comment.

[Futurepower(R)]

Interesting info, APK.

Re: Predictable outcome (only in windows?)

[Anonymous Coward]

Does this only give control of hardware aflicted by windows?

No, Intel AMT runs completely independently of the operating system. It doesn't matter whether the operating system is Windows, Linux, BSD, or anything else.

Please support open hardware

[Anonymous Coward]

It's desperately important that open hardware platforms get developed and made available -- alternative CPU architectures, hardware, and boot firmware are the only possible defense against the Intel monoculture completely screwing us like this. Security holes/backdoors are only one problem of many. There are a lot of powerful, monied interests who would prefer you not to have any control over your own hardware, and they will continue to take any opportunity to tighten the screws in that direction.

Yes, this means you will have to pay more for less performance (at first anyway), and no, you won't be able to run Windows. But if we don't make this long-term investment general purpose computing is dead.

Re:Please support open hardware

[unixisc]

How is the RISC-V platform in performance? Aside from the potential option of tossing 16 cores into a CPU? That, or the OpenRISC CPU - either of them should be able to satisfy one's requirement. Port FreeBSD onto that, and one has a solution

Q chipset boards

[valnar]

I have a Q170 chipset board at home and it's supposedly vulnerable, but I like having the ability to remotely control my PC (Server) from bootup to bios to Windows. If it's on a home network behind a firewall, this shouldn't matter.

Re:Q chipset boards

[Khyber]

As if firewalls are bulletproof.

Re:Q chipset boards

[Anonymous Coward]

Like firewalls with Q170 chipset boards :)

Re:Q chipset boards

[Lehk228]

unless the firewall is running on an intel chip too, then you are pretty fucked.

Thanks but there's BIOS stuff too... apk

[Anonymous Coward]

See subject: I omit BIOS settings you have to check too (but I did it ages ago here). Thought I'd note drivers/services removed results here too showing it's basically enough to do it manually yourself!

(I asked a while back to the guy that trumpets this here IF that'd be enough between service stoppage, drivers yanked for AMT/Intel Mgt. Engine & BIOS - he never answered so I tested it)

Results?

Per BOTH checking tools (OpenSORES one & Intel one)??

Once I disabled Windows service involved AND removed the device driver in Management Console's DEVICE mgr.???

* BOTH said I was 'clean' of it (I never had it installed but EVERY ONCE IN AWHILE? I'll install stuff like this just to test the removal tools...)

APK

P.S.=> Again, it was odd (since remnants of Intel mgt. remains on disk) BOTH tools said I was 'clean' (remnants were on disk still) - so I literally had to INSTALL IT AGAIN, run Intel's UNINSTALL, & then test w/ the tools again (knowing I could manually remove a .sys driver file or .dll's for its services etc.) . Apparently both tools TARGET THE "ACTIVE INGREDIENTS" in the service & drivers involved, & that's what I did manually anyhow... apk

Re: Thanks but there's BIOS stuff too... apk

[Anonymous Coward]

Don't worry Mr. Kowalski. One of these days, someone somewhere will think you are useful/funny/clever. Then you'll have a weak imitation of the sense of worth that you clearly are unable to find within yourself.

Re: Predictable outcome (only in windows?)

[Anonymous Coward]

No, Intel AMT runs completely independently of the operating system. It doesn't matter whether the operating system is Windows, Linux, BSD, or anything else.

In fact, it's even worse. Intel AMT can still be running while the computer is off (but still plugged in). See

https://fsf.org/blogs/community/active-management-technology

Let me say it again: your computer can be pwned while it's off! You don't need to have anything running at all, because Intel AMT keeps running in the background as long as the machine is plugged in.

Re: Predictable outcome (only in windows?)

[Anonymous Coward]

Why, then, is the detection tool only for Windows?

Remind me again why I should buy Intel?

[Anonymous Coward]

If they hadn't added this stupid feature to begin with, we wouldn't be dealing with this problem.

Yes, AMD's doing it as well, and I'm not buying their bugged CPUs, either. It'll be some time before my Phenom 2x6 is flat-out obsolete.

Re:Free tool "openSORES" too to disable AMT

[byornski]

I think you miss the point. It runs at the most basic hardware level, if it's enabled and supported by your motherboard. Having to install extra software to enable it suggests your motherboard does not directly support it, so this test is meaningless. It does not require additional software to work....

Whoopsie? No way

[JustAnotherOldGuy]

" AMT makes it possible to log into a computer and exercise the same control enjoyed by administrators with physical access [and] was set up to require a password before it could be remotely accessed over a Web browser interface. But, remarkably, that authentication mechanism can be bypassed by entering any text string -- or no text at all..."

I find it hard, very very hard, to believe that this was an accident or just the result of stupid coding. This was either deliberate or was some carefully planned subversion somewhere along the tool chain.

Re:Whoopsie? No way

[gweihir]

I understand the sentiment, but I disagree. This is far too easy to find for that. It is very surprising it took so long. The right way to do backdoors is to make _subtle_ errors that cannot easily be found without special knowledge. That way, they stay useful for a long, long time. No, this is likely just extreme incompetence.

Re:Whoopsie? No way

[Anonymous Coward]

I understand the sentiment, but I disagree. This is far too easy to find for that. It is very surprising it took so long. The right way to do backdoors is to make _subtle_ errors that cannot easily be found without special knowledge. That way, they stay useful for a long, long time. No, this is likely just extreme incompetence.

Actually a comprehensive backdooring program would involve both. This achieves at least two goals. One, by the very reasoning you are using, it looks more innocent. After all, writing bug-free code is notoriously difficult if not impossible. Bugs happen all the time, including bugs that look relatively obvious in hindsight. Two, it may promote a false sense of security because people who patch more obvious-looking bugs like this might then stop there, overlooking much more subtle backdoors while believing they have secured their systems.

Incidentally, looking at the Underhanded C Contest is just astonishing. Many of the entries look like *completely* innocent mistakes, the kind of mistakes even seasoned programmers can and do make. Consider that most entrants are individuals or small private organizations. Then consider what a state actor with vast resources, immense funding, legal sovereign immunity, NSLs and gag orders, and cushy relationships with major manufacturers could do...

Re:Whoopsie? No way

[JustAnotherOldGuy]

I understand the sentiment, but I disagree. This is far too easy to find for that. It is very surprising it took so long. The right way to do backdoors is to make _subtle_ errors that cannot easily be found without special knowledge.

And maybe there's one of those present too, but for now everyone is congratulating themselves on finding this one without realizing there's another one that hidden better.

-

That way, they stay useful for a long, long time. No, this is likely just extreme incompetence.

You may be right, but I'm skeptical in the extreme.

Re:Whoopsie? No way

[Anonymous Coward]

If the world's IT expertise couldn't find this in seven years, then they won't find anything else in plain site. Fugget about it.

Re:Whoopsie? No way

[gweihir]

Well, possibly. I think it would have been better to keep attention away from the whole thing, but it could have been some kind of "detector". I still think that is too complicated and one thing competent TLAs understand is KISS. Of course, US intelligence skill has been going down the drain, and maybe they did this as you describe. Would still be incompetence, just somewhere else.

It is a shame we will likely never find out.

AMT sounds really useful

[ooloorie]

In case you were wondering, AMT allows you to access the screen, keyboard, and mouse of your machine through VNC as if you had a network KVM on that machine. It seems to use the VNC protocol even. Network KVMs are expensive specialty items, and something like AMT is a cleaner, simpler way of accomplishing the same thing.

It's a shame Intel messed up and gave this feature a bad name. I hope they'll fix the problems and/or other motherboard makers will come out with a safer and improved version of it.

Does not get much more incompetent than this

[gweihir]

Now one wonders what great "security features" Intel has places in their network cards, chipsets and CPUs. This really is on the most stupid level possible. They cannot even have done an internal review of this code that deserves the name before putting it into production.

Re:Does not get much more incompetent than this

[AmiMoJo]

I've got an Intel motherboard that is vulnerable. I contacted their support and they gave a date of 12/05/2017 for information on what fixes they are going to offer.

Intel don't make motherboards any more. Mine is a legacy, unsupported product now. They better fucking fix it anyway.

Happens...

[SharpFang]

One of our devices comes with control port open; you can enter commands and they will be executed according to your privileges. Besides "login" very few commands should work for the default user... except external software interacting with the device still doesn't support logging in, so the default privileges are set to maximum. You can still log in... to lower your privileges.

Incorrect & "you're late to the game..."

[Anonymous Coward]

See subject & I think YOU missed the part where I already covered it here an hour before you posted https://hardware.slashdot.org/comments.pl?sid=10581229&cid=54373155/ like VPro etc. (it's in my bios off).

* Hence WHY the Intel Mgt. Engine ware (& much more by Intel) came w/ my mobo on a CD...

APK

P.S.=> "Onwards & UPWARDS"... apk

Re:Incorrect & "you're late to the game..."

[byornski]

You've clearly got some hackneyed version of it as it runs without drivers on supporting hardware. Sounds like you've got some sort of winmodem-style version of this. Read the summary...

Re: Predictable outcome (only in windows?)

[Anonymous Coward]

Try reading the summary, you helpless imbecile.

C langage guilty again.

[aberglas]

Indeed.

This is yet another security bug produced directly by the archaic C programming language. If this had been any other language the bug wold not have happened, despite the incompetent programmer. Null terminated strings! Wild pointer usage!

C is evil.

Re:C langage guilty again.

[Anonymous Coward]

My deck turned crooked and lousy. It's all the fault of that damn hammer and screwdriver!!

Re:C langage guilty again.

[Tranzistors]

Well, yes. Apparently the job required wrench and rivet fastener.

Lack of negative testing - extremely common

[raymorris]

This much more common mistake than one might think. A *lot* of applications will accept an empty password. It's one of the more common of the 90,000 or so vulnerabilities that we test for.

Programmers get so focused on making things work, 95% of the testing they do is geared toward that, toward doing whatever is supposed be used for, given correct input. They forget to test the negative - what does it do with incorrect input? If a program retrieves a web page, what if it's empty? What does a searching or sorting program do when asked to aort or search an empty list, or a list of just one item? That stuff doesn't get tested much.

Re:Lack of negative testing - extremely common

[phantomfive]

Programmers get so focused on making things work, 95% of the testing they do is geared toward that, toward doing whatever is supposed be used for, given correct input. They forget to test the negative

How would you solve that problem?

Re:Lack of negative testing - extremely common

[Anonymous Coward]

IMHO when the cost of not testing > cost of testing.

Right now, as things stand, getting compromised costs very little when compared to the cost of properly testing. The cost is going up, thankfully, albeit slowly.
 

Re:Lack of negative testing - extremely common

[parkinglot777]

White list instead of black list approach? Often times, programmers use black list approach which is cheaper and will not be adequate to test negative (no way to know all cases). If they do white list approach, it automatically rejects negative cases. Of course, the rejection (exception) handler must be included.

Re:Lack of negative testing - extremely common

[phantomfive]

I'm not sure how to apply that to this situation.......

Re:Lack of negative testing - extremely common

[parkinglot777]

I'm not sure how to apply that to this situation.......

Sometimes, white list approach looks similar to black list approach. However, in white list, you apply/check for known conditions. One solution, as others have stated, is to use the length of known string (calculate_hash) instead of user input (response). But this would give a reverse situation (could be a bug) -- will accept and pass anything (response is empty or not) if the calculate_hash is empty by itself. Another way for this situation is to validate the input -- not null or empty -- before calling strncmp() with similar arguments because you expect that the input (password) will always contain something -- white list.

The programmer who did this (if with naive intention) does not fully understand the function and may expect that strncmp() to verify the inputs for him/her.

Re:Lack of negative testing - extremely common

[phantomfive]

The programmer who did this (if with naive intention) does not fully understand the function and may expect that strncmp() to verify the inputs for him/her.

Yeah, not understanding the APIs you call is a serious cause of security flaws.

Re:Lack of negative testing - extremely common

[fox171171]

Programmers get so focused on making things work

Except for DRM programmers, who get so focused on making things not work.

Re:Lack of negative testing - extremely common

[coolsnowmen]

One of the many reasons people have gone to TDD ( https://en.wikipedia.org/wiki/... )

strncpy is broken, period.

[aberglas]

strncpy is just broken. Period.

It should complain if there is no null termination in the first string. The code should work, it just does not work around the bug in strncpy.

Very much like strncpy not adding a null if it is N long.

Lots of C grade rubbish that we still live with.

Re:strncpy is broken, period.

[chihowa]

The code shouldn't always work because it depends on receiving a valid response from the untrustworthy browser.

Using strlen(response), when the contents of response are outside of your control and you know that the correct length is strlen(computed_hash), is ridiculously sloppy for anybody, best especially somebody writing a security system.

Re:strncpy is broken, period.

[fisted]

strncpy is just broken. Period.

Sorry, but you're full of shit.

It should complain if there is no null termination in the first string.

And how, pray tell, do you imagine it to be able to do that?

Very much like strncpy not adding a null if it is N long.

You don't understand what strncpy is meant for, but I suppose it's par for the course. Hint: strncpy is not supposed to be a "safe" variant of strcpy.

Lots of C grade rubbish that we still live with.

Yeah. And those programmers...they're even worse.

Re:strncpy is broken, period.

[Anonymous Coward]

Sorry, but this is programmer idiocy not the fault of the language. The correct function to use is memcmp(). Which will catch this problem. strncmp() relies on the c-string being NULL terminated, and as such is a KNOWN AND DOCUMENTED BEHAVIOR. Anyone using strncmp() in security code needs to be removed from the keyboard before they hurt themselves. (Or indeed others, right Nintendo?)

Re:strncpy is broken, period.

[Raenex]

Sorry, but this is programmer idiocy not the fault of the language.

The problem is the language. It's very low-level and full of easy to make errors. In any reasonably sane language that doesn't treat every CPU cycle as precious shit like this does not happen.

KNOWN AND DOCUMENTED BEHAVIOR

That C's error-prone functions have been documented and can be used correctly given enough care and experience doesn't excuse the language or prevent these kinds of errors from happening in the real world. Yes, in your mythical world where only perfect and experienced C programmers write code this isn't a problem.

Re:strncpy is broken, period.

[Anonymous Coward]

strncpy is NOT a safe version of strcpy. It is a mess.

If the string is >n chars, no null terminator is appended. So, unless the programmer manually adds the null, it breaks the next time the string is used.

Re:strncpy is broken, period.

[fisted]

strncpy is not supposed to be a "safe" variant of strcpy.

strncpy is NOT a safe version of strcpy.

Yawn. Practice your reading comprehension.

Why'd Intel Mgt. Engine come w/ my mobo?

[Anonymous Coward]

Why would Intel Mgt. Engine come w/ my mobo then in both hardware and on CD for its software? Please... lol!

APK

P.S.=> I also merely pointed out that the test tools (1 from Intel per this article & the other being "openSORES") produced the results they did when I tested after installing the Intel mgt. engine ware... apk

Re:Why'd Intel Mgt. Engine come w/ my mobo?

[byornski]

For the more complicated functions that it can perform. But see this.

Traffic on ports 16992-16995 are directly intercepted by Intel AMT within the chipset before being passed to the host operating system... once Intel AMT is in a configured and accessible state.

and

Intel AMT enables reliable power control of the platform, booting for a network based ISO image, integration Keyboard-Video-Mouse (KVM), and more.

So a remote exploit could just consist of power cycling to boot from a external boot image. Only OS requests are sent to the OS, everything else is supposed to be caught at the hardware level.

Re:Why'd Intel Mgt. Engine come w/ my mobo?

[Anonymous Coward]

You need the drivers to control and monitor it locally once the OS has booted. If you don't install the drivers, then you can only detect whether it is enabled remotely and generally you can enable and disable it from the UEFI screens before booting an OS.

Here's the FUNNY part (LOL @ U w/ proof)

[Anonymous Coward]

I'm going to continue using the Host File Engine. Your software is well written, functional. The Host File Engine performs exactly as promised by mmell

his hosts program is actually pretty good by xenotransplant

his hosts tool is actually useful for those cases in which one does indeed want to locally block stuff outright while consuming minimum system resources by alexgieg

I've never tried to belittle (APK's) work, I've flat out said it's good by BronsCon

take a look at the APK hosts file engine by SuperKendall

APK is kinda right. I've tried his hosts file generating software. It works by bmo

I like your host file system by Karmashock

I find your hosts file admirable by vel-ex-tech

* My code's liked + recommended & hosted by Malwarebytes' hpHosts!

APK

P.S.=> Slashdotters find me useful/clever & getting the LAST LAUGH @ you UNIDENTIFIABLE anonymous troll? See subject... apk

Re:Here's the FUNNY part (LOL @ U w/ proof)

[BronsCon]

I've never tried to belittle (APK's) work, I've flat out said it's good by BronsCon

Context matters. If I recall correctly, I go on to point out that no matter how good your work may or may not be, your toxic personality makes everything you touch toxic as well. Sort of like a serial killer chef who makes the most wonderful of soufflé... which just so happens to be lethal within an hour of consumption.

Re:Here's the FUNNY part (LOL @ U w/ proof)

[Anonymous Coward]

UNIDENTIFIABLE anonymous troll

Hmm... Nope that doesn't remind me of anyone.

take a look at the APK hosts file engine by SuperKendall

Wow! What a glowing review.

Re:Here's the FUNNY part (LOL @ U w/ proof)

[Anonymous Coward]

UNIDENTIFIABLE anonymous troll is you.

Re:Here's the FUNNY part (LOL @ U w/ proof)

[Anonymous Coward]

Look it is the same tired troupe of quotes you have been trotting out for years. Find some new ones dick bag or is it that you can't because everyone now realizes your software is an overly complicated pile of shit. It doesn't need to be multi threaded, it doesn't need to be an executable, it is something anyone with a basic understanding of shell scripting could whip up quickly. Many have done so, and many have even done so long before you did. Also you don't actually do the hard work your junk software just aggregates the real work of others.

Re: Predictable outcome (only in windows?)

[Anonymous Coward]

Ouch... yeah, that guys got a security vulnerability.

Active xxx

[Tough Love]

Active Management Technology... it sounds so much like ActiveX, and equally porous it would seem.

I block those ranges in my firewalls... apk

[Anonymous Coward]

See subject: BOTH @ OS software & router hardware level firewalls - "ain't happenin'" w/ that & BIOS stuff = off off as I noted I did LONG ago.

* I only let 80, 8080 & 443 in here, nothing else...

APK

P.S.=> It can't GET to my system based solely on what YOU SAY NOW in fact - it'd have to compromise my firewall (especially router) too... apk

Re: I block those ranges in my firewalls... apk

[byornski]

If you blocked them internally, your LAN was never vulnerable so I'm not quite sure what your point was. This is mainly aimed at the (relatively) small set of servers that may have these features in hardware and enabled, not home users. All you've showed was that you managed to enable a software based version of the vulnerability and then disable it in software.

Re: I block those ranges in my firewalls... apk

[Anonymous Coward]

APK is just too dumb to actually understand computer security. He will argue like a penchant child until others stop replying and then claim victory.

I also hear he blows dead goats.

Stallman was Right

[BoRegardless]

We succumb to the overlords when we use proprietary software!

Re:Stallman was Right

[Anonymous Coward]

You're preachin' to the choir.

Re:Stallman was Right

[Anonymous Coward]

Except port 16992 and 16993 are open by default on my new laptop. Its OS is a Linux distro. Linux is not proprietary yet it enables this malicious AMT ports by default. Looks like those kernel were also infected. I think I need to recompile my own.

I don't run a LAN here (don't assume)... apk

[Anonymous Coward]

See subject: Internally & externally? I'm pretty well setup (I 'wrote the book' on it decades ago) https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22HOW+TO+SECURE+Windows+2000%2FXP%22&btnG=Google+Search&gbv=1/ (funniest part is I actually got paid for it too, lol!).

* I serve up nothing. I get access to everything (stand-alone system, FAR easier to secure external@perimeter & internally vs. a LAN/WAN. By far - but, it definitely works vs. threats I never saw coming decades ago but to this day, that setup's pretty prime (newer hardware by far since then all the way around but principle's same & effective).

What I liked best using PARTS of it on a LAN/WAN? I was invisible (even to admins, whole system) but I got access to everything... It's that good.

APK

P.S.=> Put it THIS way, lol - let's see: I've got UNSTOPPABLE to my credit (ask Whipslash, lol) & now INVULNERABLE - what's next? INVINCIBLE too?? It's look that way so far, lmao... apk

Re: I don't run a LAN here (don't assume)... apk

[byornski]

Perhaps I wasn't clear. I mean internal port blocking at a switch level. Hardening windows will do nothing against the exploit proper. Blocking these ports at a hardware level is a mitagation until the firmware is patched.

Re:I don't run a LAN here (don't assume)... apk

[Anonymous Coward]

You're right that is pretty funny that someone was foolish enough to pay you for anything given that your work is trivially replicated by a middle school drop out who found a copy of VB6 For Drunken Lower Primates.

Discovery tool only Windows

[OFnow]

The Discovery Tool from Intel is a Windows executable. So how about the rest of us, Intel? Are our Intel CPUs vulnerable?

Re:Discovery tool only Windows

[Anonymous Coward]

The discovery tool is there to add few more exploits into OS itself just in case the AMT feature will be fixed. Intel does not make these backdoors for fun, the NSA and Mossad will pay them a good money.

Re:Discovery tool only Windows

[Carewolf]

The Discovery Tool from Intel is a Windows executable. So how about the rest of us, Intel? Are our Intel CPUs vulnerable?

Only if you have a machine specifically made to be a workstation. Unless it is at work, you probably only have one if you have ThinkPad, Macbook Pro or another high-end business or workstation laptop.

"A look @ the future & the future IS now..."

[Anonymous Coward]

See subject: Being proofed vs. this for decades++ now & how? Well - you know https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22HOW+TO+SECURE+Windows+2000%2FXP%22&btnG=Google+Search&gbv=1/ Hardening your entire setup = does everything (long before it happens - this thing just "can't touch this" due to that setup that way for decades++ now).

* It stops this thing cold (& I did decades ago, lol, setup that very way as I said) before it was a twinkle in the eyes of its creators INTEL.

APK

P.S.=> Enjoy the read - My setup is a "Look @ the future & the future IS now..." decades++ later... apk

Re: "A look @ the future & the future IS now..

[byornski]

Yes, secure for decades by the virtue that the processor predates the features(2008ish).

No

[Anonymous Coward]

It wasn't worse than what we thought. What were you smoking Intel?

Yea but my work's good... apk

[Anonymous Coward]

Results, matter: Now, who do YOU know who said this (you know who, lol)

"I've never tried to belittle (APK's) work, I've flat out said it's good" - by BronsCon (927697) on Thursday February 11, 2016 @06:48PM (#51491263)

?

* RoTfLmAo... anybody YOU know say that? Hehehehehe... @ least I didn't tell you to EAT YOUR WORDS (or, did I? LOL!)

Results matter - CONCRETE, verifiable & UNDENIABLE results (I've got 'em - I got you with 'em in fact (in many a way)).

APK

P.S.=> I'm not here to win a popularity contest - I'm here to WIN (& I always do - It's how I roll - I mean, HOW can I help it when you guys make it easy to do by you losing? LOL!)... apk

Re:Yea but my work's good... apk

[Anonymous Coward]

Go choke down some elephant cock

We all know you love it

Re:Yea but my work's good... apk

[BronsCon]

Trust also matters and a security "professional" who stabs someone in the back after supposedly reaching an understanding (the way you did me) is not trustrowthy. Neither is their software.

You may be winning in your own mind, but when you do so by violating trust you're destroying your own brand. Security is a trust-based market and nobody trusts you.

Re:Yea but my work's good... apk

[BronsCon]

Why don't we just quote the entire post ? That gives a lot mofe context regarding what lead up to that comment, as well as what followed

Such a "trustworthy" guy you are, no? The thread that comment came from, and what your troll brigade did to my karma immediately following it (which I recovered from in less than a week, mind you, because people seem to actually like having me here for whatever reason), really bear out how much trust you and your software deserve.

Unprovisioning clients

[mcswell]

The Intel-recommended "mitigation" until the patch is released involves "Unprovisioning clients". What the ___ does that mean? They provide software to do it, but what exactly are the effects? (And yes, I did a web search, but it was unenlightening.) There is a wikipedia article here
        https://en.wikipedia.org/wiki/...
on "provisioning", but it talks about seven different kinds of provisioning, and it's not clear which one the Intel doc is talking about. Nor is it clear from reading that article what the effects of UNprovisioning would be. Loss of ability to go on the web? Inability to download antivirus updates? Is it reversible, when the fix from Intel comes out? (and if a computer is "unprovisioned", can you even get the fix from Intel when it comes out?)

Re:Unprovisioning clients

[Lehk228]

it means disconnecting your router from the internet

Re:Unprovisioning clients

[mcswell]

Really? I could do that by unplugging the cable...

Re:Unprovisioning clients

[michael_wojcik]

Essentially it means AMT will be disabled. "Provisioning" means "making AMT available for use"; unprovisioning is the the opposite.

If the Intel tool[1] shows your system is provisioned, go ahead and unprovision it. Regardless of what you might be using AMT for in your organization, it's not worth the risk.

The Intel tools[2] include some documentation which, while pretty bad, does help clarify some things.

[1] Or some alternative, if you're not running Windows; unfortunately I have no idea what the alternative might be, because Intel's communication in this issue is abysmal. Their tools are crap and their instructions are crap, even for Windows, and if you're running anything else then ha ha fuck you. Really this is an appallingly poor response by a vendor, and Intel deserve every bit of bad press and more.

[2] They can be downloaded from Intel here. Of course that page requires Javascript because it's impossible to provide downloads without Javascript. No, wait, it's because the people in charge of Intel's website are idiots.

Re:Unprovisioning clients

[mcswell]

Thanks for the explanation! Oh, and my computer is a home computer, not any organization's computer that needs to be managed. IMO, this management thing should have come turned off out of the box, preferably with a hardware switch for security. If someone's managing a bunch of computers and needs this capability, they could jolly well go in and turn it on.

Also, I'll go on record as saying Intel ought to hire you to write lucid explanations for them. Thanks again!

Doesn't matter (for me) in the end - how/why?

[Anonymous Coward]

See subject & https://hardware.slashdot.org/comments.pl?sid=10581229&cid=54373735/ via "a look @ the future"...

* :)

(As I said - that'd make some sense as to my results testing these tools per my last post - they were blind in usermode minus monitoring filtering drivers).

APK

P.S.=> Porsche - accept NO substitutes - doesn't matter - I was literally UNTOUCHABLE per that link above to this threat (& others like it before + yet to come due to my setups illustrated in part in the link above)... apk

Computer manufacturers let you disable AMT

[ayesnymous]

When I was looking at buying a Dell or HP laptop a couple years ago, they both gave me the choice of disabling vPro. AMT is a subset of vPro. So you could disable it if you wanted. Not sure why anyone would choose to have it enabled. And from what I've read, if you have them disable vPro at the factory, it's not possible to enable it later.

LEARN TO READ please... apk

[Anonymous Coward]

Pertinent excerpt of my words per my post to you "newer hardware by far since then" from https://hardware.slashdot.org/comments.pl?sid=10581229&cid=54373899/

* My firewall setup ALONE cuts this threat off easily (per my security guide that STANDS STRONG to this day 10++ yrs. later no less!)

APK

P.S.=> "I RULE!!!" ... apk

Re: LEARN TO READ please... apk

[byornski]

Literally avoiding the issue that you weren't vulnerable anyway until you installed some other software. Perhaps you should have blocked the Intel site with some sort of hosts file?

Re: LEARN TO READ please... apk

[Anonymous Coward]

Don't encourage him.

I point out I've always been safe vs. it...

[Anonymous Coward]

See subject: ... & via a layered-security/defense-in-depth security hardened system (correcting you too) https://hardware.slashdot.org/comments.pl?sid=10581229&cid=54374409/ there.

* :)

Imagine that: A security guide I started in 1997's methods STILL protect me to this very day 20++ yrs. later (pats self on back)...

APK

P.S.=> It's NOT easy being "world-class" (like me, lol)... apk

At least 8500 systems exposed you cocksucker

[Anonymous Coward]

Because of the first mention that no-one uses this - most of these articles are rather sensationalist and really have no idea what the capabilities are of AMT.

A query of the Shodan security search engine found over 8,500 systems with the AMT interface exposed to the Internet, with over 2,000 in the United States alone.

Re:At least 8500 systems exposed you cocksucker

[Raenex]

A query of the Shodan security search engine found over 8,500 systems with the AMT interface exposed to the Internet, with over 2,000 in the United States alone.

Given the gazillions of computers on the Internet, that number is extremely small.

You want more? Ok... apk

[Anonymous Coward]

APK is totally right on this count. Adblock Plus on Firefox mobile is a dog on older, or lower end, phones. A hostfile based adblocker makes for a much better experience by chihowa

I support APK's stand on the hosts file by Trax3001BBS

Your premise that hostfiles are a good way to deal with advertising and malvertising is quite valid by JazzLad

No complaints from me, I like APK... Reminds me to use a host file. Also, his stuff is free by aaaaaaargh!

APK's monolithic hosts file is looking pretty good by Culture20

APK... Awesome to see he's still spreading the good word by Molochi

ABP is insufficient as a solid hosts file does everything that APK reminds us about by fast turtle

APK isn't wrong by cfalcon

APK, I know people give you a lot of shit regarding hosts, but please don't ever stop by nasredin

You need APK's hosts file by Teun

APK solution STILL relevant by Thud457

you're right about hosts files by drinkypoo

APK

P.S.=> There's a dozen more than you've got to your name... apk

Re:You want more? Ok... apk

[Anonymous Coward]

Yet APK still can't answer to the horrid technical aspects of his obviously bloated and overly complex code that is easily replicated by anyone with the even most basic level of scripting knowledge.

Furthermore he lacks the ability to do the original difficult work and instead leverages that of others all while believing himself to be a genius.

Let us not forget how he will deride anyone who dares criticize him as hiding behind an anonymous or fake name all the while he will praise anonymous or fake names that happen to mention his questionable work in a damning with light praise fashion.

His unwillingness to post with an actual account should tell everyone how willing he is to stand behind what he is peddling.

Given time he will go on about how his ageing self will kick everyone's asses and will call everyone names while believing himself to be above the fray.

Maybe APK should take some time to reflect on his decisions and contemplate why so many people would go out of their way to mock, troll, and otherwise abuse him and his ideas but alas he will come to the incorrect conclusions that the problem isn't with him.

LMAO

[Anonymous Coward]

yet another reason I am a proud buyer/user of AMD products

Re:Free tool "openSORES" too to disable AMT

[Anonymous Coward]

The only open sores here are the ones in APKs gaping asshole after taking some elephant cock.
By gaping I mean he puts goatse to shame
I implore you seek help for your elephant cock addiction.

When you can manage this then talk

[Anonymous Coward]

See subject: Where even the highly esteemed CIS Tool took fixes to their security ware from me & where I was even unexpectedly paid for these security guides https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22HOW+TO+SECURE+Windows+2000%2FXP%22&btnG=Google+Search&gbv=1/ + the fact I made a ware for security many others like & use including our /. peers as shown here https://hardware.slashdot.org/comments.pl?sid=10581229&cid=54373621/

* You manage to show us YOU have done more, better & earlier than I have? THEN, you can talk!

(All you ARE is off-topic trolling blowhard windbag mere 'talk' though - no action (on your part)).

APK

P.S.=> No small wonder you 'hide' as UNIDENTIFIABLE anonymous troll - you don't have ANYTHING to show for yourself (& you know it) - bit jealous are ya? Yes - of me, lol... apk

Projecting your issues onto me?

[Anonymous Coward]

Projecting your issues onto me? LOL, please - get on topic & grow up!

APK

P.S.=> You have some SERIOUS issues - take your own advice & seek professional psychiatric help (you need it)... apk

Projecting your issues onto me?

[Anonymous Coward]

Projecting your issues onto me? Get on topic & grow up!

APK

P.S.=> You have SERIOUS issues - take your own advice & seek professional psychiatric help (you need it)... apk

I encourage UNIDENTIFIABLE "ne'er-do-wells"...

[Anonymous Coward]

See subject: To do better than https://hardware.slashdot.org/comments.pl?sid=10581229&cid=54373621/ or https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22HOW+TO+SECURE+Windows+2000%2FXP%22&btnG=Google+Search&gbv=1// on my part (a fraction of what I can put out to my credit).

* The latter PROOFS ME vs. this exploit (hardware firewall ranges blocked this threat uses) - you've done more, better & earlier with proof?

I DOUBT IT!

APK

P.S.=> Of course, there IS a reason you have to 'hide' behind FAKE NAMES online for your FAKE LIVES &/or use UNIDENTIFIABLE anonymous trolling - lol, you don't have a THING to your name/credit - now do you? Nope - prove otherwise (good luck)... apk

This may be a dumb question

[Anonymous Coward]

But why in the name of all that's holy was this function in the CPU? Did O read the story wrong?

Good question. Perhaps "not" tests, securit review

[raymorris]

That's a good question. Perhaps, if you managed to create an environment where tests are expected and used in useful way, one could add an expectation to have an equal number of "not" tests, of tests showing what happens when input is not good, that the software does not do things when it shouldn't. That may get developers more into that frame of mind. The famous "goto fail" might have been avoided.

Mature software development includes peer review followed by QA testing. Perhaps mature software development should include security review and security testing. Just as you do peer review, have a security-focused person look over the code and run a test. Not just to catch issues, though it'll do that, but so the feedback helps developers think about those types of issues in the future.

Pre 2013 AMD CPUs

[Anonymous Coward]

AMDs Bulldozer Cores are about to become a lot more valuable on the second hand market.

Wrong: Many trust my work (pros too)

[Anonymous Coward]

I'm going to continue using the Host File Engine. Your software is well written, functional. The Host File Engine performs exactly as promised by mmell

his hosts program is actually pretty good by xenotransplant

his hosts tool is actually useful for those cases in which one does indeed want to locally block stuff outright while consuming minimum system resources by alexgieg

I've never tried to belittle (APK's) work, I've flat out said it's good by BronsCon

take a look at the APK hosts file engine by SuperKendall

APK is kinda right. I've tried his hosts file generating software. It works by bmo

I like your host file system by Karmashock

I find your hosts file admirable by vel-ex-tech

* My code's liked + recommended & hosted by Malwarebytes' hpHosts!

APK

P.S.=> See subject: When you've personally done better tell me "how it works" then - ok? Proof above vs. bs works for me... apk

I trust your words quoted (you said it not I)

[Anonymous Coward]

"I've never tried to belittle (APK's) work, I've flat out said it's good" - by BronsCon (927697) on Thursday February 11, 2016 @06:48PM (#51491263) - works for me & I trust it (as do tons of registered /. users + security pros https://hardware.slashdot.org/comments.pl?sid=10581229&cid=54377473/

* I wonder - do you trust YOURSELF?

APK

P.S.=> You say 1 thing quoted above & now something else, lol... can others trust "shifty" people that don't stick to their guns? apk

Re:I trust your words quoted (you said it not I)

[BronsCon]

You say 1 thing quoted above & now something else

Actually, as supported by evidence (e.g. the post you quoted, which I linked to), the "something else" you're claiming I'm just now saying was said in the very same post you are quoting out of context. That was my entire point.

Reading through that conversation again did remind me of something, though. I shouldn't be speaking with the dead so, good day, sir. Enjoy the afterlife.

Unidentifiable anonymous jealous troll

[Anonymous Coward]

See subject & when you can show us you've done more, better & earlier than https://hardware.slashdot.org/comments.pl?sid=10581229&cid=54377473/ & https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22HOW+TO+SECURE+Windows+2000%2FXP%22&btnG=Google+Search&gbv=1/ then talk!

* LMAO - All you ARE is off topic trolling hotair blowhard windbag 'talk' & nothing more...

APK

P.S.=> Prove otherwise for yourself (I know you can't & so do YOU, lol - all you can do is show us your wasted life + time, trolling others who do well (in myself))... apk

how the fuck

[strstr]

such a complete exploit, it seems more like it was put there deliberately for the government to access...

it makes no sense such exploit could come about by accident.

obamasweapon.com

ALL the "supporting evidence" I need... apk

[Anonymous Coward]

See subject & your words quoted: "(APK's) work, I've flat out said it's good" BronsCon (927697) on Thursday February 11, 2016 @06:48PM (#51491263) - same as registered /. users + security pros https://hardware.slashdot.org/comments.pl?sid=10581229&cid=54377473/

* What more can I say? You said it better than I can!

APK

P.S.=> If I'm 'dead' getting results like those death's a great place - I tell ya - It's NOT easy being "world-class" (like me doing good work others like & use)... apk

Well the catch phrase works..

[Anonymous Coward]

After all, it says "Intel inside", that doesn't imply that they won't prevent anyone else from getting inside.

Show us you've done better!

[Anonymous Coward]

See subject: Show you can get these kinds of reviews from our /. peers https://hardware.slashdot.org/comments.pl?sid=10581229&cid=54373621/ then you can talk.

APK

P.S.=> I keep asking you to show us others saying you do good work - how come you CAN'T, unidentifiable talker? I know why (lol, you're a "ne'er-do-well" full of HOT air blowhard bullshit - which ANY fool can manage - you're proof of that, lmao!)... apk

sprintf, snprintf, strcmp, strncmp, ...

[Anonymous Coward]

But but but we replaced all sprintf, strcmp, etc calls with secure versions - snprintf, strncmp.

"This is the weapon of the Jedi Knight..."

[Anonymous Coward]

See subject & "... not as clumsy or random as a blaster (antivirus/firewalls/local dns/browser addons): An elegant weapon from a more civilized age..." APK Hosts File Engine 9.0++ SR-7 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/

* "For over a 1,000 generations were the Jedi Knights were the guardians of peace & justice in the old republic - before the dark times (see article>... before the EMPIRE"

APK

P.S.=> That's my review & the light saber I constructed pretty much... apk

Re: "A look @ the future & the future IS now.

[Brockmire]

You've wasted your time with apk. He's never had a technical conversation, it's all fucking non-related hosts bullshit. He makes up a lot of shit. He really should have more supervision.

Re: "A look @ the future & the future IS now.

[byornski]

I had had a few beers and wanted to see how far he'd argue his nonsense :D

It's no nonsense to be safe vs. this as I am

[Anonymous Coward]

It's no nonsense to be safe vs. this as I am. You're not questioning that either after this https://hardware.slashdot.org/comments.pl?sid=10581229&cid=54373735/

APK

P.S.=> Enjoy your beer (Paul Masson here) - you need it apparently & this really "got your goat" that you reappeared to say that (you project it got to you), lol... apk

Hey Blowhard "ne'er-do-well" talker Brockmire

[Anonymous Coward]

"You've made nothing original" - by Brockmire ( 4931623 ) on Monday May 01, 2017 @07:34PM (#54337699)

You've made NOTHING - prove otherwise FAKE NAME for your FAKE LIFE!

---

"You did not come up with the idea of a hosts file" - by Brockmire ( 4931623 ) on Monday May 01, 2017 @07:34PM (#54337699)

Did I say I did? No.

---

"You are not the first to use the hosts file" - by Brockmire ( 4931623 ) on Monday May 01, 2017 @07:34PM (#54337699)

Did I say I was?? Again, no.

---

"You are not even the first person to aggregate block lists into a single block list" - by Brockmire ( 4931623 ) on Monday May 01, 2017 @07:34PM (#54337699)

Did I say I was??? Yet again, no.

APK

P.S.=> I only said mine's better & it's no mere 'script' you SCRIPT KIDDIE "ne'er-do-well" do nothing zero:

"thousands who've made scripts to do this already" - by Brockmire ( 4931623 ) on Monday May 01, 2017 @07:34PM (#54337699)

They used prebuilt scripting tools that do a job (users want GUI, not mere scripts) vs. the fact that I wrote literally the equivalent of 14 UNIX commands into an EASY TO USE GUI multithreaded multitasking 32/64-bit non-runtime driven SINGLE .exe program to do it & do it better vs. my competitors (have you? Oh HELL no)... apk

Usage

[Anonymous Coward]

I certainly hope that no one uses this to restart my comp^^$^@^#^@

NO CARRIER

The problem is lack of memory controllers.

[Anonymous Coward]

MMUs, IOMMUs, and peripheral bus glue chips.

The only RISC-V cpus available to the consumer market are arduino or similiar replacements. Bare chips, without either data bus width or i/o options necessary to produce a desktop, notebook, or sbc off of.

Same deal with the J-series SH-clone processors (original designers from the SH on that project!) focusing on embedded instead of crowdsourced desktop replacement.

The only options at this point are to find the engineers necessary ourselves and crowdfund a proper cpu design, whether using patented components (and thus costing more) or taking the hit to performance and only utilizing legacy unpatented devices which are still available commercially (sdram, pci bus, etc, all unpatented and moderately cheap for purposes of developing a small 1 GB memory system with SDRAM and PCI. Or Larger systems (64 GB and 32 bit PAE only) that are libre, but still not cost effective/performant against DDR4+PCIe+x86_64 plus SSE/AVX extensions.