Intel's Remote Hijacking Flaw Was 'Worse Than Anyone Thought' (arstechnica.com) 200
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."
"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."
I don't think you know what that word means. (Score:5, Funny)
"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. (Score:4, Informative)
"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: (Score:2)
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: (Score:2)
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: (Score:3)
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. (Score:5, Interesting)
You know that Intel processors without AMT still have the capability but it is disabled in software...
Re: (Score:2)
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: (Score:2)
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
Re: (Score:3)
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: (Score:3)
Re: (Score:2)
Re:I don't think you know what that word means. (Score:5, Informative)
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).
Lack of negative testing - extremely common (Score:5, Interesting)
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: (Score:2)
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: (Score:3)
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: (Score:2)
Re: (Score:2)
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 st
Re: (Score:2)
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.
Good question. Perhaps "not" tests, securit review (Score:2)
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 s
Re: (Score:2)
Re: (Score:2)
Programmers get so focused on making things work
Except for DRM programmers, who get so focused on making things not work.
Predictable outcome (Score:5, Insightful)
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 (Score:5, Interesting)
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 [hackaday.com]. 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 (Score:5, Informative)
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: (Score:3, Interesting)
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.
Re: (Score:2)
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% ?
Re: Predictable outcome (only in windows?) (Score:5, Informative)
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 [fsf.org]
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 (Score:5, Insightful)
"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.
Ars story highest voted comment (Score:5, Informative)
(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)) ... entication
https://en.wikipedia.org/wiki/Digest_ac
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: (Score:2)
Re: (Score:2)
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 (Score:4, Interesting)
strncmp(response , computed_hash, strlen(computed_hash)) would be good. Or, hardwired a lower limit to avoid comparing strings less than 32 bytes.
Re: (Score:2)
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.
strncpy is broken, period. (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
strncpy is not supposed to be a "safe" variant of strcpy.
strncpy is NOT a safe version of strcpy.
Yawn. Practice your reading comprehension.
Re: (Score:2)
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: (Score:1)
Re: (Score:3)
You're assuming that this was an accident rather than a backdoor.
Re: (Score:2)
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 so
Re: (Score:2)
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: (Score:1)
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 k
Re: (Score:2)
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.
C langage guilty again. (Score:2)
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: (Score:2)
Re: (Score:2)
Responsibility for such flaws (Score:5, Insightful)
Re: (Score:3)
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.
We've known for years that AMT was a risk (Score:5, Informative)
see e.g. https://hardware.slashdot.org/story/15/01/29/2241214/fsf-endorsed-libreboot-x200-laptop-comes-with-intels-amt-removed
Moneyquote:
But hey, the FSF and Stallman are just overreacting hippies right? RIGHT?
Re: (Score:2)
Why can't both things be true?
Because one of them is nonsense promulgated mainly by special snowflakes with vested interests.
And people wonder why . . . (Score:2, Insightful)
Russian and Chinese government agencies have been passively or actively promoting the development of a domestic semiconductor industry.
Disable (Score:2)
Any way to disable this in Linux?
Re: (Score:2)
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: (Score:2)
http://web.archive.org/web/201... [archive.org]
Re: (Score:1)
Re: (Score:2)
As if firewalls are bulletproof.
Re: (Score:2)
Whoopsie? No way (Score:4, Insightful)
" 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: (Score:2)
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: (Score:2)
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: (Score:2)
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 (Score:2)
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 (Score:3)
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: (Score:3)
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... (Score:2)
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.
Active xxx (Score:2)
Active Management Technology... it sounds so much like ActiveX, and equally porous it would seem.
Stallman was Right (Score:3)
We succumb to the overlords when we use proprietary software!
Discovery tool only Windows (Score:4, Interesting)
Re: (Score:2)
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.
Unprovisioning clients (Score:3)
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/... [wikipedia.org]
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: (Score:2)
Re: (Score:2)
Really? I could do that by unplugging the cable...
Re: (Score:2)
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!
Computer manufacturers let you disable AMT (Score:3, Interesting)
Re: Dear Intel (Score:2, Redundant)
Re: (Score:1)
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 (Score:5, Interesting)
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: (Score:2)
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.
Re: (Score:3)
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: (Score:2)
Err... no?
Re: (Score:3)
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: (Score:2)
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
Re:It's time to hold engineers liable (Score:5, Insightful)
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: (Score:2)
Re: (Score:2)
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.
Thanks for the comment. (Score:2)
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
and
So a remote exploit could just consist of power cycling to boot from a external boot image. Only OS
Re: I block those ranges in my firewalls... apk (Score:2)
Re: I don't run a LAN here (don't assume)... apk (Score:2)
Re: "A look @ the future & the future IS now.. (Score:2)
Re: LEARN TO READ please... apk (Score:2)
Re: (Score:2)
Re: (Score:2)