Way to go Intel!
You're up to Microsoft grade fuck ups now! Welcome to the big leagues!
You can remotely commandeer and control computers that use vulnerable Intel chipsets by sending them empty authentication strings. You read that right. When you're expected to send a password hash, you send zero bytes. Nothing. Nada. And you'll be rewarded with powerful low-level access to a vulnerable box's hardware from …
You're up to Microsoft grade fuck ups now! Welcome to the big leagues!
With the recent lists of hardware failures and (discovered) bugs, Intel makes Microsoft look like an angel hold a nuclear detonator hiding at the back.
Yeah, totally new.
It's not like Intel endeared themselves to use with the FDIV (aka approximation bug) or F00F bug, for starters.
I could also rattle off many, many other hardware bugs, from various vendors, from old '286 BIOS bugs onward, but it'd be encyclopedic. Going back to things like Award BIOS in 32 and 64 GB hard drive handling, where WD software and the BIOS poorly handled things, resulting in trashed WD hard drives.
the username and password are hashed using a nonce from the AMT firmware plus a few other bits of metadata.
Well, if you will get a sex offender to help out with security, what do you expect?
I remember being told about it in about 2005, read a doc from the server vendor, sounded really nice (far better than the IPMI and serial port stuff we had at the time anyway, though not as good as HP iLO or (modern) Dell DRAC) at least for servers. Never managed to see it appear in any servers I have had. My last couple of laptops at least have AMT options though without more software it doesn't seem to do anything (was sort of expecting an iLO like experience, be able to connect to a web server on the management processor etc). I guess it was geared more towards corporate desktops these days.
Dug up my email from early 2006, the board the vendor was talking about was the Intel SE7230NH1LX, which was a Pentium D board, looking online I don't see a reference to AMT with that board, maybe it was an add on option though.
Well, Dell's DRAC once was an option. Can't say anything about iLO.
Come now, no one in their right mind would put a iLOM / DRAC style management port on t'Internet! At least they are (usually) on a separate physical port.
If you do want remote management you should be jumping in through a VPN first as a minimum as they are notoriously buggy and insecure.
Also not mentioned: Is this Intel vulnerability also exposed over WiFi? Could add a whole new set of fun & games available on public WiFi hot spots!
@Paul, right mind ? Have you heard what passes as modern IT execs ? There is no mind, only a buzzword echo chamber. If it saves 20c it will be ordered to be so.
"Have you heard what passes as modern IT execs ? There is no mind, only a buzzword echo chamber. If it saves 20c it will be ordered to be so."
Part of that problem is that in the, ahem, extremely unlikely event of something going horribly or tragically wrong with this week's fashion, the cost to recover doesn't usually come from the relevant IT exec's bonus or even from that budget. Some other bunch of suckers usually end up paying for it - often customers, other employees , or both.
So for example, offshoring can still look like value for money, if all that people look at is the short term impact on a narrow definition of costs and benefits. Look at the bigger picture and even corporate failures like BT Retail have realised that offshore customer service is not necessarily good for business.
As for corporate data protection: when will they learn? Holding a few board-level people up might focus the relevant minds. But in the UK there's going to be another 'bonfire of the red tape'...
The detection tool is for Windows only. Matthew Garrett knows what he's on about:
Ah ta, meant to add that link. Done so.
what kind of coder am I?
Rhetorical question. I know what kind of coder I am. I am the kind of coder that lied on my CV, got the job and now I copy/paste the code of clever people into my work. Even though I do not fundamentally understand what I am doing or what them function thingies accept as arguments or return as values... My code compiles.
Come off it, everyone who has ever written software has done something like this, which is why code should be reviewed before being committed. And I reckon too that anyone who has reviewed a piece of code has missed a clunker like this from time to time- noob or otherwise.
"Come off it, everyone who has ever written software has done something like this"
Sure, but it's disappointing that their system for reviewing code before it makes it into firmware didn't catch such an obvious mistake. Human error happens, but the review process should be designed to cope with that.
Another bug that highlights how the lack of a proper string type in C, and related operations, is dangerous from a security perspective. Any language I know that has a native string type also stores the length, and checks it a the first comparison step.
Unluckily, keeping design flaws acceptable when punched cards programs didn't require much strings manipulation is what's shacking many IT foundations.
Oddly, during my code monkey era, if I nobbed a bit of code, I examined the hell out of it and figured out what it did, how and why.
Of course, I date back to before the era of compilers being common. We used to do dev parties, where a few maniacs actually wrote raw object code.
While things have moved on, I can still disassemble code and figure out what that compiled code, disassembled and shown inefficient, actually does. While rubbish for complex code, such as office software or an entire OS, it's eminently useful in malware samples.
"Human error happens, but the review process should be designed to cope with that."
Something that I continually strive to achieve in our information security shop, as a hedge for when I make one of my legendary fuck-ups.
You know the type, such as that hibachi accident at Hiroshima in 1945, to which the US quite nicely accepted the blame for my accident.
It's purely bad coding, not C's fault that someone decided to use strncmp instead of strcmp. Looking at the code snippet we can be fairly sure that he two strings have already been validated and stored in their own string buffers, so why not use it? You'd get the same error in BASIC if you'd decided to use LEFT$ instead of = for some crazy reason.
And code review and QA should catch it. The fact that it didn't means AMT is probably full of other bugs.
No, it's C fault the lack of a string type with proper operators, and then the need to have n functions to perform the same task, each slightly different from the previous one, attempting to fix its issue.
It's the arrogance of the Unix/C people who believe they got the perfect design by divine suggestion over forty years ago, and nothing needs to be changed, that is creating innumerable issues in software. Face it, how applications work has changed a lot from the times of punched cards and batch jobs, little memory and slow CPUs. In many languages, that bug is simply impossible.
To have secure systems we need big changes in CPU designs, OSes, and programming tools. Otherwise, it's just a whack-a-mole game.
And how would a string type fix the fact the programmer used a substring compare function instead of a full string compare function?
In many languages, that bug is simply impossible.
There are languages without substring compare? Tell me which ones they are so I can avoid them.
"No, it's C fault the lack of a string type with proper operators"
Blaming C here is like blaming a hammer for hitting your thumb.
There's a reason why I map out all the states that my code assumes. This.
It is almost impossible to map all states to be honest and if you call external libraries (which is pretty hard to avoid) then you'll have to map those out as well 8) This is a bit of a blinder though, on what must surely be a code path that can be reasonably easily audited. As it is the gatekeeper then surely it shoudl warrant quite a lot of inspection.
Given how face-palmingly obvious it is and how long this has been out there we can assume that lots of cracking has been perpetrated via this channel. It is quite hard to not extrapolate to a conspiracy ...
"This is a bit of a blinder though, on what must surely be a code path that can be reasonably easily audited."
Never attribute malice to that which could be better attributed to being close to lunchtime or quitting time.
I've hastily reviewed documents at both times, to re-review, to reacquire my train of thought later, and was horrified at what I missed and then had to fix and review a bit farther back. And those were simple things, like mission plans (military) and policies.
Eventually, I narrowed my window of distraction time down and ceased such reviews until the later time period and pursued other items that required my attention. The change, distracting enough to avoid such errors.
This bugs a gem. It is easy to explain, succinct, and devastating.
It's teach-ability will almost make up for the pain of auditing the Intel based gear address the immediate problem. Almost.
ON ERROR GOTO HUMAN
Yeah, I'm a *bit* older than that. My first memory was being stuck, while wriggling, by a diaper pin. My next memory, JFK being shot to death, while mom was taking down curtains for laundering.
There is at least one more remote root/admin/god-mode AMT bug, which Intel haven't yet mentioned.
Can't say more for obvious reaons.
Are you referring to the NSA back-door?
"Are you referring to the NSA back-door?"
No, those have specific prefixes.
Oh! That was my internal voice, not my real voice, right?
...when the better function to use is also easier to use, and in fact on the same man page.
"Real Men" don't ask for directions, so the man page is totally out of the question.
Although, I'll admit, I've coded such an abomination more than once and while going over the code, thinking, "WTF was I frigging thinking?!".
Although, my best coding was in coding security, authentication and verification systems
I've also an infamous habituation for "fucking off", aka taking an additional break. I was productive enough to be able to do so, in each career I've had, which has now reached a half dozen, all high level successes, until the field faded. Before I could fatigue enough to not pay attention and miss things, it was time for a fuck-off time. Where I circulated among peers, resolved their problems, went out for a smoke, conversed for a bit, then went back to work.
In one corporate environment, efficiency analysts were annoyed at my waste of time and I insisted re-examination and permitted a non-additional break period examination. Shop productivity dropped by 30%, morale dropped even more and my own production dropped.
They re-examined their data and via interviews with those observing, noted my interactions and troubleshooting, while still managing to work my way to the remote smoking area.
Yeah, after, they recommended things my way. Alas, only for me.
Frigging idiots. Drove off other people, who would otherwise had advanced to such an SME level.
Who then worked for competitors.
This snag is quite important, so I'll drop this here:
Thanks for that - very useful.
It makes the point around a firewall running on an AMT-enabled system being unable to properly secure the system (I.e. Has the packet you sent to the firewall been intercepted by the management processor rather than the firewall CPU). I suspect that may affect a lot of security people's assumptions about their network setup if the firewall is running on an AMT platform through pfsense, virtualisation or similar. And I'm very interested to see if any vendors come out with firewall patches. As for any environment you can't physically validate yourself...
I tend to go for stupidity over malice when looking for explanations for this type of thing, but I'm going to add a bit my tinfoil to my head ware just in case...
This problem requires some sort of direct network access. If you have a router based on a Dell/HP/IBM/whatever Core i5 or 7 and your WAN connection comes from the NICs that are onboard then this could be an issue for you.
eg, you repurpose an old server system (with AMT) as a pfSense based router and plug an on board nic into WAN. That NIC is not directly accessible by anyone other than your ISP - in theory. Mind you, who knows what is on your ISP's network anyway?
You get the idea.
Such interfaces, DRAC, this, various other management interfaces, should always be on an internet blind VLAN, accessible only from the management VLAN, which also does not have access to the internet.
*That* is the damage limitation.
WTF would you put a management *anything* openly accessible to the entire frigging internet?! If anything, it should be via authorized VPN connections that are allowed to access the management server's VLAN, which can access that VLAN only.
Christ on a crutch! This isn't complicated!
The firmware update mentioned security and said "HP strongly recommends" so I'm pretty sure it is the one. Luckily I just had bought a new laptop last fall so it is still actively supported. I'll have to see whether Dell ever releases a firmware update for my old laptop. Since I never use either one wired I'm not really too worried.
Due to a relocation, change of lab and production networks, loss of critical equipment, due to that relocation, I'm now down to two potentially vulnerable systems.
A previously desired reconfiguration will be advanced to next weekend.
There's a big plus in having enterprise networking equipment at home. :)
The very common Lenovo T4xy Thinkpads are affected by this bug.
There's lots of badly written, never audited software with hardware privileges running in modes, inaccessible to the operating system.
For example when USB came to the market, operating system and BIOS vendors couldn't be asked to implement it, after all it's a rather complex protocol. So the CPU vendors shipped a special binary blob which used the Service Mode of the CPU to emulate standard PC devices even though you actually had USB ones. On bad laptops even things like battery control are done by Service Mode software.
Well, without that you'd not be able to boot from a USB stick, so there are obvious trade-offs. They can own your machine, and you can own other people's.
Presumably as this is an Intel bug, can we presume that a AMD based system is unaffected?
From this particular bug yes, but probably they have their own ones...
When it comes to bugs, I'll take probably over definitely any day.
Depends what you mean by "AMD based". If the motherboard chipset is Intel but the CPU is AMD then the system would be vulnerable.
Definitely rare though, a quick google suggests it was last possible before this vulnerability existed, so unless you have something like this...
...then you should be safe.
Erm, this is enterprise specific hardware, not consumer geared hardware.
So, 99.9% of the userbase on the planet are not vulnerable to this bug.
So, my wife's hardware isn't vulnerable. Some of my hardware might be. :/
A bit of network reconfiguration would take care of that issue. :)
It was a very similar bug that lets pirated Wii games to be played on the console. Strncmp used to compare the hash of the executable with the some other value (sorry, can't remember the exact scheme). So just need to make sure the hash has a null character as it's first byte.
How intriguing, seeing as how the AMT processor runs the ARC instruction set, which Nintendo also use.
So code not developed by Intel at all, but inherited from ARC?
But written by a total f**kwit?
The Wii's bootloader and OS are run by an ARM coprocessor in the GPU, but the games themselves are run by a PowerPC.
Your last sentence is, of course, correct.
Never trust user input!
(Programmer for more years than I care to mention)
Some say it's a coding bug, others say it's an NSA backdoor.
Biting the hand that feeds IT © 1998–2018