US-CERT Warns of Intel CPU Flaw

ShintaiDK

Lifer
Apr 22, 2012
20,378
146
106
http://www.kb.cert.org/vuls/id/649219

The majority of customers have automatic updating enabled and will not need to take any action because this security update will be downloaded and installed automatically.
Customers who have not enabled automatic updating need to check for updates and install this update manually.

Install KB2709715 for W7 and 2008 R2.

An attacker must have valid logon credentials and be able to log on locally to exploit this vulnerability. The vulnerability could not be exploited remotely or by anonymous users.

Apple and VMware not affected.

Microcode aka distributed with BIOS updates also fixes it. Or for example OSes where you can load microcode at bootup.

For example Linux:
http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=21385&keyword=%22microcode%22&lang=eng
 
Last edited:

Khato

Golden Member
Jul 15, 2001
1,305
383
136
Indeed they are... because software didn't follow Intel's specification for the SYSRET instruction. Now sure, feel free to still blame Intel for not implementing the exact same behavior as AMD... just remember that such is only the case because AMD's specification was ambiguous.
 

Ferzerp

Diamond Member
Oct 12, 1999
6,438
107
106
Indeed they are... because software didn't follow Intel's specification for the SYSRET instruction. Now sure, feel free to still blame Intel for not implementing the exact same behavior as AMD... just remember that such is only the case because AMD's specification was ambiguous.


That would be an unbiased view of the situation yes. :whiste:



I think the poster would like there to be some massive problem with Intel procs though. Disappointingly for him, this won't be it.
 
Last edited:

piesquared

Golden Member
Oct 16, 2006
1,651
473
136
That would be an unbiased view of the situation yes. :whiste:



I think the poster would like there to be some massive problem with Intel procs though. Disappointingly for him, this won't be it.

Nah, you think wrong. My motive was because this story broke about a week ago and was largely swept under the rug, and at the same time was plastered across the GPU forums about the same issue with some GPU's.

Love the part about blaming AMD though. lol
 

Ferzerp

Diamond Member
Oct 12, 1999
6,438
107
106
Ah, well, I'm sure I can find all your posts of software flaws over on the software forums for patches that need applied there. After all, you're just trying to inform us, so surely you inform us of all patches that should be applied, yes?

I'll go check them out! Thanks for your service! I bet you have like 5 Adobe posts a month or so, yes?
 

ShintaiDK

Lifer
Apr 22, 2012
20,378
146
106
Nah, you think wrong. My motive was because this story broke about a week ago and was largely swept under the rug, and at the same time was plastered across the GPU forums about the same issue with some GPU's.

Love the part about blaming AMD though. lol

Not much story in it. Hence why. For example on Windows we talk a local console user that is authenticated. Not to mention its already patched.

And if you already knew it a week ago. Then why pick one of the least telling link you can find without any sources. Just post the CERT link instead.
 
Last edited:

Ferzerp

Diamond Member
Oct 12, 1999
6,438
107
106
Not much story in it. Hence why.

Pretty much. Privilege escalation on a few OSes because of a discrepancy in two different implementations, both of which fit the letter of the published spec. Privately disclosed and patched in all affected OSes before public disclosure. No working code in the wild that utilizes this flaw. Not really an issue.

Sadly, I couldn't find any more piesquared security posts. Surely he would have told us about MS's "little" mistake where terminal server licensing servers could create MS signed certificates earlier this month. That one was an actual major risk to all windows systems.
 
Last edited:

Ferzerp

Diamond Member
Oct 12, 1999
6,438
107
106
Well, I suppose my use of "local" was a little bit incorrect. In theory, remote, authenticated sessions would work too here. Let me remove the local from my post.
 

Khato

Golden Member
Jul 15, 2001
1,305
383
136
Love the part about blaming AMD though. lol

Hey, I'll take any opportunity I can to shed light upon the fact that AMD's x86-64 specification isn't the awesome innovation that some would like to believe it is. If AMD had provided adequately precise pseudocode in their documentation of the SYSRET instruction then Intel would have implemented the very same. Instead Intel noticed the ambiguity, decided which behavior made more sense, and documented their implementation properly.
 

piesquared

Golden Member
Oct 16, 2006
1,651
473
136
Hey, I'll take any opportunity I can to shed light upon the fact that AMD's x86-64 specification isn't the awesome innovation that some would like to believe it is. If AMD had provided adequately precise pseudocode in their documentation of the SYSRET instruction then Intel would have implemented the very same. Instead Intel noticed the ambiguity, decided which behavior made more sense, and documented their implementation properly.

You'll notice that none of AMD's CPU's are affected.

AMD processors are reportedly not affected. SYSRET is part of the x86-64 standard as defined by AMD. Intel uses a different implementation and it is apparently this difference that can allow an attacker to write to arbitrary addresses in the operating system’s memory. Affected operating systems include the 64-bit versions of Windows 7 and Windows Server 2008 R2, NetBSD, FreeBSD, as well as Linux distributions, including Red Hat and Suse, and operating environments from Citrix, Joyent, Xen and Oracle.
 

Phynaz

Lifer
Mar 13, 2006
10,140
819
126
You'll notice that none of AMD's CPU's are affected.

Apple uses Intel CPU's right? And yet they are not affected. VMWare? Nope, no problem there.

Hmmm...Guess that makes it a software issue, not an Intel CPU issue. Don't let the facts get in your way though, carry on :)

My motive was because this story broke about a week ago and was largely swept under the rug, and at the same time was plastered across the GPU forums about the same issue with some GPU's.

Incorrect again. That was not a GPU issue, it was a software issue - and still is as it remains unpatched. But, just as this it is also basically a non-issue and affects almost nobody.
 
Last edited:

Ferzerp

Diamond Member
Oct 12, 1999
6,438
107
106
Amusingly, what you insist upon calling a flaw is functioning exactly like the documentation that Intel provides for the instruction. Some software vendors wrote some pretty bad code that makes some assumptions that the documentation is pretty explicit in showing that those assumptions cannot be made.

I suspect you aren't really interested in the actual facts though.

It takes a pretty odd leap of logic to take a product that functions exactly as the documentation for that product says it does, have someone treat the product as if it functions differently than the documentation that has been provided, and then claim the product is at fault when it is performing exactly as specified.

Please, explain to us how you can call this a flaw when the instruction performs exactly as Intel claims it performs? An implementation that exactly fits the wording of the specs AMD published for the instruction when it made it. Sadly, the documentation of the spec allowed for multiple differing implementations that have material differences. That looks to me like a flaw in the original documentation.

If you would like to discuss specifics on how Intel's implementation of the instruction doesn't fit either their documentation of their implementation, or the wording of AMDs spec for the instruction, feel free. Otherwise, we can only assume that your claims are just an attempt at FUD.

I really don't expect that you'll actually respond.
 
Last edited:

Vesku

Diamond Member
Aug 25, 2005
3,743
28
86
I don't think I would be pointing the finger at specifications for things like this. It's a software mistake handled responsibly. Also a good reminder to keep on top of OS security updates and that micro-code update (is there a security update in a newer motherboard BIOS? Roll the dice on motherboard manufacturer update information.) information is not very well delivered to regular IT folk :( . For anyone still wondering, this is why companies like Dell and HP get paid good money for service contracts. A bit of CYA finger pointing if your systems happen to be left vulnerable.
 

piesquared

Golden Member
Oct 16, 2006
1,651
473
136
It's too bad intel didn't follow the standard as set out by AMD, none of this would have happened :shakeshead:. Why must intel relentlessly cause problems? Why why why!
 

ninaholic37

Golden Member
Apr 13, 2012
1,883
31
91
Intel uses a different implementation and it is apparently this difference that can allow an attacker to write to arbitrary addresses in the operating system’s memory.
Sounds like fun. Reminds me of C programming in Dos, how when you walk off the map of a game you end up in a different area of memory beyond the array, and can throw something at area[99][184]=1 which ends up being the address of "boolean godmode;". Nice to know we can explore a similar adventure into the Windows/Linux 64-bit OS world (running Intel) in 2012. :D
 

Ferzerp

Diamond Member
Oct 12, 1999
6,438
107
106
Linux was vulnerable but patched in 2006, so that would be pretty difficult in 2012.