Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Intel CPU Privilege Escalation Exploit

timothy posted more than 5 years ago | from the they-never-offer-the-purple-pill dept.

Security 242

Eukariote writes "A paper and exploit code detailing a privilege escalation attack on Intel CPUs has just been published. The vulnerability, uncovered by security researchers Joanna Rutkowska (of Blue Pill fame), Rafal Wojtczuk, and, independently, Loic Duflot, makes use of Intel's System Management Mode (SMM). Quote: "The attack allows for privilege escalation from Ring 0 to the SMM on many recent motherboards with Intel CPUs. Rafal implemented a working exploit with code execution in SMM." The implications of this exploit are severe."

cancel ×

242 comments

And thus does the dance continue... (4, Insightful)

downix (84795) | more than 5 years ago | (#27258243)

The dance between malware writers and the security experts seeking to thwart them continues ever on.

Re:And thus does the dance continue... (2, Informative)

maxume (22995) | more than 5 years ago | (#27258519)

Hopefully this guy is playing for the good guys:

http://blogs.zdnet.com/security/?p=2934 [zdnet.com]

Bring back burning at the stake! (0)

Anonymous Coward | more than 5 years ago | (#27258703)

I for one would love to torch the pile to BURN the evil these devils are!

Ouch (5, Funny)

Big Hairy Ian (1155547) | more than 5 years ago | (#27258245)

This could make the apple bricking patch look like a kindergarten party

Re:Ouch (4, Interesting)

Z00L00K (682162) | more than 5 years ago | (#27258513)

Just consider a malware that replaces the PC BIOS with it's own code. Sure it may brick a few, but it may also be a new interesting level of malware.

Write-protect your BIOS:es and you can be a bit safer.

Another interesting thing is that this may be a way around the TPM chip and other copy-protection techniques too.

And beware of special bioses from manufacturers that allows your employer to run keylogging!

Re:Ouch (4, Informative)

Molochi (555357) | more than 5 years ago | (#27258987)

I think this bypasses bios write protection unless you still have a motherboard that uses a jumper for this. None of mine do.

Could be used as a force for good, true.

Bricking patch look like a kindergarten party (0)

Anonymous Coward | more than 5 years ago | (#27258553)

This could make the apple bricking patch look like a kindergarten party

A kindergarten party in a holodeck where all the attendees turn out to be old men.

Re:Ouch (1)

Jurily (900488) | more than 5 years ago | (#27258577)

This could make the apple bricking patch look like a kindergarten party

What's even worse: I have one of these.

Re:Ouch (4, Funny)

Knara (9377) | more than 5 years ago | (#27259151)

A kindergarten party?

Re:Ouch (5, Funny)

machine321 (458769) | more than 5 years ago | (#27259431)

I was on the apple bricking patch for a while, it really helped me quit apple bricking.

CD Boot (4, Funny)

Baldrson (78598) | more than 5 years ago | (#27258277)

TFA: The malware code takes over a PC with little or no recourse to remove it.

Haven't these guys ever booted from a CD?

Re:CD Boot (4, Informative)

adonoman (624929) | more than 5 years ago | (#27258353)

You're assuming that the rootkit isn't loaded before the bios tries booting off the CD.

Re:CD Boot (5, Funny)

CannonballHead (842625) | more than 5 years ago | (#27258403)

No, really. It takes it over! You can't even come within 5 feet of the case, the malware pushes you back!

Re:CD Boot (5, Informative)

I.M.O.G. (811163) | more than 5 years ago | (#27258481)

Haven't these guys ever booted from a CD?

While you succeed at being snarky, you fail at being correct. Assuming the article is credible and accurate, it explains why booting from a CD won't save you:

By design, the operating system cannot override or disable System Management Interupt (SMI) calls. In practice, the only way for you to know what is running in SMM space is to physically disassemble the firmware of your computer. So, given that an SMI takes precedence over any OS call, the OS cannot control or read SMM, and the only way to read SMM is to disassemble the system makes an SMM rootkit incredibly stealthy!

Now with that said judging by the authors language at networkworld he likely doesn't fully understand whats going on - he uses words like "powned" and "the PC is living in the matrix", whatever the fuck that means! I'll reserve my judgement on this until I read more from someone that owns a clue.

Ring of Fire (5, Interesting)

goombah99 (560566) | more than 5 years ago | (#27258585)

So it says you can promote from ring0 to SMM. So I take it that's a lower level of hell?

If you are running in ring zero doesn't that mean by definition you are completely trusted anyhow?

Or is the vision something like you enter your root password to install the cheeze-whiz app and the mal ware not only installs the code but escalates itself above the operating system.

I think I'm not getting it.

Re:Ring of Fire (2, Funny)

geckipede (1261408) | more than 5 years ago | (#27259215)

if you're on vulnerable hardware, once some malware that uses this trick has gained root, nothing short of physically setting fire to the motherboard will clean it. Reinstalling from scratch can't help you.

Re:Ring of Fire (1)

geckipede (1261408) | more than 5 years ago | (#27259257)

Er... no, I'm talking nonsense there apparently. Reading incompetence on my part.

Re:Ring of Fire (1, Funny)

Barsteward (969998) | more than 5 years ago | (#27259285)

"If you are running in ring zero..."

No-one is going to running in my ring 0 unless they pay a million or two

Re:Ring of Fire (1)

larry bagina (561269) | more than 5 years ago | (#27259321)

root's magic powers don't come from running at a different ring level, they come from the OS checking the uid/euid. VT/V work by creating a ring -1 which is where the hypervisor runs. This exploit would let a kernel module or other kernel code to jump into the hypervisor level.

Re:CD Boot (4, Interesting)

vadim_t (324782) | more than 5 years ago | (#27258681)

And you fail at understanding.

The exploit talks about modifying SMRAM. It's done with root level access on the computer. And in my understanding, the effect is not permanent, since you're changing RAM. Reboot, and it'll be gone.

Now, once it's there, the OS can't have an antivirus scan that memory area. But that's it. If this thing persists across reboots, something has to put it back into the SMRAM, and you could find that something by booting a scanner from a CD, or reformatting the computer.

I don't see this as a particularly scary thing. Yes, it's nasty. But a virus could also disable antiviruses and patch the kernel to hide its presence for the same effect.

This is the same scaremongering as with the virtualization virus. Yes, it's a new way a virus can use to hide. But it's absolutely nothing new. Under DOS, viruses would trap DOS calls, and remove themselves from opened files, so that an antivirus trying to scan the file would see an uninfected one. Boot from a floppy, and none of that trickery will be active.

Re:CD Boot (2, Interesting)

Anonymous Coward | more than 5 years ago | (#27259393)

Actually, this IS new in that it's using a low-level exploit that previously wasn't known.

Also, the virus could use a commonly available BIOS utility to flash malware into the cmos.
Much, much more insidious than a traditional file-based root. Then it's there on every boot.

How exactly would you even KNOW you were infected by a BIOS-based kit? That's the question.

I take particular (if momentary) satisfaction in owning ONLY AMD based platforms.

I'm sure there will be some exploit or another for them someday, but for now... it's fanboy gravy.

Re:CD Boot (1)

I.M.O.G. (811163) | more than 5 years ago | (#27259453)

If you go thru the trouble of performing an SMM exploit you are already tailoring your attack to specific hardware. At that point, it would be silly not to also write your code to firmware so that its persistent.

So while theoretically you could find the bug by using a bootable CD and a scanning utility, that wouldn't be a likely situation in practice.

Re:CD Boot (5, Insightful)

antifoidulus (807088) | more than 5 years ago | (#27259107)

While you succeed at being snarky, you fail at being correct.

Dude, I think you came up with a new motto for slashdot!

Re:CD Boot (2, Funny)

l3ert (231568) | more than 5 years ago | (#27259153)

I'll reserve my judgement on this until I read more from someone that owns a clue.

I assume you meant "powns a clue".

Re:CD Boot (2, Interesting)

kheldan (1460303) | more than 5 years ago | (#27259227)

There are two things that aren't clear from the article:
  1. Does this include ALL x86 chips (i.e., AMD chips) or just pure Intel chips?
  2. If the SMM firmware is in the BIOS Flash ROM, does/can malware actually overwrite your BIOS, thus making itself more-or-less permanent (save for physically removing/replacing the BIOS ROM chip)?

BTW if #2 is true, then it really is a huge threat -- and we'd all be better off going back to EPROMs and ditching the ISP flash ROMs, or at least having some sort of hardware read-only switch or jumper on motherboards limiting access to overwriting flash ROMs.

Re:CD Boot (1)

Baldrson (78598) | more than 5 years ago | (#27259237)

Its interesting that the hardware would be designed so that the firmware has no real control over itself. Where do they get these guys?

Re:CD Boot (1)

Joeyspecial (740731) | more than 5 years ago | (#27259335)

I'll reserve my judgement on this until I read more from someone that owns a clue.

I think you mean powns a clue.

Re:CD Boot (1)

InsertWittyNameHere (1438813) | more than 5 years ago | (#27258601)

From the article:

"Rutkowska and Wojtczuk claim they found a method to bypass the system-level protection, allowing them to create a rootkit that installs in the SMM space."

Does this mean that even if you boot up from a CD (or format) the malware will still be there?

Re:CD Boot (3, Informative)

vadim_t (324782) | more than 5 years ago | (#27258899)

My understanding is that "SMM space" refers to an area of memory even the OS kernel can't access, but doesn't mean it's anything that persists across reboots.

If I got it correctly, an userspace app can't write to kernel memory, and the kernel can't write to SMM memory, but it's RAM all the same, and located on the RAM modules plugged into the motherboard and not any particularly special place.

Yikes... (0)

Anonymous Coward | more than 5 years ago | (#27258281)

This is *not* good.

But more importantly... (5, Funny)

Anonymous Coward | more than 5 years ago | (#27258301)

... Joanna Rutkowska is hot [zdnet.com] !

Re:But more importantly... (1, Funny)

Ginger Unicorn (952287) | more than 5 years ago | (#27258483)

are you kidding? she looks like Q [tripod.com] ;)

Re:But more importantly... (0)

Anonymous Coward | more than 5 years ago | (#27258531)

This [totalprograms.net] is a much better picture, but yes.. she is cute.

Re:But more importantly... (5, Funny)

Anonymous Coward | more than 5 years ago | (#27258743)

This [amazonaws.com] is an even better picture. But it's not Joanna.

Re:But more importantly... (1)

dotancohen (1015143) | more than 5 years ago | (#27259233)

Is that the part right before she stabs herself in the throat with her bare hand while unbuttoning her blouse and making airplane noises? I love that trick!

Re:But more importantly... (0, Offtopic)

u38cg (607297) | more than 5 years ago | (#27258941)

I know I shouldn't, but this one is too good to pass up. Look out, it's a trap.

Re:But more importantly... (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#27259025)

By "hot" do you mean "ugly"? She looks like a d00d with the overhanging forehead, squared jaw and the butt chin.

I think some of you people haven't been outside in so long that you've degenerated into finding ANY woman attractive.

Re:But more importantly... (2, Insightful)

dotancohen (1015143) | more than 5 years ago | (#27259191)

I think some of you people haven't been outside in so long that you've degenerated into finding ANY woman attractive.

Hole and a heartbeat. It's never failed me.

Re:But more importantly... (-1, Troll)

Anonymous Coward | more than 5 years ago | (#27259229)

She's also quite possibly not a woman at all: http://seclists.org/fulldisclosure/2007/Feb/0123.html [seclists.org]

This was the subject of intense debate on her wiki entry; however, all references to it have been removed as they were deemed "potentially libelous."

I remember the last time she made the news (for Blue Pill, and all the BS that surrounded it), and the evidence as presented was fairly convincing.

Re:But more importantly... (0)

Anonymous Coward | more than 5 years ago | (#27259353)

But she has a chin like a bare bum.

Easy workaround (5, Funny)

Anonymous Coward | more than 5 years ago | (#27258305)

Run all code on a 286 or below.

Re:Easy workaround (2, Funny)

teknopurge (199509) | more than 5 years ago | (#27258871)

Your lulz make my Sparcstation weep....

Wait, what? (3, Insightful)

girlintraining (1395911) | more than 5 years ago | (#27258357)

Wait... You have to get your code running in ring 0 and then you can do anything you could do with ring 0 access? Wow. Quite an exploit. -_- And a reboot removes the code.

Re:Wait, what? (0)

Anonymous Coward | more than 5 years ago | (#27258479)

If the OS can't see or access SMM how does this get installed there in the first place?

Re:Wait, what? (3, Insightful)

girlintraining (1395911) | more than 5 years ago | (#27258607)

It might be more accurate to say the OS does not manage or provide services for the SMM. Any code executing in the OS with sufficient access rights can make "unsafe" calls to trigger SMM events, or to any other hardware device in the system. The OS only recognizes the SMM to the point of saying "If you don't finish what you're doing within N clock ticks, I'll crash", and then it syncs with the clock upon the SMM releasing control back to the OSS. If it exceeded that timeframe, the OS simply throws its hands in the air and says "Frack you." Anything loaded into the SMM would have to be very compact, and would be incidentally detectable much the same way software can detect when it is running in a VM -- by looking for delays.

Re:Wait, what? (1)

vally_manea (911530) | more than 5 years ago | (#27258563)

Yeah, but what if you are running this code in a VM? Then it's not so funny. Also from what I have read you can't really detect it, because the OS isn't aware when the CPU is running the SMM code.

Re:Wait, what? (2, Insightful)

Darth Liberus (874275) | more than 5 years ago | (#27258587)

Yeah, this reminds me of the "Windows XP's Raw Sockets will destroy the Internet!" hype.

Re:Wait, what? (3, Informative)

Molochi (555357) | more than 5 years ago | (#27258589)

The exploit allows access from Ring to SMM? Summary is confusing but I think we're talking about an exploit that can write to bios even with flashing disabled at the bios level.

Re:Wait, what? (1)

anss123 (985305) | more than 5 years ago | (#27259459)

The exploit allows access from Ring to SMM? Summary is confusing but I think we're talking about an exploit that can write to bios even with flashing disabled at the bios level.

Not really. SMM is a mode that's normally the BIOS's playground. There may be SMM code that prevents BIOS flashing which this exploit could be used to circumvent, but this exploit does not flash the BIOS.

Doesn't seem that scary (4, Informative)

vadim_t (324782) | more than 5 years ago | (#27258383)

From the PDF:

Below we describe how to exploit cache poisoning to get access to the SMRAM memory. We assume that the attacker has access to certain platform MSR registers. In practice this is equivalent to the attacker having administrator privileges on the target system, and on some systems, like e.g. Windows, also the ability to load and execute arbitrary kernel code.

If they can do that, your box is rooted already. The only difference seems to be that in this way it can hide in a place where the OS can't get at it. But IMO, if you're compromised you can't count on the compromised OS being able to remove everything malicious anyway.

Re:Doesn't seem that scary (2, Insightful)

anss123 (985305) | more than 5 years ago | (#27258653)

If they can do that, your box is rooted already. The only difference seems to be that in this way it can hide in a place where the OS can't get at it. But IMO, if you're compromised you can't count on the compromised OS being able to remove everything malicious anyway.

IOW it's like the Blue Pill rootkit except possibly harder to get rid off/detect if you get infected and no need for AMD-V/VT-x support in the CPU.

Re:Doesn't seem that scary (5, Insightful)

sjames (1099) | more than 5 years ago | (#27258719)

It's much worse, when combined with a firmware re-write, it will survive a complete re-install and cannot be detected by a security scan booted from CDROM.

Re:Doesn't seem that scary (1)

vadim_t (324782) | more than 5 years ago | (#27258805)

Well, and why would the firmware allow a rewrite?

My motherboard seems to be on the right track -- it's possible to flash the BIOS from the BIOS. So there's no need to allow write access at any other moment.

Motherboards seem to come configured to forbid flashing by default, too.

Re:Doesn't seem that scary (2, Insightful)

anss123 (985305) | more than 5 years ago | (#27258851)

It's much worse, when combined with a firmware re-write, it will survive a complete re-install and cannot be detected by a security scan booted from CDROM.

This is true even without the SMM exploit.

Re:Doesn't seem that scary (1)

sjames (1099) | more than 5 years ago | (#27259479)

The first part is, but not the second.

Re:Doesn't seem that scary (0)

Anonymous Coward | more than 5 years ago | (#27258785)

The difference here is that even if you wipe the hard drive the rootkit is STILL there.

Re:Doesn't seem that scary (2, Insightful)

vadim_t (324782) | more than 5 years ago | (#27258843)

The difference here is that even if you wipe the hard drive the rootkit is STILL there.

Where does it say that? I read the PDF, it talks about modifying RAM. RAM is cleared after a reboot.

Re:Doesn't seem that scary (0)

Anonymous Coward | more than 5 years ago | (#27258913)

If they can do that, your box is rooted already. The only difference seems to be that in this way it can hide in a place where the OS can't get at it. But IMO, if you're compromised you can't count on the compromised OS being able to remove everything malicious anyway.

A silly statement. Of course I want to be able to remove everything without throwing the chip away. Did you actually read the paper carefully? It's impossible to tell what is running in SMM and so you can never remove or know that the exploit even exists on your chip. Well, unless you want to physically look at the firmware on it with a probe.

Re:Doesn't seem that scary (0)

vadim_t (324782) | more than 5 years ago | (#27259145)

A silly statement. Of course I want to be able to remove everything without throwing the chip away. Did you actually read the paper carefully? It's impossible to tell what is running in SMM and so you can never remove or know that the exploit even exists on your chip. Well, unless you want to physically look at the firmware on it with a probe.

I read it, and my understanding is different from that of your. Here's mine:

At boot time (probably) the BIOS initializes an area of RAM for SMM purposes. This area is made inaccessible to the OS. When a SM interrupt is triggered, the CPU saves state, jumps to the SMM code, does its magic, and then continues what it was doing.

This is completely out of the OS' control, and the OS never knows when this happens, can't trigger it on its own, doesn't know what's it doing, and can't read the memory used for this. It can only hope it won't change anything under the OS that will make things break. The exploit breaks this protection and patches the code that runs in SMM.

Nowhere I see any references to that this is anything on the chip. It's simply a higher level of access, above the OS, similar to a hypervisor. Plain normal RAM is used.

The reaon for the reference to a logic probe is that you can't see this from within the OS, since it's less privileged and has no access or control over the SMM code. But that doesn't mean there's some magic area within the CPU that retains state. It's plain RAM, with access controls. And this trick described in the paper must be redone every time the box boots.

Re:Doesn't seem that scary (1)

Hatta (162192) | more than 5 years ago | (#27259395)

It's impossible to tell what is running in SMM and so you can never remove or know that the exploit even exists on your chip.

This seems like an extremely stupid design choice. I imagine Intel must have had a reason, and I hope it's a lot better than protecting their trade secrets. What possible technical reason would there be to hide anything from the OS?

Practical implications? (1)

icydog (923695) | more than 5 years ago | (#27258477)

I don't know anything about SMM, but it sounds from TFAs that the OS can't interact with SMM. If I am understanding this correctly, then what steps must occur for me to be infected? How does the exploit load itself into my machine?

Re:Practical implications? (0)

Anonymous Coward | more than 5 years ago | (#27258511)

HaX0rs could turn your PC into a bomb!

Re:Practical implications? (2, Informative)

wolf12886 (1206182) | more than 5 years ago | (#27258725)

Of course I didn't read TFA, but it doesn't sound like this exploit has shown up in any malware yet. At this point the potential for attack has just been demonstrated.

A cording to some other commenters, the exploit code must run in ring 0, so you already have to be rooted for it to work. In a nutshell, this vulnerability can't be used to infect your OS in the first place, but it can potentially make detection and removal near impossible.

Hyperbole? (2, Insightful)

anss123 (985305) | more than 5 years ago | (#27258521)

Mod this guy up.

From Wikipedia:
Joanna Rutkowska claims that, since any detection program could be fooled by the hypervisor, such a system would be "100% undetectable".

Articles about this exploit are referring to this "Blue Pill" ordeal (a Matrix reference I'm guessing) which was a rootkit using AMD-V/VT-x. Hypervisors, as they're currently exists, are not 100% undetectable and that rootkits could use AMD-V was not unexpected.

This new SMM exploit could is just an upgrade to that Blue Pill thing. Unless they manage to get into SMM from usermode I'm leaning towards "sensationalism".

Re:Hyperbole? (2, Informative)

anss123 (985305) | more than 5 years ago | (#27258573)

I'm an idiot. That was supposed to be a reply....

Time for some new Anti-virus methodologies (2, Insightful)

Well-Fed Troll (1267230) | more than 5 years ago | (#27258537)

Guess we need to start booting from CD every time we scan for viruses?

Re:Time for some new Anti-virus methodologies (0)

Anonymous Coward | more than 5 years ago | (#27258757)

That should already be standard practice.

Re:Time for some new Anti-virus methodologies (1)

GMFTatsujin (239569) | more than 5 years ago | (#27259451)

Totally. If you suspect a virus might be in place, you must consider that the entire system is compromised, including stealthiness.

The best way to be sure, if you're serious about scanning everything, is to use an operating system independent of the suspected infection.

So yeah: Boot from a CD to scan your system. Always.

Intel SMIs and SMM (0)

Anonymous Coward | more than 5 years ago | (#27258579)

Intel is extremely secretive about this kind of documentation on their processors. You barely get the bare minimum documentation when you have their Orange books.

This is probably why it took so long to discover the problem.

Intel has a number of really nasty micro-architecture bugs related to SMM as well... I wish they'd be more forthcoming about them so we can workaround them better.

Just like old times... (2, Informative)

FurtiveGlancer (1274746) | more than 5 years ago | (#27258605)

Several EE students found a similar exploit for the Motorola 68010, way back when (early 80s). Bumped the user into supervisor mode with a little register manipulation. At least Motorola sent us updated models after they fixed their undocumented stack issue.

Re:Just like old times... (2, Informative)

anss123 (985305) | more than 5 years ago | (#27259501)

Several EE students found a similar exploit for the Motorola 68010, way back when (early 80s). Bumped the user into supervisor mode with a little register manipulation. At least Motorola sent us updated models after they fixed their undocumented stack issue.

Going from usermode to supervisor mode is a far more serious exploit than going from supervisor to "hypervisor" mode.

Powned? (1)

Trouvist (958280) | more than 5 years ago | (#27258641)

I'm about to flip out and kill somebody, namely the writer of that last article. First off, if you are a journalist, "powned" shouldn't be in your vocabulary. Secondly, its "pwned."

Re:Powned? (0)

Anonymous Coward | more than 5 years ago | (#27259303)

Correcting people when they misspell words that were originally typos is an odd pastime.

welp it seems (1)

mcbain942 (806450) | more than 5 years ago | (#27258665)

all your cpu's are belong to us. She totally walks the walk at ITL of everyone doesnt already know

Let's go retro (2, Funny)

AlteredEgg (849856) | more than 5 years ago | (#27258691)

Wonder if this will spawn a run on Mac G5's.

Re:Let's go retro (1)

Molochi (555357) | more than 5 years ago | (#27259351)

And Athlons and pentium 4s. Woo! My closets are filled with gold!

Inexcusable (5, Interesting)

sjames (1099) | more than 5 years ago | (#27258693)

Considering that SMM exists solely to help proprietary vendors hide the "secret sauce", this is inexcusable. Every legitimate use of SMM could be accomplished by telling the OS that the memory area is reserved without hiding it away.

The most frequent use is to have a proprietary chipset device emulate a standard one without revealing the details of its operation.

Often enough, the "big secret" is that the hardware is crippled and the CPU is doing the real work. Kinda like those onboard "RAID controllers" that are just a plain old IDE interface and a poorly implemented softraid in the proprietary driver. The next step from that is to hide the softraid in SMM and have an SMI trigger whenever the OS writes to the fake registers in the PCI space.

more nonsense from the same people (4, Insightful)

YesIAmAScript (886271) | more than 5 years ago | (#27258699)

These people (I refuse to type their names) employ hype incredibly effectively.

The implications of these exploit are incredibly minimal. They might help a rootkit hide a little better, but they don't make it any easier to install one.

If you have malicious code running in ring 0, you're already so boned, you really need to dust off and nuke the machine from orbit anyway. And if you have malicious code that modified your BIOS (as some people list as a nightmare scenario), you again already have problems so large a little bit of SMM trouble means little additional pain.

They've found a way to infect the processor itself (0)

Anonymous Coward | more than 5 years ago | (#27258741)

Geez! What's this world coming to? These malacious programmers have found a way to create a trojan that gets into the small amount of SMM memory inside the processor and execute?? That's insane! So, now viruses can tell the KERNEL what to do!

This could create an awesome anti-virus app too! (1)

rrossman2 (844318) | more than 5 years ago | (#27258775)

Anyone in the know I'm sure wouldn't trust many, if any, anti-virus/malware companies from utilizing a tool like this... but imagine how it could potentially help the anti-virus companies. Rootkits, worms, etc wouldn't be able to disable the anti-virus software, as it wouldn't be able to detect it's even running, let alone try to shut down the anti-virus software. Plus, it would make hiding malware, worms, etc from the anti-virus software themselves!

VERY good point! (0)

Anonymous Coward | more than 5 years ago | (#27258997)

There should be some space in the processor to run "very trusted" software. This software could be self-updating anti-virus software (assuming the anti-virus company's website doesn't get hacked LOL imagine what would happen to all of our comptuers).. ok, nevermind what I just said...assume you can trust the files coming from the anti-virus site, our computers would be totally protected. Not even the operating system could touch or even detect this code. It could execute every so often (on start up?) and make sure there are no threats on ANY hard drive, USB drive, etc. It will fix any threats or warn you about threats that it couldn't take care of on its own (non-rewritable CD-ROM or DVD-ROM containing a boot sector virus)... Disk ejects on its own, system tells you never to insert it again!...THEN o/s boots!

hmmm cool idea!

Re:VERY good point! (1)

gumbi west (610122) | more than 5 years ago | (#27259281)

Yeah, so that is a great idea until the virus pwns that sector. Oh wait, this is basically what this is. The point is any resource can go to work for the other side.

Apple (1)

jlebrech (810586) | more than 5 years ago | (#27258789)

Does this mean Apples are vulnerable?

Re:Apple (2, Funny)

Anonymous Coward | more than 5 years ago | (#27259105)

Does this mean Apples are vulnerable?

No. Macs are imperious to rootkits. Now check out this super cool beta version of Safari [tinyurl.com] :

Does this mean you can take over the hypervisor? (1, Informative)

wirelessbuzzers (552513) | more than 5 years ago | (#27258883)

The obvious implication of this exploit, if SMM is truly more privileged than the hypervisor, is to escalate from root on one vm to root on other vms on the same box. That could be pretty devastating, both for hosting providers and security researchers.

On another note, I know nobody RTFA around here, but ya gotta love this quote:

Intel feels that it has a solution in SMM transfer monitor (STM). The premise is that STM places SMM in a sandbox as Intel explains further:

Lock-based synchronization has known pitfalls: using locks for fine-grain synchronization and composing code that already uses locks are both difficult and prone to deadlock. Transactional memory is proposed to simplify parallel programming by supporting âoeatomicâ and âoeisolatedâ execution of user-specified tasks.

Gotta love acronym confusion! (That second paragraph is describing Software Transactional Memory, which is totally unrelated to the proposed SMM Transfer Monitor.)

Just when I thought it was safe to upgrade.... (0)

Anonymous Coward | more than 5 years ago | (#27258919)

Darn,I was just considering upgrading my G4 Mac to an intel based Mac... Guess I'll wait a bit longer.
By the captcha is appropriate for this post... "trapped"

wide reaching, but limited exploitability (1)

v1 (525388) | more than 5 years ago | (#27259109)

So is there any way to exploit this on a mac? It doesn't look like they've actually released information on how the attack gets the foot in the door yet.

Also, things get a lot more difficult when you are running on such a low level, not interacting with the OS or even the hypervisor. (it's like the difference between coding in VB versus assembly) They talk about it phoning home and downloading nasties, but really, even being able to use the NIC card could be quite an undertaking if you're doing it "by hand" instead of using drivers and OS calls. (so you're going to code a TCP/IP stack in the SMM are you? have fun with that...) Even if they do demo a howto, actually coding something useful may take an equal level of skill as the actual exploit itself required to create. This would at least limit its application.

Imagine the poor thing getting itself all moved into the SMM and then finding out it's on a mac. Um... what now?

Re:wide reaching, but limited exploitability (0)

Anonymous Coward | more than 5 years ago | (#27259235)

It doesn't look like they've actually released information on how the attack gets the foot in the door yet.

They need Ring 0 access, then they use the MSR registers. Pointless scaremongering IOW.

Re:wide reaching, but limited exploitability (1)

Phroggy (441) | more than 5 years ago | (#27259377)

Imagine the poor thing getting itself all moved into the SMM and then finding out it's on a mac. Um... what now?

I suspect you've got that somewhat backwards. I would think once you get the code into the SMM, if it's as low-level as you suggest, it shouldn't matter whether it's a Mac or not. However, getting the code into the SMM is probably going to rely on OS features, so unless somebody writes a Mac port, it's not happening.

Re:wide reaching, but limited exploitability (1)

evilbessie (873633) | more than 5 years ago | (#27259405)

I think the point is that because this is a privaledged area it can do anything to any system it is running on. So it can add malicious code or change what is already there, because this is more privaledged than root on any system which it has compromised. Which is particularly nasty as exploits go. Not that I've read the article or anything but that was my understanding of this issue. There are things which might make this difficult to exploit in the first place, but once it is there you have no idea what it could have done.

Re:wide reaching, but limited exploitability (0)

Anonymous Coward | more than 5 years ago | (#27259429)

Imagine the poor thing getting itself all moved into the SMM and then finding out it's on a mac. Um... what now?

It potentially becomes a nearly invisible carrier, constantly re-infecting any vulnerable PCs it is connected to. That bad enough for you?

wow (0, Offtopic)

blueforce (192332) | more than 5 years ago | (#27259013)

Would you look at the brain on that chick...WOW.

ah the exploits of P1 (1)

lrohrer (147725) | more than 5 years ago | (#27259023)

This sounds way to similar to the exploit used in the book P1 -- over thirty years ago.

sigh.

Volatile memory? (1)

JoCat (1291368) | more than 5 years ago | (#27259081)

I don't see anything about this in the article or on Wikipedia:

Does SMRAM get cleared when a system is rebooted? It seems like the stuff is stored in chip cache or, worst case, battery-backed bios. Cutting the power and removing the backup battery should be able to clear it, no? It's not much of a rootkit if you can remove it by unplugging your machine.

Re:Volatile memory? (1)

JoCat (1291368) | more than 5 years ago | (#27259111)

It occurs to me only now that CMOS is battery backed, not BIOS. My mistake. Still, you can reflash a bios, right?

amd to the rescue! (1)

scharkalvin (72228) | more than 5 years ago | (#27259171)

Yet another good reason to use an AMD cpu!

Wow (4, Insightful)

quo_vadis (889902) | more than 5 years ago | (#27259247)

Very interesting loophole. For those too lazy to read TFA, basically this attack allows someone running as root (or in some cases as a local user) to run code at a level that even hypervisors cant deal with. To put this into perspective, if you are running some big iron hardware with a dozen virtualized servers. With a local privilege escalation exploit on one VM, an attacker could use this attack to take over the whole system, even the secured VMs. Worst problem is that it would be undetectable. No VM, and no hypervisor would be able to see it. Any AV call can be intercepted as the SMM has the highest priority in the system.

The solution on the other hand seems pretty simple. Make the chipset block writes to the TSEG for the SMRAM in hardware (by disabling those lines) and use some extra hardware to prevent those lines from being loaded into cache. Finally, make every bios SMRAM update contain a parity and create tools that allow SMRAM parity check.

CanSecWest security conference (-1, Offtopic)

rs232 (849320) | more than 5 years ago | (#27259341)

Pwn2Own 2009 Day 1 - Safari, Internet Explorer, and Firefox Taken Down by Four Zero-Day Exploits [tippingpoint.com]

Charlie Miller got the luck of the draw, and had the first time slot for the browser competition. His target- Safari on Mac OS X. Before I could even pull my camera out, it was over within 2 minutes- and Charlie (coincidentally also last year's first winner of the day) is now the proud owner of yet another MacBook, and $5,000 from the Zero Day Initiative.

Next up, Nils. Just Nils- you know, like "Prince" or "Madonna". With a little tweaking, he ran a sleek exploit against IE8, defying Microsoft's latest built in protection technologies- DEP (Data Execution Prevention) as well as ASLR (Address Space Layout Randomization) to take home the Sony Vaio and $5,000 from ZDI.

Summary of the exploit (1)

mkaushik (1431203) | more than 5 years ago | (#27259407)

For those who've no time or inclination to read the article:

1) The attacker should first modify system MTRR
register(s) in order to mark the region of system
memory where the SMRAM is located as
cacheable with type Write-Back (WB).

2) Attacker now generates write accesses to
physical addresses corresponding to locations
where the SMRAM is located.

3) Finally attacker needs to trigger an SMI, which
will transfer execution to the SMM code. The CPU
  will start executing the SMM code, but will be
fetching the instructions from the cache first.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...