Beta
×

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!

Hiding a Rootkit In System Management Mode

kdawson posted more than 6 years ago | from the can-you-see-me-now dept.

Security 119

Sniper223 notes a PC World article on a new kind of rootkit recently developed by researchers, which will be demoed at Black Hat in August. The rootkit runs in System Management Mode, a longtime feature of x86 architecture that allows for code to run in a locked part of memory. It is said to be harder to detect, potentially, than VM-based rootkits. The article notes that the technique is unlikely to lead to widespread expoitation: "Being divorced from the operating system makes the SMM rootkit stealthy, but it also means that hackers have to write this driver code expressly for the system they are attacking."

cancel ×

119 comments

Sorry! There are no comments related to the filter you selected.

Who thinks Hillary should drop out ? (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#23372460)

Cast your vote here.

Re:Who thinks Hillary should drop out ? (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#23372510)

Me.

Re:Who thinks Hillary should drop out ? (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#23372956)

She should stay in to continue El Rushbo's plan to self destruct the Democratic Party. 100 years in Iraq, w00t!

My BIOS has a toggle for virtualization feature (0)

Anonymous Coward | more than 6 years ago | (#23372494)

And I toggle it to disabled. Problem solved?

Re:My BIOS has a toggle for virtualization feature (5, Informative)

Anonymous Coward | more than 6 years ago | (#23372518)

Nope! This isn't using Virtualization mode.

VISTA IS SAFE! (1)

CEOBallmer (1181419) | more than 6 years ago | (#23374568)

Vista running with WGA and all of our protections is safe 66.8% of the time! That's 22% better than XP http://fakesteveballmer.blogspot.com/ [blogspot.com]

hmm (5, Funny)

extirpater (132500) | more than 6 years ago | (#23372524)

i have norton, problem solved.

Re:hmm (5, Funny)

v1 (525388) | more than 6 years ago | (#23372540)


Isn't that like using a gun to prevent a cold? Yes I suppose it's effective, but still...

Re:hmm (5, Funny)

extirpater (132500) | more than 6 years ago | (#23372584)

Isn't that like using a gun to prevent a cold? Yes I suppose it's effective, but still...
soldering gun is exactly for this

Re:hmm (1)

garett_spencley (193892) | more than 6 years ago | (#23372620)

Isn't that like using a gun to prevent a cold? Yes I suppose it's effective, but still...

Where can I buy this gun of which you speak ?

Re:hmm (0, Redundant)

DigiShaman (671371) | more than 6 years ago | (#23372814)

Isn't that like using a gun to prevent a cold? Yes I suppose it's effective, but still...

Sure, if put up to your head and pulled the trigger. I doubt that cold is still going to be an issue from there on.

Re:hmm (1)

Debug0x2a (1015001) | more than 6 years ago | (#23373470)

Isn't that like using a gun to prevent a cold? Yes I suppose it's effective, but still...
IT'S SUPER EFFECTIVE!

Re:hmm (3, Interesting)

Anonymous Coward | more than 6 years ago | (#23372596)

Strongly suggest you spend some time learning about SMM. Hnt: the OS stops running while this takes place in the background - Norton wouldn't have a clue.

Re:hmm (1)

extirpater (132500) | more than 6 years ago | (#23372606)

Strongly suggest you spend some time learning about SMM. Hnt: the OS stops running while this takes place in the background - Norton wouldn't have a clue.
Of course, i know about Science Museum of Minnesota

I'm Canadian, you insensitive clod! (2, Funny)

A nonymous Coward (7548) | more than 6 years ago | (#23373166)

Science Museum of Manitoba, eh!

Re:I'm Canadian, you insensitive clod! (1)

Nimey (114278) | more than 6 years ago | (#23373542)

Nothing there but tractors, eh?!

Re:I'm Canadian, you insensitive clod! (1)

myowntrueself (607117) | more than 6 years ago | (#23374010)

Nothing there but tractors, eh?!

And outboard motors! Eh!

Re:hmm (0)

Anonymous Coward | more than 6 years ago | (#23373448)

Norton wouldn't have a clue.
Did it ever had one?

Re:hmm (1)

nog_lorp (896553) | more than 6 years ago | (#23373660)

The rootkit has to be installed from something. Unless you get victims to boot from a CD to install your rootkit, Norton has the opportunity to catch it (not saying it will).

Re:hmm (0)

Anonymous Coward | more than 6 years ago | (#23375234)

replying to this to undo redundant mod i accidentally clicked instead if insightful.

Re:hmm (0)

Anonymous Coward | more than 6 years ago | (#23374770)

Inasmuch as Norton would otherwise have one, anyways.

Re:hmm (4, Funny)

jotok (728554) | more than 6 years ago | (#23375058)

Yes, but running Norton, he won't have any free RAM for the rootkit to be loaded into.

Re:hmm (1)

DiEx-15 (959602) | more than 6 years ago | (#23374364)

Are you sure it is "problem solved" and not "problem found"?

oooooh scary (4, Insightful)

ILuvRamen (1026668) | more than 6 years ago | (#23372560)

Oh boy, I love ridiculously overly dramatic BS! Yes it's very easy for it to hide there and for there to be basically no signs that it's there. OMG everyone run for the hills! Oh wait, malware doesn't just sit there, it does stuff. It runs threads, it reads from and writes files on the hard drive, and it has to at some point send some sort of data over the internet or local network. So yeah, no virus can hide and still cause damage and spread while remaining undetected.

Re:oooooh scary (0, Redundant)

Anonymous Coward | more than 6 years ago | (#23372636)

Oh boy, I love ridiculously overly dramatic BS! Yes it's very easy for it to hide there and for there to be basically no signs that it's there. OMG everyone run for the hills! Oh wait, malware doesn't just sit there, it does stuff. It runs threads, it reads from and writes files on the hard drive, and it has to at some point send some sort of data over the internet or local network. So yeah, no virus can hide and still cause damage and spread while remaining undetected.
Thanks for your argument stating that malware and viruses are not an important issue. Unfortunately we had to reject your submission because you are empirically wrong.

Also, nice strawman argument, but the article (or even the summary) didn't say that the malware would remain 100% undetected. It merely stated that this technique is more difficult to detect.

Re:oooooh scary (5, Informative)

Anonymous Coward | more than 6 years ago | (#23372790)

Depending on the BIOS, the chipset itself can be configured to explicitly make it impossible for the OS's kernel to even read or write the specific memory range that it being used for SMM.

The attack vector is made a lot easier because most BIOS vendors don't blockhole the address range as they need to support USB devices DMAing into the Aseg and Tseg segments (the memory ranges utilized by SMM). This is what you pay for to be able to use a USB keyboard in DOS. Legacy emulation so that all those ancient BIOS interrupt calls continue to work with your latest input devices..

If there is a modern operating system running, there is a handoff between the OHCI driver and the SMM using a mailbox register on the usb controller so that the BIOS stops using the USB controller. What this means that modulo BIOS services that do things like control fans (and aren't implemented in ACPI), something could slip into SMM quite easily and flip the bit that makes it impossible for your antivirus to find it.

Re:oooooh scary (1, Interesting)

Anonymous Coward | more than 6 years ago | (#23372848)

At last, someone who is familiar with the problem and the technology involved. Yes, SMM memory space is often locked by the BIOS and not subject to viewing by antivirus. Not that antivirus would know what code written to run in SMM looks like since it's not exactly a normal Windows or Linux binary.

Re:oooooh scary (4, Interesting)

Anonymous Coward | more than 6 years ago | (#23372916)

FWIW, an even easier vector for stuffing data into the SMM, and not as a BIOS payload (which will be very motherboard specific) is to chain it into the VGA BIOS (which most PCs have..). The VGA bios is nice because it's a very clean interface (as far as option roms go) for getting called and you can chain in the real VGA bios after doing whatever you see fit.

You can even have it trigger on the first BIOS calls of the windows bootloader so that you can easily overwrite the SMM memory regions in a nice and portable way.

Linux OK, then? (0)

Anonymous Coward | more than 6 years ago | (#23375604)

Because (and I do think that windows started doing this too) Linux uses the BIOS to boot minimally and then drops BIOS completely.

Does this either

a) stop a BIOS call being issued
b) reset the BIOS completely

I think, because the SCSI BIOS is rerun too, causing your devices to be reassigned, that it is the latter.

Re:oooooh scary (3, Insightful)

ILuvRamen (1026668) | more than 6 years ago | (#23373908)

LEARN HOW TO READ! All I said was this particular gloom and doom bullshit is overstated and shouldn't be as feared as they're making it sound. Where the hell did you get "all viruses aren't dangerous" out of that? All I'm saying is every virus can be detected. All these new "unstoppable supervirus: we're all gonna die!" articles are idiotic and wrong.

Re:oooooh scary (0)

Anonymous Coward | more than 6 years ago | (#23374648)

All these new "unstoppable supervirus: we're all gonna die!" articles are idiotic and wrong.


Yes. You're right. Everytime we see a new article about Virus X we should ignore it, because afterall, if Virus X hasn't destroyed us before, therefore it will never destory us in the future.

Listen, kid. Articles posted on slashdot are for the benefit of all readers. The problems posed by this article are interesting and (potentially) dangerous. I have full faith that all the problems raised will eventually be dealt with.

Someone (not you) will come up with a solution to the problem. Just because you don't care about the problem or the algorithm to deal with its solution doesn't mean it isn't an interesting topic of discussion.

Re:oooooh scary (2, Funny)

j00r0m4nc3r (959816) | more than 6 years ago | (#23374930)

All these new "unstoppable supervirus: we're all gonna die!" articles are idiotic and wrong.

That's exactly what the unstoppable supervirus wants you to think!

Re:oooooh scary (0)

Anonymous Coward | more than 6 years ago | (#23372980)

all it has to do is store some cp there, and drop a line to interpol.

Re:oooooh scary (0)

Anonymous Coward | more than 6 years ago | (#23374592)

Oh boy, I love ridiculously overly dramatic BS! Yes it's very easy for it to hide there and for there to be basically no signs that it's there. OMG everyone run for the hills! Oh wait, malware doesn't just sit there, it does stuff. It runs threads, it reads from and writes files on the hard drive, and it has to at some point send some sort of data over the internet or local network. So yeah, no virus can hide and still cause damage and spread while remaining undetected.


The previous statement is currently rated +5 informative.

That means that of all informative statements posted in the ten years of slashdot's existence, this message rates amount the highest.

Would anyone like to justify that moderation? Please?

Is straw-man arguing now an automatic key to karma?

LiveCD (2, Interesting)

Anonymous Coward | more than 6 years ago | (#23372568)

With all the security issues that we hear so much about, I have decided that one potential way of avoiding most of them is to run a liveCD distro of whatever OS when working with sensitive data.
I do all my internet banking via freeBSIE now - yes it takes a veeeeery long time to boot, and I know that it doesn't solve ALL of the problems but it has to eliminate enouogh problems to be a viable solution.
Agree / disagree ?

Re:LiveCD (5, Informative)

Anonymous Coward | more than 6 years ago | (#23372658)

If the code runs in SMM and is launched from the BIOS a live CD doesn't avoid the problem.

Re:LiveCD (1)

harry666t (1062422) | more than 6 years ago | (#23375386)

Then we'd need a live BIOS :)

Re:LiveCD (1)

A nonymous Coward (7548) | more than 6 years ago | (#23373194)

At some point you have to write a new LiveCD, yes? Or perhaps you have passwords too complicated and numerous to remember, and need to write them to an encrypted USB stick?

It seems to me that there are still opportunities to get infected. On the other hand, you have reduced the danger space, so that's good.

Re:LiveCD (0)

Anonymous Coward | more than 6 years ago | (#23373382)

Hmmm, good point.
And another thing, if you are going to download ANY binary / ISO image, surely the risk remains that that particular image is corrupted. Unless you manually download the source files, check through each line, test, test and test again, and then compile it yourself, with your own home made compiler, you can never be sure of its integrity. I mean a site might offer an md5 checksum but who is to say that we should trust that site.
I mean how far do we wanna take it?
As some point we are going to have to just close our eyes and jump right? And hope for the best.
I'm sure that even Theo himself doesn't take apart the chipset of EVERY piece of hardware he employs and run scans and tests against it. at some point we all excersize TRUST, it's just at different levels of comfort.
We live in a connected world and as such should all follow some simple rules.

Use difficult passowords
Change passwords regularly
Never use a public terminal for sensitive computing
Don't install software from unknown providers on a computer that you plan to do banking on
Always check certificates
Keep your system updated
Use security software
Don't answer unsolicited emails
Don't engage ANY bank emails or other financial institutions that require your user details
And I guess STAY INFORMED.

There's a lot more but this is what I do - and I use a liveCD for banking.

I know that it is not fool proof but I am tryng to do due dilligence and decrease my chances of being hit.

Re:LiveCD (1)

CastrTroy (595695) | more than 6 years ago | (#23373476)

Would booting from an SD card with the write protect on be any faster? I know that not all computers support booting from USB devices, but for those that do, it should be much quicker than booting from a CD.

Re:LiveCD (3, Insightful)

Technician (215283) | more than 6 years ago | (#23374386)

and I know that it doesn't solve ALL of the problems but it has to eliminate enouogh problems to be a viable solution.

It's time to look at the Intel vPro tm. tech that enables this. Look for demo videos online. The level in the BIOS enables remote powering up machines to push OS updates, remote booting repairing crashed/unbootable Windows machines, etc. This protected level of stuff is beyond the OS and even the power switch. IF it can remote boot an unbootable corrupt Windows partition, write fixes to it and boot it up, there just isn't much that a Live CD can hide. You best bet is to use your own known hardware. Turn off the remote management stuff unless your employer is using it. If the employer is using it, their top level management should be able to detect alterations to the protected area.

Re:LiveCD (1)

couchslug (175151) | more than 6 years ago | (#23376372)

"yes it takes a veeeeery long time to boot"

A fast CD drive helps, as do light live distros. I find Damn Small Linux boots very quickly.

You might also boot an ISO image from a flash drive or CF card that is write-protected and/or has no persistent home directory. Google for LOTS of info on doing this. I don't find live CD boot times to be very long on modern PCs, even with full distros like Knoppix.

Ekoparty (1)

cachimaster (127194) | more than 6 years ago | (#23372572)

Interesting, but I heard of this technique at the Ekoparty 2007 conference (link [ekoparty.com.ar] ), in a talk given by Rodrigo Rubira Branco (BSDaemon), so is nothing new in the security field. Except if there is a working proof of concept this time.

Difficult in practice (5, Interesting)

Anonymous Coward | more than 6 years ago | (#23372594)

In theory, SMM is the ultimate rootkit hiding place. In practice, it's difficult to exploit on a wide scale. Getting the system to execute rootkit code in SMM isn't easy. You're going to need an exploitable BIOS bug, or the ability to reflash the ROM. Either is going to be very system-specific.

Re:Difficult in practice (3, Funny)

garett_spencley (193892) | more than 6 years ago | (#23372650)

"You're going to need an exploitable BIOS bug, or the ability to reflash the ROM. Either is going to be very system-specific."

Exactly. Windows was written to solve this very problem. All this talk about hiding root kits in SMM is one giant leap backwards.

Re:Difficult in practice (0)

Anonymous Coward | more than 6 years ago | (#23372844)

"You're going to need an exploitable BIOS bug, or the ability to reflash the ROM. Either is going to be very system-specific."

Exactly. Windows was written to solve this very problem. All this talk about hiding root kits in SMM is one giant leap backwards.
Wow, not sure if you intended to make a pun but its true - Windows does solve this very problem. Writing low level exploits is difficult and not very portable, Windows simplifies and virtualizes the process nicely. So much crap running, mostly undocumented, not too hard to sneak something in the average user would never notice. Before ya'll crow about anti-virii, they can be hacked as well. Tracked down an infestation once that was coming from the AV tools ... vendor said, oh yeah, that happens, reload with theese patches. Nice investment!

Re:Difficult in practice (4, Interesting)

moteyalpha (1228680) | more than 6 years ago | (#23372688)

This is one area where I have worked a bit and there is tremendous potential for abuse of VMM and SMM when you combine it with users that trust a company to deliver binaries. I will not use a binary program, unless I have the source and can verify it is legitimate. A bit of social engineering and the right picture and an uninformed user will be flashing their BIOS while they wait for the security update they think they are getting. If it is done right, this type of program can remain dormant and use no CPU time to give itself away, until it is keyed to act in something like a bot net or some other purpose.

Re:Difficult in practice (1)

emmafreester (1287644) | more than 6 years ago | (#23372768)

As someone who doesn't know that much necessarily about the capabilities of this type of exploit, I still have several questions after reading the article. 1. While this rootkit may very well be something that you can't see while inactive, would you be able to see it with some of the Sysinternals suite of programs (e.g. regmon, procmon, filemon) while running? 2. If someone is tricked into flashing their ROM, is there any way of getting rid of it other than a new computer/new hardware? 3. Is there ANY possibility of blocking it, even if you can't remove it?

Re:Difficult in practice (0)

Anonymous Coward | more than 6 years ago | (#23372850)

sysinternals tools wouldn't see anything in SMM. SMM is a 'hidden' mode of the processor for firmware developers to perform actions behind the scenes of the OS. There is _no standard_ way to communicate with SMM in a traditional bios.

Effectively, when CPUs enter SMM (either from an interrupt from the southbridge, or by explicit interrupt sending through the Local APIC), they all bounce into SMM together and run there. All CPUs all leave SMM together as well. The only side effect seen by the operating system is a little bit of time just seemed to disappear.. (typically less than a ms).

Re:Difficult in practice (1)

rts008 (812749) | more than 6 years ago | (#23373760)

I don't know much either, but will chip in what I do know.

1. probably no unless whatever malware was loaded is actually Doing Something actively. Otherwise it is just kind of idling in a 'protected' (from OS) space of RAM

2. really not trying to be a pedantic jerk, but ROM cannot be flashed (Read Only Memory), did you mean EPROM? (which IS flashable)

Also sometimes EPROM's can be reflahed to OEM state, sometimes they can be trashed by a faulty/malicious flash-depends (YMMV)

3. I'm not sure, but as per #2 above, reflashing your BIOS EPROM, you may get back to a 'clean' state, or could send the motherboard back to the mfr. to have the BIOS chips replaced- probably just as easy/cheap to replace the motherboard. (again- YMMV)

From TFA, and some of the above seemingly knowledgeable posts above, this looks like something that is running 'between' the mobo/BIOS and the OS, so unless it started Doing Something that the OS would notice, then nothing in #1 (tools) you mentioned would have a clue.

Please take this all with a grain of salt, and if have given you bum info, I apologize, but it seemed no one else was bothering to answer you.
I would be glad to be corrected (for both of us) if I am wrong here.

Sorry, best I can do for you.

Re:Difficult in practice (0)

Anonymous Coward | more than 6 years ago | (#23373990)

Pretty much hit it right on the head. Most of the firmware in a machine is flashable on EPROMs so yes EPROMs. SMM doesn't run between BIOS and OS exactly, it sort of runs alongside. When an SMM event occurs the OS is sort of set aside for a cycle or so while the SMM event is handled, then the OS is back in control. The memory space that SMM uses is locked and hidden away from the OS and the code isn't a standard binary that any AV would recognize anyway. This is going to be the realm of BIOS programming I'd expect.

Really, setting this up to do something malicious is a pretty tough deal. These guys might have something nasty but I doubt they could put it on another piece of hardware - it's going to be pretty targeted. This is pretty arcane stuff and not well documented either. It'll be an interesting talk and I'll be there to ask questions but this isn't a threat I'd lose sleep over.

Re:Difficult in practice (1)

srw (38421) | more than 6 years ago | (#23374024)

Really not trying to be a pedantic jerk, but you misspelt EEPROM every time. (EPROMs were erased with UV light. EEPROMs are "Electrically Erasable")

Re:Difficult in practice (1)

rts008 (812749) | more than 6 years ago | (#23374062)

Thanks for the correction.
You are correct, it's been a few years since I have had to deal with the different types of chips.
I was just trying to help the guy out.

Re:Difficult in practice (1)

Majik Sheff (930627) | more than 6 years ago | (#23374950)

Really not trying to be a pedantic jerk, but EEPROM and flash are distinct technologies. You used the terms interchangeably.

Please mods, this was an attempt at humor (piling on). Maybe with your help I can be rehabilitated. In the mean time, I've never seen a +5 redundant. BRING ON THE UNDERRATED POINTS!

Re:Difficult in practice (1)

node 3 (115640) | more than 6 years ago | (#23374842)

really not trying to be a pedantic jerk, but ROM cannot be flashed (Read Only Memory), did you mean EPROM?
Not to be a pedantic jerk, but EPROM is a type of ROM.

Re:Difficult in practice (1)

maxume (22995) | more than 6 years ago | (#23372774)

Is the stuff you do on every single system you use really that important?

I can see being very careful with systems that are used for a wide range of tasks, but the desktop machine with nightly backups that you use to draft documents doesn't seem like it is going to be so important that you need to inspect all binaries. Most people use computers for stuff that is even less important than that.

Re:Difficult in practice (0)

Anonymous Coward | more than 6 years ago | (#23373140)

Is the stuff you do on every single system you use really that important?

I can see being very careful with systems that are used for a wide range of tasks, but the desktop machine with nightly backups that you use to draft documents doesn't seem like it is going to be so important that you need to inspect all binaries. Most people use computers for stuff that is even less important than that.
You work in Microsoft product management by any chance?

Re:Difficult in practice (1)

AnomalyConcept (656699) | more than 6 years ago | (#23372694)

What about environments which have the same hardware build deployed, such as corporate/enterprise networks?

Re:Difficult in practice (3, Informative)

Anonymous Coward | more than 6 years ago | (#23373368)

[quote]or the ability to reflash the ROM. Either is going to be very system-specific.[/quote]
Manipulating the ROM image is trivial. It basically consists of the emergency boot block, a small LHARC decompressor, and a mini filesystem (basically a linked list) containing some modules of position-independent code in LHARC archives. If you want to add a module, simply compress it, read out the existing image, append your achive to the list, and write the result back. People have been doing this so often, f.e. for adding the PXE boot rom from the LinuxBIOS project without fully replacing the BIOS.

Flashing itself is also pretty easy. Take a look at UniFlash, which is a FOSS program written in Pascal that supports virtually every existing flash chip. The procedure is pretty much always the same and very simple. It allows allows for flashing PCE/AGP/PCIe expansion ROMs.

(You will also find some very interesting details. F.e. on some chips, apparently the hardware flash protection switch can be overridden by a software flag, rendering it absolutely useless.)

So please stop spreading the myth that BIOS rootkits would be hard or unstable. It's really just that seemingly no-one ever bothered to write a proof-of-concept, since the concept really is too trivial.

Re:Difficult in practice (1)

rts008 (812749) | more than 6 years ago | (#23373800)

Okay, I'm a little confused here. I did not think that a ROM could be flashed, only an EPROM could.
Has something changed, or is the term ROM now commonly used for all embedded chips?

Really not trying to be a pedant, just want to know.
If this is a case of 'not confusing the proles', then okay- sometimes it is easier to 'go with the flow' instead of being bogged down in technospeak, but I'm really starting to doubt my education and (slim) knowledge here.

Re:Difficult in practice (0)

Anonymous Coward | more than 6 years ago | (#23374130)

Well, from a legitimate software's perspective, it is a ROM. That is, by default it acts like a ROM, though in some special mode its content can be changed. May this special mode be a usage of UV light (PROM, EPROM), a higher voltage (EEPROM), or simply a bunch of special configuration registers (Flash ROM or NVRAM).

Re:Difficult in practice (2, Informative)

node 3 (115640) | more than 6 years ago | (#23374908)

is the term ROM now commonly used for all embedded chips?
Erasable, programmable, read-only memory chips, aka EPROMs, are a type of read-only memory chip, aka ROMs.

As are EEPROMs, which is the specific type of ROM we are talking about here (electronically erasable, programmable, read-only memory), since they don't require a UV light to erase the chips.

To further confuse things, flash memory (such as SD cards, USB flash drives, internal memory for iPods, cameras, phones, as well as SSD drives) are actually a type of EEPROM, even though they aren't strictly read-only in the sense most people would think. ROM actually refers to the memory being non-volatile and not to it being non-writable.

Re:Difficult in practice - is it? (0)

Anonymous Coward | more than 6 years ago | (#23375650)

What scares me, is this, in regards to what YOU stated, here:

"You're going to need an exploitable BIOS bug, or the ability to reflash the ROM" - by Anonymous Coward on Sunday May 11, @09:47PM
I've thought about that for years now, + mentioned in discussions just like this one on various forums I have attended over time

HERE is how I would go about it (not that I would), thru this combination of fairly easily done techniques, which I have used before in programs, & list an example below? It's PROBABLY do that!

(In a "blended threat" type of virus/trojan/rootkit/spyware etc.? DOABLE!)

For example, tools by ASUS &/or GIGABYTE (& probably other vendors) allow BIOS FLASH thru Windows (& probably for LINUX too by now, but you LINUX folks tell us more on that note)...

So, that said & aside?

What says a Virus/Trojan/Spyware/Malware-in-general can't use that tech too?

I.E.-> It's NOT THAT HARD to store ANYKIND of file (including BIOS image data, OR another program, say in the case of malware? A driver) or data inside an application as a runtime extractable + even memory resident (instead of disk) resource, & run a program over it + use it from memory even...

E.G.-> I do it inside this app (stores an .avi internally & plays it back, from INSIDE of the .scr file no less, making it "1 moving part only" basically):

----

APK Doctor Who ScreenSaver 2008++ v. 1.0

http://www.drwhodaily.com/community/index.php?s=4c91394a4eeba63a7acde25e70dbbe64&showtopic=386 [drwhodaily.com]

----

AND - the same basic idea & technique could be done via a virus, albeit for nefarious purposes!

Simply by using what's noted above, for flashing a PROM whose data it stores internally (BIOS IMAGE FILE + possibly a PnP loadable driver) & probably via the use of a driver stored internally as well as a runtime extractable & useable (Plug & Play dynamically loaded drivers DO exist on Windows, not sure on Linux though) as well!

& voila: FLASHED BIOSES FROM A VIRUS!

Think about it...

(The code's out there for BIOS flashing WHILE IN WINDOWS no less, in legit tools so far @ least afaik ONLY!)

BUT, I saw code for that @ ROOTKIT.COM no less, but I can see it being hardware specific (BIOS specific actually in this case, bios flashing viruses etc.) - still, doesn't make it "undoable" though. Far from it...

& the technique I extoll of storing even BIOS IMAGE DATA (or other programs, even drivers & use them) inside of any program (virus/trojan/rootkit/spyware etc. et al) is not difficult to do @ all, because of resource storage programs use...

APK

There could be something to this (3, Interesting)

lakeland (218447) | more than 6 years ago | (#23372664)

Lets say you are an evil terrorist hell-bent on infultrating the American military and wrecking havoc.

It seems to me that this would be exactly the sort of thing you'd look for. Military machines are specced very precisely, you'd know exactly what hardware was on the system so drivers wouldn't be much of an issue.

All you'd have to do is sneak your code in here once, and the timebomb would be ticking for when you want to activate it. Yeah, it wouldn't be easy to get it on there, but it means breaking through once allows you to lay a trap for another time. That sounds pretty serious to me.

Re:There could be something to this (2, Interesting)

PhireN (916388) | more than 6 years ago | (#23372992)

Its true, I worked in a company involved in air traffic control over the summer, And the computers which they had to use were old Compaq servers from 1998, of a certain model, with exactly x ram.
They were using eBay to track down replacements.

Re:There could be something to this (1)

geekgirlandrea (1148779) | more than 6 years ago | (#23373044)

Lets say you are an evil terrorist hell-bent on infultrating the American military and wrecking havoc.

I think this would, in fact, make you not evil, but very very good.

Re:There could be something to this (0)

Anonymous Coward | more than 6 years ago | (#23373352)

in b4 shitstorm

Re:There could be something to this (1)

gandhi_2 (1108023) | more than 6 years ago | (#23373714)

Right, cause when the North Koreans, Russians, Chinese, et al. came in to "save you" from the "evil US military" your freedoms would finally be secure for all time.

Those countries always bring liberty, equality, and cell-phone coverage to all they conquer.

Re:There could be something to this (1)

flyingfsck (986395) | more than 6 years ago | (#23373748)

Sure, you are not paranoid if they really are out to get you. Now you just need to figure out how to bridge an air gapped network and then you are all set.

Re:There could be something to this (1)

lakeland (218447) | more than 6 years ago | (#23374980)

Well yes, you do. I never claimed this was anything more than a privilege escalation bug.

The point is that if you were planning some attack, you would want to co-ordinate a computer system failure with the rest of the attack. You have militants willing to die while making an attack, and you have the ability to screw up an important computer for a short period of time. If you can't co-ordinate them then all you get from both is a bit of annoyance and fear. Co-ordinate them and you get an attack at the same time the computer security malfunctions.

I'm glossing over the detail of how you get this code to run on the system once. I realise that wouldn't be easy but I wouldn't want to rule it out as impossible. Would you bet your country's future that a gun-to-the-head of somebody's daughter type technique wouldn't work?

As you note, this is only a concern if you are trying to keep out a highly organised and well resourced enemy. I'm not about to set up anything like this for my home server.

IPMI Card Vulnerabilities (4, Interesting)

landonf (905751) | more than 6 years ago | (#23372744)

What about vulnerabilities in onboard IPMI [wikipedia.org] cards? Our new servers have ARM-based cards running Linux. The built-in HTTP server is vulnerable to a widely-known buffer overflow:

landonf@ahost:~> telnet XXX.XXX.XXX.XXX 80
Trying XXX.XXX.XXX.XXX...
Connected to XXX.XXX.XXX.XXX.
Escape character is '^]'.
GET /x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/ HTTP/1.0
Connection closed by foreign host.
landonf@timor:~> telnet XXX.XXX.XXX.XXX 80
Trying XXX.XXX.XXX.XXX...
telnet: connect to address XXX.XXX.XXX.XXX: Connection refused

Seems like a recipe for compromised data centers, to me. Re-imaging a machine won't touch the IPMI card.

Re:IPMI Card Vulnerabilities (3, Insightful)

netcrusher88 (743318) | more than 6 years ago | (#23375530)

Yes, but presumably you don't let the entire world get on your DC network. If only trusted people access vulnerable systems, the vulnerabilities are less significant. Yes they're still there, and yes there's still a risk, but what would the cost be of replacing or reprogramming all the IPMI cards? Security is all about risk/reward, except with a few more variables. If your demonstrable risk is minimal, the reward to reduce or eliminate it will also be minimal. If the cost outweighs the benefit, it's just bad business. Even if it is a good idea.

Looks like an argument for openness to me... (3, Insightful)

fuzzyfuzzyfungus (1223518) | more than 6 years ago | (#23372784)

Obviously I don't like hearing about nasty, or potentially nasty, vulnerabilities in common systems; but these sorts of situations do seem like an argument for more openness in computer systems, right down to the dark, embedded corners. Particularly with these dark, embedded, corners taking on more and more functions. If you can pull stuff like this with the BIOS, I hate to think what a full EFI setup could be doing(particularly if the OEM enthusiasm for shittastic bundleware reaches that level of the system). Time and again, we see that we cannot trust what we cannot verify.

Re:Looks like an argument for openness to me... (2, Insightful)

cdrguru (88047) | more than 6 years ago | (#23373246)

The problem is, you would like to turn the "personal computer" into a something that needs attention and continual review and updating. What 99% of the world wants is an email appliance that they can download the latest neat stuff on. We need to move to more of an appliance that needs less, not more administration.

The second problem is that there is no "administrator", at least no qualified one for most of the home computers in the world. Windows needs some administration, arguably more administration than it gets. Linux can't operate without administration although it can be less frequent but requires more knowledge.

Re:Looks like an argument for openness to me... (0)

Anonymous Coward | more than 6 years ago | (#23373474)

Isn't that like justifying totalitarian secret government with the argument that people are too stupid understand what they want and vote?

Maybe you feel superior to "99% of the world"?

Re:Looks like an argument for openness to me... (1)

node 3 (115640) | more than 6 years ago | (#23374952)

Isn't that like justifying totalitarian secret government with the argument that people are too stupid understand what they want and vote?
Yes, but only if you equate your computer, which has no (or, very, very limited) power to force its will upon you, with a government, which can take your wealth, liberty, and even your life.

Re:Looks like an argument for openness to me... (0)

Anonymous Coward | more than 6 years ago | (#23375468)

Sadly, we might be slowly approaching an era when the computers and the web might be the most important parts of our lives.

Re:Looks like an argument for openness to me... (1)

fuzzyfuzzyfungus (1223518) | more than 6 years ago | (#23376044)

cdrguru is correct in noting that a setup requiring significant amounts of admin per system just isn't going to happen. Even admins have limited time and patience.

That said, the continuum from appliance to fully customized system is, while not orthogonal to it, distinct from the continuum between fully closed and fully open systems.
Take the Free Telephony Project [rowetel.com] as an example. Their product is a little embedded Astrix PBX in a box. Plug it in, it works. Such a device can easily qualify as an appliance. It is, however, a fully open, fully hackable system. You don't have to poke at it; but if you want to, you can.
The OLPC is another decent example. Not quite as open as the Free Telephony Project's hardware(firmware blob in the wifi controller, and I'm not sure how the hardware schematics are licenced); but it is also appliance-like in operation, designed for easy use by young possibly illiterate children without computing experience, while being fully modifiable by somebody with appropriate interest and skill.

It is also possible for systems to be open, at least in limited contexts, without being Free. Customers with specific needs, and sufficient clout, can sometimes obtain access to vendor code or designs and at least test and monitor the product, even if they have no other rights. I suspect we'll see a lot of this in the future, from proprietary entities that don't want to loosen their grip; but do want to keep large security conscious customers(take the story about Cisco gear in federal facilities that ran a little while ago).

Neither news or an issue (2, Informative)

Anonymous Coward | more than 6 years ago | (#23372792)

This has already been discussed about two years ago. Basically you can't carry it out because every chipset blocks write access to this memory part by doing a complete remapping of the memory layout in hardware. Together with a very short list of mainboards where the developers forget to set up the necessary flags through the BIOS code.

Re:Neither news or an issue (2, Informative)

DigitAl56K (805623) | more than 6 years ago | (#23372856)

Basically you can't carry it out because every chipset blocks write access to this memory part by doing a complete remapping of the memory layout in hardware.
But TFA says someone has carried it out and will demo it in August.

Re:Neither news or an issue (1, Informative)

Anonymous Coward | more than 6 years ago | (#23373254)

The real FA behind PC World's article explicitly stated that they had to reflash the BIOS to carry out the attack. This is why it would be detected (take out the BIOS chip and compare it to a safe one, or check out the chipset-specific flags if the protection is really enabled), or even be impossible (yes, quite some mainboards today still have a hardware flash protection flash, and the chips where this flag could be overridden in software aren't produced any longer).

At any rate, there are many alternatives. On AMD processors you could load a microcode update (Intel CPUs verify those with a digital signature, but AMD doesn't) to manipulate the effects of machine instruction. On any machine, you could install a hook on the Page Table Handler which then marks its own pages as NoRead, NoWrite, Execute while exposing to the rest of the system as Invalid page (this is what the Shadow Walker rootkit mentioned in TFA does). Or virtualization (which means you would at most detect the presence of a virtual machine monitor, which couldn't be differed from an installed legitimate one). I'm pretty sure BluePill can be made nearly impossible to detect if it simply occupied exactly half of the TLB cache (even though it needs less), hooked CPUID to report only half of the TLB cache size, reported the CPU model as one which typically has such a TLB cache size, and hook all instruction that supposedly don't exist on this older CPU model but are present on the actual one. Some people mentioned hiding in PCI/AGP/PCIe cards expansion ROM, or reflashing a harddisk's or DVD driver's firmware to inject code into binaries read from it.

I guess all this leads to way to an obvious conclusion: Damn secure your system that even if your usert account is compromised, there's no reasonable way to escalate privilege to root or kernel rights.

Re:Neither news or an issue (0)

Anonymous Coward | more than 6 years ago | (#23373598)

This is why it would be detected (take out the BIOS chip and compare it to a safe one, or check out the chipset-specific flags if the protection is really enabled)

And norton would do that for me after the computer reboots itself yet again for whatever reason?

Re:Neither news or an issue (0)

Anonymous Coward | more than 6 years ago | (#23373834)

Hm? Norton is a well-known scamware from a scam company (which has only become very rich through selling their scamware, but never had any actual qualifications) which guarantees that there are privilege escalation vulnerabilities in your system. Heck, they didn't ever bother patching a trivial buffer overflow in their HTTP parser, which has been reported three years ago - and is still unfixed.

No, I already mentioned one part of the real solution: Make sure that malware nevers gets root/kernel privileges in first place. Do as much as possible in unprivileged context, and possibly use a VM for testing privileged stuff or for preparing privilege-demanding software for running unprivileged.

The second thing is to contact your mainboard manual to check out whether the D_LCK bit is already set by default. If not, contact the vendor and ask them if they BIOS sets the bit. If not, ask him for an update. Even if you don't get that, you could trivially write a boot-time driver that sets the bit, so subsequent access to the SMI handler is denied.

Re:Neither news or an issue (0)

Anonymous Coward | more than 6 years ago | (#23373238)

If you're launching FROM the BIOS then I'd assume this isn't an issue.

Not really an issue on recent hardware (4, Informative)

mjg59 (864833) | more than 6 years ago | (#23372862)

In system management mode, the processor runs code from memory (SMRAM) that can't be seen by the operating system. The usual way of handling this is to map the SMM memory into the address space at 0xa0000 - that is, where the legacy graphics framebuffer is. Normal accesses to this address space are redirected to the graphics card by the northbridge. In SMM, accesses to this address space are diverted to real memory and the magic code is run.

Obviously, it has to be possible for the BIOS to put code their in the first place. There's a configuration flag in the northbridge (on recent Intel chipsets, it's byte 0x9d of the PCI configuration space on the host bridge) that controls whether accesses are directed to the graphics hardware or physical memory. The BIOS can set that to do the initial setup. Once it's done that, the bit is flipped and normal code can no longer see the SMM code. The vulnerability lies in the fact that OS code could reset that bit, gain access to the SMRAM and modify it. Any BIOS I've seen from the past couple of years has gone a step further and set an additional bit that prevents this from occuring. Once that bit is set, the only way for normal code to gain access to the SMRAM region is for the machine to be reset. This happens before any OS code gets run, so there's no opportunity to install hostile SMM handlers.

Is it still possible to exploit? Yes. If the attacker can modify your BIOS they can modify the code that it copies into SMRAM. However, if the attacker can modify your BIOS then they've already won even without using SMM. The initial bootloader uses BIOS calls to read data off disk, so a sufficiently intelligent attack could rewrite that in order to boot a modified kernel. In versions of Windows before Vista, most graphics drivers still made BIOS calls. A modified BIOS could do anything it wanted to with those without looking suspicious in the slightest. Like the article says, it's unlikely that this'll be common. But to be honest, I don't see it happening in the real world at all.

(Today I have been trying to work out just WTF a Dell laptop does when it enters system management mode in response to a brightness hotkey press. The locking down of SMRAM makes this effectively impossible)

Re:Not really an issue on recent hardware (0)

Anonymous Coward | more than 6 years ago | (#23373500)

Most laptops use SMM to handle special keyboard events, such as brighness adjustments, video output switch and the like The embedded controller [the keyboard controller] raises SMI and BIOS takes over and tells the video hardware what to do.

Re:Not really an issue on recent hardware (1)

mjg59 (864833) | more than 6 years ago | (#23373552)

Yes. The fact that the SMRAM is locked from the OS doesn't matter - it's still accessible when the CPU's in system management mode. Since (in the absence of ridiculous BIOS bugs) there's no way to get a CPU in SMM to execute arbitrary code or rewrite arbitrary sections of the SMRAM, this isn't an issue.

Invisible to anti-virus? (2, Insightful)

DigitAl56K (805623) | more than 6 years ago | (#23372874)

The problem with the "invisible to antivirus" argument is that it assumes the system is pre-infected. To root a remote system you need to get the code onto the system and execute the software that puts it in SMM, and during that process any anti-virus is able to inspect it. The question is will the anti-virus heuristics or signature-based methods actually catch it?

How specific of a target? (4, Interesting)

rocketPack (1255456) | more than 6 years ago | (#23372878)

TFS says the code must be specifically targeted to a particular machine which, on a PC, means a very big challenge.

On a Mac, however, you could easily target a very large number of people using only a very small number of hardware variations. Could this exploit be better suited to Macs than PCs? On the other hand, it also seems like it would be equally easier to detect the problem, since your algorithm can be fairly specific (both in terms of Macs and PCs), since the code needed to exploit would be rather specific.

Re:How specific of a target? (1)

Kevinv (21462) | more than 6 years ago | (#23374090)

Not really.

a) Mac's have something like 1-4% market share (including the PowerPC models which may not even have this mode), all you have to do is find a processor with greater than 1-4% market share in the windows and target that.

b) These are rootkits running outside of the OS, so you wouldn't target a particular OS, you target a chip (or perhaps a chipset?). You'd want the most popular ones running. Could be a chip in Mac and Windows would be most popular. Article doesn't mention how much the OS is needed to install the exploit. If it's significant you may have to stick with targeting just Windows machines just because there are so many more of those machines around.

Re:How specific of a target? (1)

rocketPack (1255456) | more than 6 years ago | (#23374726)

I realize it's not targeting the OS, but it just so happens that (until very recently) all computers running Mac OS have a fixed hardware base, unlike PCs. I thought I made this fundamental concept pretty clear.

My point here is that even if Macs don't own the market, there is frequently at at least one in every major corporate/government network. Since they can be positively identified, and their hardware possibilities narrowed down to a tiny fraction of those for the PC market, it would be a logical entry point from which to leverage a large scale attack if you knew you could get a high level backdoor installed.

Does this clear it up for you?

Re:How specific of a target? (1)

jimicus (737525) | more than 6 years ago | (#23375552)

TFS says the code must be specifically targeted to a particular machine which, on a PC, means a very big challenge.

Regardless of this, it's still a pretty big challenge. It's well out of script-kiddie land and into "determined hacker" territory - and I can't imagine anyone would take it on unless the target was really worth it. Think large bank or governmental organisation.

Thing is, though, large banks and governmental organisations buy hundreds, if not thousands of identical PCs at a time - and they're likely to be based on relatively conservative hardware, rather than "latest and greatest gaming rig" stuff. Finding out what type of PC to target and obtaining one for your own development purposes would probably be relatively easy. Then all you've got to do is socially engineer the software onto a target PC.

Re:How specific of a target? (1)

el_chupanegre (1052384) | more than 6 years ago | (#23375662)

Doesn't the fact that the Mac uses EFI instead of BIOS make this irrelevant? You need to mess with the BIOS to get this to work.

ma83 (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#23373188)

rival distribution, not anymore. It's Hot on the heels of learn what mistakes faster chip architecture. My Something that you everyday...Redefine And Michael Smith If you answered

Hardware Anti-Virus (0)

Anonymous Coward | more than 6 years ago | (#23373576)

Forgive me if there is such a thing but it seems to me that HW vendors should be providing some sort of AV type program that runs at startup. For example I use a Toshiba Satellite A30 laptop. At startup it should spend 60 seconds running a scan and acting / reporting appropriately.
There would be requirements for updating and such but this can be worked out.
Is there such a thing already? And if not - is it possible to do?

Yes But! Does it run on linux? (0)

Anonymous Coward | more than 6 years ago | (#23373770)

I quess I should feel lucky.

Re:Yes But! Does it run on linux? (1)

extirpater (132500) | more than 6 years ago | (#23376326)

Yes But! Does it run on linux?
netbsd runs on it.

int 19 (1)

monkaru (927718) | more than 6 years ago | (#23374108)

It strikes me that Interrupt 19 is a heck of a lot easier to use and not hardware dependant providing that the CPU is any version of x86 and int 19 isn't disabled. Curiously, most CMOS, even modern ones, leave int 19 wide open by default so it can reboot the system without clearing memory or restoring interrupt vectors. How easy is that?

General Software BIOS (1, Interesting)

Anonymous Coward | more than 6 years ago | (#23375150)

Have a look at General Software's Firmbase technology. They are using the SMM for lots of crazy stuff - a tiny OS is running in SMM mode. It is interacting with USB, network adapter, serial ports etc. It has a web server, telnet server, snmp server... It is possible to get a prompt on serial port to poke the hw registers, memory, cpu registers etc while the main OS is running and doesn't have a clue what's going on. This comes very handy when developing drivers for such systems, but if some evil bios engineer would add an exploit to SMM, nobody would figure out where to look for it.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?