Slashdot Mirror
Anti-Rootkit Security Beyond the OS
Orome1 writes "Cybercriminals know how to evade current operating systems-based security, demanding a new paradigm – security beyond the operating system. On that note, McAfee demonstrated the workings of its new McAfee DeepSAFE technology at the Intel Developer Forum on Tuesday. Co-developed with Intel, it allows McAfee to develop hardware-assisted security products to take advantage of a 'deeper' security footprint. It sits beyond the operating system and close to the silicon, and by operating beyond the OS, it provides a direct view of system memory and processor activity."
Why doesn't McAfee just write an OS?
I sat down to write a new sig tonight and all I did was make the chair warm.
Scary.
I think an anti-malware scanner that ran from a boot disk and loaded the OS on the drive into a virtual machine would be an incredibly valuable tool.
Or we could just switch to cloud based security white-listing and kill the majority of the malware industry overnight.
10 years later..
"Cybercriminals know how to evade current silicon-based security, demanding a new paradigm - security beyond the hardware and the OS. On that note, McAfee demonstrated the workings of it's new invention - the non-dumb user."
now you've got your silicon running under the assumption that the OS is not implicitly trusted, but for some reason, some other OS should be trusted and should process every bit of information a 2nd time before anything is accomplished.
#dumb
Just like ring 0 and ring -1 have been abuse, I'm pretty sure that in a few years, we'll read headlines "New persistent rookit infects McAfee DeepSafe"!
hammer a nail through the cpu it'll kill all the vira, and it will still have more computing power left than if it was running McAfee ...
Now the hardware can be ground to a halt without ever loading an OS.
Given the choice of McAfee or malware at this level, I would choose the malware.
- Dan.
~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
This is great, sounds like a tool that would be great for MAKING new rootkits, actually.
Also, you can make sure that yours is hidden even from hardware-based antivirus. .... paranoia asside, it is the right way to go... but I don't really think McAfee will put a dent in serious viruses.... they still don't even detect ircphate...
it's turtles all the way down!
With a core operating system in ROM, mounted as a system disk. Flash your new OS like a BIOS.
That'd stop a lot of this rootkit crap cold, wouldn't it?
occultae nullus est respectus musicae - originally a Greek proverb
Yet another technology to confuse the end users. There will be countless 3rd party versions of this, due to anti-competition legislations, a significant portion which will be "free" or "lower cost alternatives" and not do what it promises to do.
Nothing should get between the OS and the metal. The OS should be smart enough to watchdog all processes.
OK, this is another layer to slow the system down before the OS is even loaded.
Where's the UI? Via the OS? Is McCaffee writing a UI for NT, Mac OS, Linux...? Fine, so develop a sandbox then they write the circumvention saving the script kiddies the bother...
Operation Guillotine is in effect.
McAfee that deep and cozy with the bare hardware?
What a waste of bits. The article didn't talk about much more than what was in the summary.
Beginning back in 2003 I talked about the future of computing which will include DRM in the BIOS. I have posted numerous times about it and even once noted DRM'd BIOSs will eventually be required to connect to the "safe" Internet.
We're one step closer now with this... Oh looky, we have the perfect way to stop this from happening. A totally secure DRM'd BIOS. Just use our product and the secure Internet won't have any spyware/malware/etc.
Oh, and in order to do online banking, pay the electric bill, connect to webmail from Google, etc will all require you to have a DRM-enabled BIOS.
IPs may not point to an individual computer but the DRM'd BIOS sure will.
It sits beyond the operating system and close to the silicon, and by operating beyond the OS, it provides a direct view of system memory and processor activity."
Has she got little windows to look in at the bytes going by or bye?
And require physical manipulation, e.g. jumper or dipswitch, to flash that ROM in case you want to re-install/upgrade OS.
While write mode is ON the box is isolated from rest of the internet.
At this point you only have to make sure that your update isn't infected. This can be easily verified using public key embedded in the current OS assuming that the vendor hasn't pulled a DigiNotar.
'it provides a direct view of system memory and processor activity, allowing McAfee products to gain an additional vantage point in the computing stack'
So it's visible from the OS. Now we have another vector of attack. How long before it's exploited to create even deeper rootkits, eh? Unless it's completely uncrackable, like the PS3.
Is it going to be written in some new magical language that prevents programmers from fucking up and having buffer overflow/underflow or other common problems that you see in C and C++, the most likely languages that this kind of software would be written in?
Just today there was an article on
From TFA:
(bold tags added by me)
Bullshit. Just like normal AV has minimal performance impact now.
Besides all of the obvious reasons that this is just another gimmick by McAfee to get more $$ from corporate IT departments with MBA directors that don't even know what the "silicon" in the marketing press release, sorry "article" means, when this gets exploited and there are viri for this layer I bet McAfee will have a AV for this layer to sell.
"and by operating beyond the OS, it provides a direct view of system memory and processor activity."
I thought you meant "Seal Team 6 and a bullet between the eyes" beyond the operating system.
I rootkitted your rootkit so you can rootkit while you rootkit.
Via tools U already own: Windows Install Media (read-only), & it's RECOVERY CONSOLE - Fixmbr, Disable, & Listsvc are all you needed to "take out" anything in the way of rootkits (or, those combined w/ botnets + "3rd party malware" they download & use)... it works & has worked recently.
Even vs. the last allegedly "indestructible botnet" & it's hello_tt.sys bootsector protectant driver... which disable from RC stalls on reboots, then it's fixmbr to blowout the MBR$ infesting rootkit itself.
(Listsvc's only for seeing driver &/or service names + their load states, etc. (when you don't know the name of the rootkit's driver, IF ANY, most rootkits don't use that & a "phalanx" formation extra driver protector either though, luckily, not yet @ least))
In the case of the "allegedly indestructible rootkit", this worked, in perhaps @ most, 3 min. time...
(Especially for those that know & recognize valid service &/or driver names used by Windows itself too, saves time googling from another system for driver &/or service names + purposes).
APK
P.S.=> The weakness the "allegedly indestructible rootkit" had is that it's driver also didn't protect ITSELF @ the registry driver parameterization itself...
Now, think about that, given the tools I've been using for ages vs. rootkits - IF it did that? The technique above might not have worked vs. it!
This one this article's about?? Looks like a mean cookie what-with the BIOS being thrown into the mix as well... to me @ least?? It'd mean time.
Time tp bootstrap from a DOS bootdisk with bios flashware & latest/greatest ROM for that mobo, & reburn that too - timeconsuming b.s.!
However, not avoiding it - it would NEED TO BE DONE, otherwise that rigs "permanently hosed" - period. It's @ BIOS hardware ROM level then, have to cleanse it or it's typhoid Mary basically... anyhow...
Know the tools you already own - they can do a hell of a job in minutes on rootkits of ANY kind (MBR, driver driven, or a "blended threat" that uses both)...
... apk
McAfee thinks that Microsoft will never be able to write a secure OS, so they are taking matters into their own hands.
Considering the vast majority of attacks relies on human stupidity, why don't we try to solve that problem first. Security should be part of the educational package in high schools. How to be secure with your digital life.
But rather than call it security, just call it safety. Kids have to be taught how to be safe in all sorts of situations, computers shouldn't be any different.
I'm god, but it's a bit of a drag really...
FYI, Intel owns McAfee now. This sounds like something between Trend ChipAwayVirus, a hardware debugger and draconian DRM.
Can it stop God? You've picked a side.
10 i = i + 1
15 IF i > 99999 THEN PRINT ".";: i = 0
20 IF INKEY$ = "" THEN 10
30 PRINT "King James Bible, Line:", i
Line:46410
7:12 If he turn not, he will whet his sword; he hath bent his bow, and
made it ready.
7:13 He hath also prepared for him the instruments of death; he
ordaineth his arrows against the persecutors.
7:14 Behold, he travaileth with iniquity, and hath conceived mischief,
and brought forth falsehood.
7:15 He made a pit, and digged it, and is fallen into the ditch which
he made.
I use an Ubuntu USB drive that I created for the specific purpose of scanning systems before they boot into the OS. It won't detect malware in real-time, but it should, in theory, catch a root kit that's well hidden from being detected within the OS. What I don't understand is why there's not something commercial out there that does this. With my home-made drive, I can boot, mount a truecrypt volume (all our computers are truecrypted) and scan a Windows file system with several different free tools. The only problem is, since they are free, they tend to be not very good. I scanned a system I was working with yesterday, and ClamAV, Avast!, BitDefender and AVG all missed a boot sector virus. The system was clearly infected, judging by all the BSODs and other strange behavior, but all these tools came up clean. They were also slow as hell. Each scan took hours. Finally, I attached the hard drive to a Windows machine and ESET picked up the virus right away, although it wasn't able to clean it. Had to download a separate tool from Kaspersky to do that.
What I'm saying is most of the stuff I did is not accessible to the unwashed masses. On top of that, I would actually pay good money for a tool that I could use and not have to screw with 5 different immature anti-virus platforms that could be used to remove rootkits. Nothing about this virus was particularly fancy, once you got it outside of the OS. (It loaded kernel mode drivers to prevent it from being seen within Windows.) Why don't one of the major players start looking into something like this? Bootable, able to update definitions over the Internet and fast. I, and probably my company, would pay really good money for that.
-Arthur
Cave ne ante ullas catapultas ambules
i think, here also need to add that spyware also great problem for PC users. we need enough protection against it.
http://en.wikipedia.org/wiki/Trusted_Platform_Module
Not a new idea at all. Heck, many existing mother boards support it.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
All computer users need it; few computer users have it.
Any new layer of software like this will be complex enough to be hackable and has to be maintained, so it has to have ways to get into it. Even with TPM or some similar scheme there are ALWAYS weaknesses, timing attacks, back doors, bad implementation, etc.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Why don't they make a bootable antirootkit like bitdefender? That's the easiest solution to the problem. Getting closer to the metal is an uphill battle because eventually malware writers will figure out how to get there themselves, and the situation just becomes worse. In fact, as antivirus software get more and more privileges they beacome more and more like viruses. Cannot be closed, always running in the background, inspects/modifies/deletes files without your permission. Sometimes I wonder if the reason of not fixing OS bugs is that Microsoft is afraid to make AVs incompatible.
That's what I was thinking. A SATA/USB3 adapter I bought has a jumper to make the drive read-only. That got me thinking - why can't we have a hardware toggle switch to make the boot drive read-only? You can't root it if you can't modify any of the bootable system files, or if you do manage it a reboot will clear it up. Yeah you'd have to toggle the drive writeable to install new software or update. But is there really any point to leaving the boot drive writeable when you're not updating or installing?
"Might as well just return to the Tandy 1000 days With a core operating system in ROM, mounted as a system disk. Flash your new OS like a BIOS. That'd stop a lot of this rootkit crap cold, wouldn't it?"
..
That solution wouldn't work with today's `innovative' desktop operating systems and besides there's no money in your solution
Bah. Back around the turn of the century I constructed the most hack-proof OS install ever. My FreeBSD-running-Squid solution mounted the entire OS off of a CD-ROM, created a 2MB RAM disk, mounted it as /etc and copied the entire /etc directory from floppy disk. After booting, it unmounted the floppy disk and I called the NOC to eject it, creating a 1cm air gap between the read-write heads of the floppy drive to the floppy disk contents. The collocation space and bandwidth were free and the floppies and CD-Rs cost $.10 each. If I ever suspected rootkits I would just shut the machine down as I had half a dozen of these 1U servers, at $100 each off eBay! Take that cloud computing and McAfee ROMs!
Diplomacy is the art of saying "nice doggy" until you can find a rock.
I would suspect this would be more for MBR exploits than anything else. On the other hand, if they are going to try to sample instructions in real time, they would not need to sit between anything as a majority of people on here seem to suggest, they could simply send an interrupt whenever something is detected... just like every other piece of hardware on the system does. My only concern would be is how they handle the interrupts, if it halts the system, blocks processes etc it would be relatively simple for someone to write code to effectively brick motherboards.
why can't people just stop allowing themselves to be tricked. Trust the internet like you'd trust any stranger and you'll be OK.
Never say never. Ah!! I did it again!
Windows on a cartridge sure would deter piracy...
Why doesn't McAfee just write an OS?
Too busy writing software to destroy performance on Windows. Can't spare any staff otherwise someone out there on a PC infected with^H^H^H^H^H^H^H^H^H^H^H^Hrunning McAfee might get some work done. What if that were the accountant? He might close the company account with McAfee!
These posts express my own personal views, not those of my employer
It's our only sure defense against the Cylon menace!
Student: Is it true that the foundation of the universe is paradox?
Master: Well, yes and no.
God only infects human brains, not computers.
The Tao of math: The numbers you can count are not the real numbers.
As I pointed out less than 24 hours ago in response to a similar story... (mods in brackets)
I keep watch on "security" threads like this one, hoping to find sanity in at least one answer prior to mine.... and keep getting disappointed.
You're all wrong, so far. [Well, all but about 5 of you... progress is being made]
Why? It's simple, it's not a [Trusted Platform / Virus scanning] issue, it's an Operating System design issue.
The default permit environment present in everything except IBM's VM is the root cause of 99% of our problems. [Yes, including this one, trusting something not to install a rootkit once it gets past the virus scanner]
Instead of giving each PROCESS a list of resources and permissions, Linux, OS-X, Windows, and pretty much everything else, does it at the USER level. (Yes, I know about app-armor, but that's a special case[, and isn't dynamic enough to do a proper job of capabilities])
This means that all of the defenses are pointed in the wrong direction. (Imagine building a fort with 10 foot thick perimeter wall as its sole defense in the age of paratroopers and helicopters to get an idea of the scale of the problem). [In this case, they claim to have better walls]
It doesn't matter how careful or professionally trained the application programmers are, nor how safe the programming language used to write the application is, when the OS isn't even designed to limit what they can do. All programs have bugs, you shouldn't have to trust them not to have them.
Now, those skills and language enhancements are useful for building the operating system, especially when constructing the micro-kernel to run everything, so it's not wasted effort. [However... virus scanners are a waste, as we shouldn't need them at all]
I predict we'll see stories like this for at least 10 more years [well... that's #2 in the first 24 hours], regardless of the effort or money put in, because we haven't [corrected] our approach yet. It's going to take a few more years until the cognitive dissonance gets loud enough in peoples heads to prompt them to find a better OS, and a few more years to actually have something reasonably solid available. Until then, buckle up... it's going to be a VERY bumpy ride.
What about the botnet comprised of all the electrons in the solar system? :D Everyone is rooted....
In the distance you hear an ominous moo.
0.0.0.0 dh.3515.info , because this rootkit uses it (as a C&C/Payloads Server). That blocks it.
* You're welcome "in advance"...
APK
P.S.=> I like what you said: Clever, & amusing enough of a play on words though from you, I have to admit, lol!
However, & as to actual time involved using it on my part? Well, I have been using that basic technique since the days of the 1st Recovery Conole for Windows NT-based OS, 1999 or so.
It just works!
(But, there are limits to it, like anything else - I outlined a possible & a design of rootkit that would evade destruction, vs. MY METHOD THAT'S NEVER FAILED ME ON ROOTKIT DESTRUCTION, & simply by improving its "phalanx" formation MBR$ infestor portion, & specifically, it's bootsector backup driver -> hello_tty.sys (e.g. from the "allegedly indestructible rootkit" recently (very destructible via the method I use)).
So again: Since, oh, 1999-2000 right @ its introduction, so, working on 2 decades...
I like it, as it's very useful vs. rootkits of MOST designs, be they driver based, or MBR$ infector based, or a "blended threat" of both combined...
... apk
Oh, wait.
It doesn't matter how careful or professionally trained the application programmers are, nor how safe the programming language used to write the application is, when the OS isn't even designed to limit what they can do. All programs have bugs, you shouldn't have to trust them not to have them.
By extension, it doesn't matter how careful or professionally trained the operating system programmers are, because all operating systems have bugs. I completely agree.
It's time to start requiring formal verification of all system software so that it doesn't matter how bad the programmers are; if a simple proof verifier that is stored in the BIOS can't validate a proof of correctness at the machine code level for the boot sector it loads, it won't jump to it. The formally correct boot loader would then load the OS and its correctness proof and verify it before starting the OS. Part of the correctness proof would be showing that no modification of the BIOS, boot loader, or OS can occur unless the modification also has a valid proof that follows a security policy stored in the BIOS. Don't ever allow the initial proof verifier or the security policy to be modified. Prove the correctness (with regard to the axioms of set theory, at least) of the proof verifier's machine code in the same language, and the proof verifier can even verify itself every time it boots. Of course, you could claim that all mathematical proofs have bugs in them and that there's no way to trust the proof verifier to be correct. But then you might as well distrust ZF and most of mathematics by extension.
The whole operating system doesn't need formal verification, just the kernel. If it does its job, then there is no point at which a rootkit will be given access to the underlying hardware, and thus it won't be installed.
There... translated the ambiguous abbreviation in teh summery for ya.... oh, sure... we had a rootkit in UNIX before, but its such rare treat its actually quite valuable. For all intensive purposes, the OP should have just said "Windows," but its likely he's never heard of any other OS. So, again, in the summary,
OS = Microsoft Windows
The Admin and the Engineer
With a core operating system in ROM, mounted as a system disk. Flash your new OS like a BIOS.
That'd stop a lot of this rootkit crap cold, wouldn't it?
Yes it would. Also it would leave most of the users vulnerable because no one would bother to patch the os if he had to mess with jumpers or hardware switches and if you did it updatable by software malware would get easily in.
There was some pretty straightforward method method for detecting rootkits making use of their cloaking (read about it on /. can't remeber in which article). You make a file listing of the whole disk while os runs (rootkit is hidden). Then take out the disk and make a file listing on another machine (rootkit isn't hidden). Compare lists, deal with files which are there in second list but missing in first.
Really, McAfee? They have absolutely zero credibility with me. If only they had a stable and useful retail antivirus product... Nearly every machine I've ever serviced (I do this for a living) with McAfee installed has had problems that were cured by removing the McAfee product and going with another well known vendor. I'm talking dozens of machines over the past five or six years.
Who knows, it sounds like a potentially useful and interesting idea but not from these guys. They're just marketing sharks.
Rob
A rootkit doesn't need to involve hardware. It can be an OS patch, or a driver, which simply filters out any data that would show the presence of the rook kit.
If your kernel allows neither replacing the kernel with a different one, nor installing drivers, don't expect your OS to be usable for anything outside the embedded world.
Now the hardware can be ground to a halt without ever loading an OS. Given the choice of McAfee or malware at this level, I would choose the malware. John air max shoes
Make the first thing that happens during boot or a windows-install, the set-up of a VM. Let the VM monitor the OS.
Religion is what happens when nature strikes and groupthink goes wrong.
hmm interesting. Let's say you have the OS read-only, then you can have a differences virtual drive that loads on boot. Now if your OS get's scrambled you will always be able to return to the stock OS. Kind of like 'last known good' but better.
However looking at the Win8 preview there does seem to be something similar there but I've not explored it yet.
fix the OS
Anons need not reply. Questions end with a question mark.
This is a terrible execution of a seemingly fantastic idea. McAffee(sp?) is known for accidentally hosing untold numbers of business machines with 1 (yes, one) update! How can we allow them this much control over our compute environment?
Also, this would appear to be why Intel had to have McAffee. Antivirus on die? Pretty much the definition of CISC.
Well, here's to updating your antivirus and accidentally bricking your CPU.
"Helping to keep you two steps ahead of the Thought Police!"
We need less of this not more. The more ways there are to elevate power for AV, the more possibilities there are to elevate power for rootkits.
Bios should not be writable when OS is running. MBR should not be writable when os is running. Code injection, debugginh and hooking, while neat, should be removed, except when the program INVITES an intruder. Drivers should only have access to things explicitly enumerated to the user: a graph card driver only to graph card, keyboard only to keyboard. Drivers not from manufacturer should give extensive warnings, with long forced waiting times before ok is clicked.
Kernels can be replaced in real time, it's been done in Linux.
Something in hardware (which is implied in this new technology) has to be updateable in order to resist threats over time. It too will have the same critical points as any system which doesn't trust the code running on it.
A capabilities based operating system would have about the same attack surface because it wouldn't trust anything by default, the opposite of the way things are now.
Instead of deploying a new hardware stack, isn't it better to just fix the software stack we already have?
and I'm not letting them any near my CPU.
Actually, most, if not all, rootkit scanners are like this. Compile a list of files and registry entries using the API and compare this against a list generated by the rootkit developer's method of reading the filesystem and registry file directly.
It means it's Windows all the way down. Linux would be indistinguishable from malware in a hard coded, unflashable, secure chip. MS can lock up large vendor machines by claiming security, and letting Intel do the dirty work. Does anyone honestly think they'll hard code every alternative OS? Unless it is specific, it's useless. Malware can run a rootkit as a linux kernel. Also, what's to say that it wouldn't block a new kernel release even if it was whitelisted.
Goodbye Tux, we barely knew you.
I8-D
Well well, isn't that a remarkably lucky coincidence?
ALAN: It's called Tron. It's a security program itself, actually. Monitors all the contacts between our system and other systems... If it finds anything going on that's not scheduled, it shuts it down. I sent you a memo on it.
DILLINGER: Mmm. Part of the Master Control Program?
ALAN: No, it'll run independently. It can watchdog the MCP as well.
DILLINGER: Ah. Sounds good. Well, we should have you running again in a couple of days, I hope...
Alan rises, goes to the door. As soon as he leaves:
The Master Control Program comes back to life, on the screen and through the speakers.
MCP: Ed, I am so very disappointed in you.
http://www.google.com/search?sclient=psy&hl=en&site=&source=hp&q=%22dh.3515.info%22&btnG=Search
APK
But the article is significant, in that this marks the beginning of the battle for ring -1 in the security products market. Personally I am 'root'ing for QubesOS to show the way, but having any COTS product on the market for Windows would be a good thing. Why? Because if you have a processor with the VT-x capability and you are not loading in a ring -1 hypervisor then one can be inserted under your OS by Malware, and you would never know its there. Its a race to be the first software package/Malware to implant itself and have total domination over what gets loaded next. You may think you are running at the ring -1 level, but other than timing tests on certain CPU instructions it would be very hard to tell that you don't and a new Malicious Overlord. IMHO it would be wise to load even a dummy hypervisor in ring -1 rather than just letting a virtualizing rootkit become the master of your domain.
Well, yes, until some malware author reverse engineered the updater software, learned how to duplicate the bypass-the-write-protect-mechanism code that allows flashing, and then used that to inject his own code. That would take all of the next day after it hit the store shelves, at most. Have you heard of malware that alters the BIOS? There are a few prior examples of such a thing. CIH was doing that in 1998, for example. Mebromi does that today.
So, no, it wouldn't stop it, unless you had to purchase and install a new physical ROM chip as your upgrade process. Nobody would go for that, though... too expensive to manufacture the parts, too fragile, too scary for non-geeks!
You'd still have regular viruses and such that were installed in the "regular" filesystem, though, so rootkits would still exist. Someone could make a virus that installs as a driver, which does NOT have the prerequisite of controlling hardware nor does it have to be visible to the user. That could get high-level access to the system, and you'd never know it. That happens today. It's been happening since at least 1999, when Infis was discovered. Remember the Sony rootkit, too!
This problem was solved many years ago when mainboards had a jumper that you had to move to flash the BIOS and they also had a bit of code in the BIOS to write protect the MBR. These two simple features effectively locked down a mainboard with a very minimal cost.
Nothing like chip & software companies getting together to promote a $100 solution to a $1 problem.
If your disk driver isn't formally verified, it can overwrite the boot sector.
If your video driver isn't formally verified, it can overwrite any location in memory.
If your (insert just about anything here) driver that supports DMA isn't formally verified, it can also overwrite any location in memory.
If your BIOS flashing driver isn't formally verified, the next time you boot you have a rootkit.
If your file system driver isn't formally verified, it can modify the operating system files.
If your window manager/login prompt/other common OS programs aren't formally verified, they will allow privilege escalation.
In short, everything the user has to trust when using a computer needs to be formally verified. That even includes web browsers and plugins that allow running untrusted code.
Well; for something as simple as a CA Cert list, that could be updated pretty frequently (these days, LOL!) - you'd be popping that jumper on and off every Tuesday.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
Put a switch on the case.
Jut because it is a jumper now, doesn't mean it needs to stay that way.
Great Intellect...
The only thing that MUST be verified is the OS kernel, the rest can be dealt with as untrusted code. L4 is at this stage.
If your disk driver isn't formally verified, it can overwrite the boot sector.
If your file system driver isn't formally verified, it can modify the operating system files.
The OS doesn't have to trust the boot sector, it can verify the information using cryptographic signatures. If you treat the block devices as untrusted, you will do things like using checksums, CRCs, ECC, etc... don't forget that hard drives typically get 1 out of 10^15 blocks wrong in the normal course of doing business.
You can also encrypt/sign the drivers so the OS can check for modifications, should a rootkit be present.
Since an untrusted file system driver would have to use the OS to read / write the block devices, you could present it with a read-only capability to the block device which contains the OS, stopping all modification. In the case of a need for an update, the OS could then use a read/write capability to do the update, and switch back when done. I'm sure someone with a good background in CS could figure out a more secure way of doing it.
If your video driver isn't formally verified, it can overwrite any location in memory.
Not if the memory management is working correctly... Windows NT 3.5 and earlier had video running outside the kernel... which is the right way to do things in terms of security.
If your (insert just about anything here) driver that supports DMA isn't formally verified, it can also overwrite any location in memory.
Drivers don't have to run in kernel mode to be efficient, and the DMA doesn't have to be set up directly by the drivers. The MMU and the control over input parameters to the DMA/Interrupt subsystems should suffice here as well.
If your BIOS flashing driver isn't formally verified, the next time you boot you have a rootkit.
True, but to have a rootkit, it has to be installed at some point, which a secure OS would prevent.
On the other hand, if your threat model includes nation states, you can't stop rootkits installed using physical access to the hardware, if they have enough time... even a checksum bios could be subverted with the right hardware between the motherboard and storage.
Either way, attempting to detect faults and fouls should be a normal part of the boot process.
If your window manager/login prompt/other common OS programs aren't formally verified, they will allow privilege escalation.
Yes, they MIGHT allow privilege escalation, especially if they aren't well constructed and fairly transparent in their operation to the user. The key is to provide an easy to use facility for specification of exactly what permissions are to be given to a program. This needs some work, the first few widely used iterations will be a bit rough around the edges, but after some use and tweaking, it should be pretty easy to do. This results in a secure, efficient Operating System, with no need to trust any program.
The primary reason we even worry about root kits is that Operating Systems haven't been designed to work in a world of untrusted code. Changing that one aspect of things, doing a hell of a lot of coding to build a capability based OS, provides an environment in which it is very unlikely that any rootkit would get the opportunity to be installed.
The OS doesn't have to trust the boot sector, it can verify the information using cryptographic signatures. If you treat the block devices as untrusted, you will do things like using checksums, CRCs, ECC, etc... don't forget that hard drives typically get 1 out of 10^15 blocks wrong in the normal course of doing business.
DRM is not the same as formal correctness. I can probabilistically trust public key methods to protect probabilistically correct code, or I can fully trust formally proven code. Given the track record of DRM and code-signing I would opt for formal correctness. Hardware reliability is another issue entirely. You can only have probabilistic trust in the hardware, but unless you are working with tamper-resistant systems you probably don't have to worry about direct attacks on hardware reliability and can use ECC and cryptography to ensure that your own hardware is operating correctly.
Since an untrusted file system driver would have to use the OS to read / write the block devices, you could present it with a read-only capability to the block device which contains the OS, stopping all modification. In the case of a need for an update, the OS could then use a read/write capability to do the update, and switch back when done. I'm sure someone with a good background in CS could figure out a more secure way of doing it.
How does the OS know which data blocks contain user data and which blocks contain OS data? How does the OS know the filesystem isn't lying about the data it's going to write? Suppose the OS has perfect control over when and where the file system can write data. The file system says "Time to install an OS upgrade", gets permission, and then writes a rootkit instead of valid data. The entire chain has to be trusted. "a more secure way of doing it" is to formally verify the data to be written to the OS disks before it's written, and then when booting formally verify it again before running it to be sure it wasn't modified.
Not if the memory management is working correctly... Windows NT 3.5 and earlier had video running outside the kernel... which is the right way to do things in terms of security.
It's not just the CPU that has access to RAM, any device on the PCI bus has access as well. You do have to trust your hardware, of course, but once the hardware is trusted you also need to trust the driver software to give the correct addresses to the hardware for DMA. The hardware has no idea what sort of protection the OS is using or how it has organized memory, it just reads and writes to specific addresses in RAM. There were (are) numerous X11 privilege escalations based on this fact since OpenGL programs can talk directly to the hardware via direct rendering.
Drivers don't have to run in kernel mode to be efficient, and the DMA doesn't have to be set up directly by the drivers. The MMU and the control over input parameters to the DMA/Interrupt subsystems should suffice here as well.
Sometimes the DMA parameters are sent directly to the hardware, especially with video cards. DMA scatter/gather is also used by many disk and network controllers. The particular interface used to tell the hardware which addresses to use is not standardized to the point that every possible hardware driver could use a simple, secure operating system service to pass those DMA parameters to the hardware.
The primary reason we even worry about root kits is that Operating Systems haven't been designed to work in a world of untrusted code. Changing that one aspect of things, doing a hell of a lot of coding to build a capability based OS, provides an environment in which it is very unlikely that any rootkit would get the opportunity to be installed.
So you have a perfect capability operating system and it will never be infected by a rootkit and you have fine-grained control over network and file access. You have a secret file on your computer that you would like to process, the result of the proc