Tag Archives: Intel

Friday News

Intel will NOT be patching all of its flawed chips

After saying, for months, that it would release firmware updates to all chipsets produced in the last 5 years, Intel is now backtracking saying that it won’t produce patches for the Bloomfield line, Clarksfield, Gulftown, Harpertown, Jasper Forest, Penryn, SoFIA 3GR, the Wolfdale line, and the Yorkfield line.  There were several reasons, number one being that it was too hard (read:impossible) given the architecture of those chips.  (Source: The Verge).

Microsoft Patch Tuesday Patches at Least 65 Vulnerabilities

From one perspective, given the breadth of Microsoft’s empire, releasing 65 SECURITY patches a month is not unreasonable.  On the other hand, given that they have been doing this for years, that is thousands of security flaws, which is a bit mind blowing.  This month’s patches affect Internet Explorer and Edge, Office, one more time, the Microsoft Malware Protection Engine, Visual Studio and Microsoft Azure.

A patch for the Malware Protection Engine (MPE) bug was release in an out-of-band patch last week because it affects all of Microsoft’s anti-malware products such as Windows Defender and Security Essentials.  This is at least 3 emergency patches to the MPE in recent months.

Corporate IT usually has patching handled, but when it comes to home users, things are a bit more spotty, so make sure that you install these patches (Source: Krebs On Security).

Identity thieves going after CPAs

If the IRS is warning tax preparers to “step up” their cybersecurity game, it must be bad. Brian Krebs details the story of a tax preparer who allowed his system to become compromised with a not very sophisticated keystroke logger.  The result was that his client’s data was hacked and false returns filed.  When the client’s real returns were rejected by the IRS, the CPA provided form letters to his clients to file with the IRS saying that they were the victim of identity theft but not saying that it was the accountant who was responsible.  No doubt the clients were left with the bill to client up their CPA’s mess on top of it all.

If you use a tax preparer, you should be asking questions about their cybersecurity practices and if he or she says not to worry, you should start worrying.  Or looking for a more astute CPA (Source: Brian Krebs).

Atlanta, Colorado spending millions after ransomware attack

Atlanta has spent over $2 million mitigating the ransomware attack which started on March 12.  The attackers asked for $50,000 which likely would have been covered by insurance.  The costs are for Secureworks, Ernst and Young and others.  If these costs are to upgrade inftrastructure, the insurance would not cover that.

The Colorado Department of Transportation (CDOT) has spent $1.5 million since their ransomware attack in February.  CDOT is still not fully operating yet.

Stories are that Atlanta’s IT was on life support due to lack of funding prior to the attack.  Assuming some of those millions are being spent on upgrading the infrastructure, maybe the attack has a silver lining.  (Source: SC Magazine).

Facebooktwitterredditlinkedinmailby feather

Is Turnabout Fair Play?

Tech Crunch is reporting that Intel told customers about the Meltdown and Spectre flaws before the public announcement, but they did not tell the U.S. Government about it.

Most of the time, it is the other way around.  The U.S. Government knows about a flaw but doesn’t tell the company who can do something about it.

One kind of strange twist to this is that, apparently, they did tell some Chinese customers, who likely did tell the Chinese government about it.

There certainly is no law that requires them to tell the U.S. Government about the flaw, ever.  Just like there is no law that requires the U.S. Government to tell Intel about any flaws that it knows about.

Still, it seems odd that they would opt to tell a Chinese company (likely a large OEM, maybe Lenovo?) and not tell Homeland Security.

They claimed that they were unable to tell everyone they planned to tell because the news leaked early.

Just to be clear – they knew about the problem since June.  They PLANNED to announce the bug on January 9th, but it was leaked on January 3rd.

This means that even if they did plan to tell the Feds about the “issue”, they didn’t plan to tell them in enough time to do anything about it.  Intel declined to say who they did tell about the bug or who they were planning to tell about it.

There is another part to this story, however.

There was a research paper published about this flaw in 1992.  That would be 26 years ago for those who are not good at math.  There was another paper on the subject around 1995. The NSA is VERY good at reading research and figuring out if they can exploit it.  That is what they are supposed to do and even though people like to complain about them, they are pretty damn good.  Maybe not perfect, but VERY, VERY good.

SO, an argument could be made, but not proven, that (a) the NSA and maybe other parts of the government knew about this flaw, (b) other governments, friendly and not so friendly knew about it and (c) some of them might have been selectively exploiting it.  For possibly, up to 25 years.  Even if the various governments who are likely to have known about it (Russia, China, Israel, U.S. and others) denied that they knew about it, would you believe them?  After all, lying is part of their business also.

For Intel, this is just more bad news to tarnish their reputation, although it doesn’t seem to be hurting their stock price at the moment.

Still, with AMD about to release their Ryzen Threadripper 2 later this year, which is supposed to be  much faster than the new Intel i9 at less than half the price, they don’t really need any more good news.

Who said there was no such thing as bad publicity?  That person might want to talk to Intel and see if they agree.

Information for this post came from Tech Crunch.

 

Facebooktwitterredditlinkedinmailby feather

Windows and Linux to Patch Major Intel Chip Flaw

UPDATE: Google’s Project Zero released information about the flaw and attacks as reports and speculation escalated (see here).  Reporters, including this one, are just learning the details of this.  An FAQ about the attack, which says that it affects Intel, AMD and ARM processors is available here.     It does, they say, affect every microprocessor made since 1995.

Microsoft released an emergency patch overnight and Amazon announced that they have completed patching all but a small number of machines, which will be patched in the next few hours.  Expect more announcements over the next days.

Keep in mind that attackers will have to figure out how to weaponize this, but applying this patch should be considered critical.

The big tech news of the day is that Microsoft and the Linux community are about to release major patches to both environments including all supported versions of both to cover a known problem in the Intel x-64 environment.  For Linux users, you will need to make sure that the particular distribution that you are running has the patch.  I assume but do not know that Microsoft will patch all supported operating systems back down to Windows 7.

Intel made some design decisions years ago to combine the operating system kernel and the user’s code into a combined environment to make it quicker to provide operating system services to user programs.

The details of the bug have been embargoed until the Windows and Linux patches have been released.  Apple released their MacOS patch (10.13.2) in mid December.  Still, reverse engineering betas of the Linux code is giving folks at least a partial idea of the problem.

Several years ago operating system vendors implemented a feature called address space layout randomization or ASLR, sometimes called KASLR for Kernel ASLR.  ASLR randomizes where operating system modules are placed in memory in order to make it harder for attackers to jump to places in the operating system to do their dirty work.

Unfortunately, it appears, the bug allows programs, from web browsers to databases to read the kernel memory.  IF it is possible for user programs to access the operating system kernel memory, they could find passwords, among other things.  They could also read the tables used for ASLR, effectively totally neutering that technology.

Given all this and possibly more, the patch becomes critical.

For enterprises and end users, installing these patches quickly is important because as of today, hackers are likely thinking about how to abuse your systems.

A couple of more things.

The question came up whether Intel could patch the microcode to fix this.  The answer, apparently, was no.  This was a fundamental design flaw.

Also, apparently, it required major effort on the part of Windows and Linux developers.  So much so that they were tempted to name it Forcefully Unmap Complete Kernel With Interrupt Trampolines. You can figure out what the acronym for that would be.

Oh yeah, there was a reason that Intel did things the way that they did – PERFORMANCE.  This performance change will cause a performance decrease of from 5% to 30% depending on the chip family.  This means that the patches have to be coded differently for different chip generations.  The performance hit will especially hit cloud providers like Google Compute Engine and Amazon EC2.

Finally, since this is a problem with Intel’s chip implementation, it does not affect servers with AMD processors in them.

I assume that Intel will fix this in the next generation of chips, but then we will have to add yet another hack to look to see if this is a new chip with the instructions implemented differently and code that again differently.  What a mess.  Shades of the Intel 486 Divide problem.  At least that could be fixed by updating the microcode in the chip.

This one is a big deal!

Information for this post came from The Register.

Facebooktwitterredditlinkedinmailby feather