Slashdot Mirror
US-CERT Discloses Security Flaw In 64-Bit Intel Chips
Fnord666 writes "The U.S. Computer Emergency Readiness Team (US-CERT) has disclosed a flaw in Intel chips that could allow hackers to gain control of Windows and other operating systems, security experts say. The flaw was disclosed the vulnerability in a security advisory released this week. Hackers could exploit the flaw to execute malicious code with kernel privileges, said a report in the Bitdefender blog. 'Some 64-bit operating systems and virtualization software running on Intel CPU hardware are vulnerable to a local privilege escalation attack,' the US-CERT advisory says. 'The vulnerability may be exploited for local privilege escalation or a guest-to-host virtual machine escape.'" According to the article, exposed OSes include "Windows 7, Windows Server 2008 R2, 64-bit versions of FreeBSD and NetBSD, as well as systems that include the Xen hypervisor."
Why is this tagged linux and redhat
Proper link that ought to have been in the summary instead of that csoonline link (whatever that is):
http://www.kb.cert.org/vuls/id/649219
"Besides Microsoft and Intel, vendors whose products are affected include Joyent, Citrix, Oracle, Red Hat and SUSE Linux, US-CERT says."
So what exactly is the bug?
The story gives about as much information as the summary.
Apparently there is some instruction that doesn't do exactly what the amd64 specification says, but what exactly does it do?
XP, Win7, and Server Core are affected, but somehow, Vista isn't!
-- Who am I? How did I get here? My God, what have I done?!
Say you have local access to a machine, which is a Xen guest. Does the machine KNOW it's a guest? If yes, how "virtual" is it, and if no, how would the attacker know to try the escape?
I want to delete my account but Slashdot doesn't allow it.
Microsoft Corporation: Affected by the bug-
notified:01 May 2012 corrected:08 Jun 2012
Debian GNU/Linux: Affected by the bug- Unknown
notified:02 May 2012 corrected:02 May 2012
Easy victory for debian, as there was no manager who had to wonder how fixing the bug ASAP vs. schedule the fix for later could potentially affect his career...
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
If some operating systems are not affected, doesn't that make this a software issue?
Got a citation for that?
I thought it was interesting to note that the article never mentioned anything about OpenBSD. While this does not necessarily mean that OpenBSD is not vulnerable to the Intel 64-bit bug, I still find it interesting. If OpenBSD had been tested, I wouldn't be surprised if researchers found privilege escalation by exploiting said bug impossible. The OpenBSD team has spent an inordinate amount of time working to make their OS highly secure.
http://www.linuxjournal.com/content/allegations-openbsd-backdoors-may-be-true
Only the State obtains its revenue by coercion. - Murray Rothbard
having worked for two government agencies and three private companies, I can say that the private corporations are no better, wasting more. Both government agencies ran a very tight ship.
Like all pain, suffering is a signal that something isn't right
Actually as Microsoft contributions to Linux increases so does the migration away from Linux towards BSD.
I am surprised that it took this long for it to reach /.
Linode.com had already patched the items last month. During an emergency but scheduled update round (took less than 30mins per host) and most users did not notice any issues since they were given more than 7 days advanced notice of the emergency update. [linode uses XEN on intel].
http://blog.linode.com/2012/06/13/xen-security-advisories-and-how-we-handled-them/
--
Time is on my side
This flaw apparently affects only Intel chips as the vulnerability does not exist for AMD 64-bit chips.
That's the power of the GPL. Even the mighty Microsoft must contribute code. Meanwhile Apple gets rich off the work of the basement dweller neckbeards who hack BSD without paying them or even giving any code back, haha.
You think this is bad? Dell did the same to me, even though my machine has (came from factory with) 4GB of RAM! And the combination of their BIOS + drivers only allow 2.9 GB of usable RAM on the default OS (Win7 32-bit)! I've seen some posts saying that you're now allowed to install a Win7 64-bit with a key from 32-bit OS, but anyway you can't just upgrade a 32-bit installation to 64-bit (you have to reinstall).
Um... really?
http://opensource.apple.com/
Having worked for both the government and private companies, I can say the exact opposite. Horrible benefits, low pay, general incompetence in staff and bureaucratic road blocks making sure nothing could get fixed, all led to my making the decision to never work for a government organization again. At least a private company is only wasting its own money and not tax dollars.
I know some people who used to work there. You are quite wrong.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Has it not occurred to anyone here that this (and many other "flaws") are simply the carefully designed, plausibly deniable backdoors for the next generation of Flame, Stuxnex, etc? Are you all really that naive?
They better release a fix before agent Smith finds about it...
... except if they are a government contractor.
now we need to go OSS in diesel cars
BSD is dead. CERT confirms it?
or maybe the reason is that OpenBSD does not include any virtualisation, rather than it being robust?
Virtualization is irrelevant in this case. Just as Linux fixed this bug in 2006 (CVE-2006-0744) OpenBSD had added a check 2 years earlier, in 2004. Indeed, this is a great example of the "silly security facists slowing down the kernel with unnecessary sanity checks" paying off in spades. (This message was written on Ubuntu 12.0.4 on an AMD64, but will pass through an OpenBSD x86 firewall before getting to /.)
One processor bug like this exploitable from NaCL native client code could lead to exploits for millions of computers before it is patched. The patch could even require interpreting NaCL code possibly at hundredths of the normal speed. It's also why WebGL is a bad idea, since the graphics card has DMA access one driver bug could be used to exploit the entire OS.
I got fired from my government job. It happens to people all the time.
It's not a flaw but a feature of the Patriot Act and the NDAA.
The mind conceives, the body achieves, the spirit manifests.
Is there a windows microcode update yet?
My understanding is that RCX going into the SYSRET instruction contains the saved instruction pointer from when SYSCALL called into kernel-space, which should necessarily be valid/canonical if the userspace code that performed the SYSCALL was able to run. How does RCX get replaced by an invalid/noncanonical pointer? Is the return address saved on the userspace stack and modifiable from another thread with access to the same VM space while one thread is in kernelspace? Or is there some other mechanism for feeding it an invalid address? None of the discussions of the vulnerability I've seen have addressed this issue.
...or have a union.
MidnightBSD was also affected by this bug. It was fixed in 0.4-CURRENT already, but still exists in the latest release.
It's both an OS problem and Intel's fault for implementing the instruction differently than AMD.
I would for a government agency. Our jobs are the most unstable there are (layoffs once or twice a year), no superannuation plan, no benefits, low salary, and generally it's just shit. I only stay there because I like the team I work with.
For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
http://lxr.linux.no/linux+v3.4.2/arch/x86/kernel/entry_64.S#L451
In fact, that referenced line was probably added back when this vulnerability was first found in 2006. That is referenced in the above US-CERT: CVE-2006-0744 (http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2006-0744).
Linux kernel before 2.6.16.5 does not properly handle uncanonical return addresses on Intel EM64T CPUs, which reports an exception in the SYSRET instead of the next instruction, which causes the kernel exception handler to run on the user stack with the wrong GS.
Same thing!
The fact that it has taken 6 years to migrate this vulnerability to other systems is somewhat discouraging.
To be honest, I think it's because Intel screwed up but didn't own up. If you look at the description of the 2006 Linux fix, it makes it sound like it was somehow Linux's fault; when Linux's code works just fine to the AMD specs. Intel's instruction was supposed to be a copy of the AMD instruction. If every single operating system vendor, independently, managed to "not properly handle uncanonical return addresses on Intel EM64T CPUs", it's hard not to conclude that it was a mistake on Intel's part (at very least in documentation). They should have gone around to all the operating system vendors and told them about the vulnerability when it was first discovered in 2006, and put a note in the instruction manual stating that it's important to check the return address.
TCP: Why the Internet is full of SYN.
Clarification on the FreeBSD inclusion:
A quick review of the related FreeBSD advisory(*) reveals that FreeBSD is only vulnerable to this if one has mis-matched the install-version of the OS to the hardware. Installing either the amd64 version on AMD hardware, or the i386 version on Intel hardware is fine. The risk comes from installing the AMD version on Intel hardware.
Arguably, not a lot of people who'd install FreeBSD in the first place would go with that seemingly obvious mismatch.
(*) http://security.freebsd.org/advisories/FreeBSD-SA-12:04.sysret.asc