Despite what everyone seems to think, PatchGuard is not security. It's "security through obscurity", which is not security. If you are a rootkit running in kernel mode, you can patch out PatchGuard. It may be difficult to reverse engineer, but it CAN be defeated. I still think it's a great idea.
The "security" vendors out there have nobody to blame but themselves. For years now they've been installing badly designed "security" software that damages the integrity of the system. This software adds hooks into syscalls that frequently crash the system or make it easy for unprivileged user-mode programs to crash the system. Worse, some of these unintentionally add back doors to the system that allow privilege escalation.
PatchGuard prevents legitimate software developers from doing things they shouldn't be doing. If a legitimate software developer breaks PatchGuard, the next second Tuesday their software will stop working. Meanwhile, rootkits are completely unaffected; they've pwned your system for a month already.
Many people suggest that kernel drivers should need to be signed to solve these problems. This is a terrible "solution" for many reasons. For one, you have to severely restrict user mode in order for it to work. To explain it to UNIX users, "mkfs", "fsck", etc. would have to become kernel programs because otherwise bypassing signature checks becomes easy: overwrite/dev/hda with a hacked MBR and reboot.
Driver signing throws the ability to write kernel software out the window for anyone not able to pay the VeriSign Tax - and only corporations, not individuals, can get such a signing key.
PatchGuard does have one problem from my perspective: you cannot implement features that Microsoft hasn't implemented or has removed. For example, I wanted to make my own NTVDM for Win64 since Microsoft removed it. I found out that it is impossible, because Microsoft removed support for LDTs in Win64. You can't add it yourself with a kernel driver, because you'd need to patch the context switch mechanism - the kernel doesn't have code to switch LDTR values between processes anymore.
An integer overflow would imply that the string is the size of the address space minus 1. Where's the code that's executing the strcpy? =)
(Yes, this is theoretically possible in DOS and Win16...)
I hope "foo" is not direct user input from an insecure context, or its size is limited. Allocating hundreds of megabytes is bad even if it doesn't leave to a buffer overflow.
Microsoft's PREfast stuff lets you mark up code to say how the parameters to functions work. If you accidentally put a "5" instead of "6" as your array size, the compiler would notice a violation of the rules and issue a warning. It won't pick up everything (see "halting problem") but at least it'll find the obvious things.
There are performance reasons to use strcpy.
I personally feel that strcpy on a buffer allocated by the same function is okay, but doing this across functions is bad because someone else (or you years from now) modifying your code won't know to do that.
When presented with the choice between her and the competing Republican religious whackjob who would probably also support DRM, what am I supposed to do?
Coverity sounds like a scam. It is not possible for a program to analyze another program and find all the bugs; see halting problem.
I would find heuristic analysis annoying. I'd get quite annoyed if the program says "fix this buffer overflow" 1000 times because I use "strcpy" somewhere - even though I'm very careful and only use it when I know it can't overflow.
I should write a program that searches for odd perfect numbers and terminates if it finds one. I wonder whether Coverity would say it is an infinite loop.
Coverity sounds like scare tactics to make money by claiming to do the impossible. They won't even disclose what their algorithm is. I would never trust them, especially on closed-source programs. Firefox doesn't have that risk, but they are wasting money.
Microsoft's PREfast is simpler but seems like a much more realistic solution: mark up your code to say how things are supposed to be used and the compiler can decidably sense problems. I'd just get tired of typing 2 underscores a million times.
Vista has something known as "Protected Processes". These are user-mode processes that are protected against modification. The kernel continually hashes these processes' code sections and verifies that they have not changed. If they have changed, the system bugchecks (BSOD). Such processes run at ordinary user security levels - they are not privileged.
You might ask what these are for. The answer: DRM. Windows Media Player is such a process when playing protected media. If you try to mess with it, the system bugchecks.
DoS attack against Terminal Services machines, anyone?
This is about x64 driver signing. In Vista 64, drivers *cannot* run if they are not signed by a corporation who has paid the "VeriSign Tax" *. Even if the administrator requests it, they will not run. This is retarded "security", and it will keep being broken until Microsoft either gives up or forces everyone to have TPM bootup (more likely the latter).
It infuriates developers, yet doesn't do anything for preventing rootkits, as Joanna has demonstrated. As long as user-mode programs have raw disk access, they will be able to attack whatever they want.
I have a feeling that Microsoft's response to this will be to lock out raw disk access to user mode regardless of privilege. Keep in mind that even SELinux does not do this. All disk utilities would have to be written as signed drivers. The problem here is that developers won't stand for it, and will make signed drivers that grant access again. Then the rootkits can just copy these signed drivers then use them to do the same thing.
Even if Microsoft encrypts the page file or removes the ability for the kernel to page itself out, raw disk access is still an issue. You can always open \Device\Harddisk0\Partition0 (NT's/dev/hda) and overwrite the MBR, then call NtShutdownSystem to reboot. If you take away raw disk access to user mode, then you get more esoteric. Detect when a blank CD or DVD has been inserted. When the user requests to burn it, intercept the write request and burn something else instead. Act like a system crash and reboot after it's done. Most computers are configured by default to boot from CD first.
The real reason for driver signing appears to be DRM. The easiest way to "crack" song DRM is to install a fake audio driver that logs to disk. With the DMCA, it's illegal to make such a driver, and with driver signing, it's impossible to do it anonymously. If you temporarily disable driver signing - which is possible if you press F8 each boot - Vista's Windows Media Player refuses to play protected songs. Gee I wonder why.
By the way, I thought of the same pagefile hack as Joanna on my own and posted it on my weblog in early June. I'm sure Joanna figured it out long before me though.
* There are other root certificate companies that are countersigned, but this is a well-known phrase.
Clearly the police weren't wrong in this case about who did the crime, but they could have been. The laws and articles protecting citizens against police power are there because of that possibility.
There's also the point that it's often the criminals who need the most legal protection.
Ignorance of how the justice system was designed among the majority of Americans is what is going to turn this country into a police state.
This is assuming that this damage to the oceans can continue indefinitely. A massive extinction of marine animals would make its way up the food chain. Land life would eventually be affected, both by the stuff we're already doing and by the extinction of their marine food. Eventually, it will affect humans. We'd start dying off too, leading to basically a collapse of civilization. It would return us to the stone age. With civilization gone, the damage to the oceans will stop.
It's very hard to kill all humans. Even now we don't have enough nukes and chemical weapons to kill every single person on Earth. You can probably get 99%, but that still leaves 62,000,000...
I implied that rootkit developers would still be able to make rootkits, but fake audio drivers couldn't be made. This sounds contradictory, since fake audio drivers can be made the same way as a rootkit. However, it's not technically infeasible, it's socially infeasible.
A rootkit is typically very secretive. It is rather uncommon for the run-of-the-mill trojan to have a kernel rootkit. Almost all trojans remain in user mode. Rootkits are a tool of experts, not script kiddies. Probably most rootkits out there are unknown.
A fake audio driver is public. There's nothing they intend to hide; they get credit when lots of people use their crack software.
The problem is that if you make a public crack of the signing system, it will be fixed the next second Tuesday, guaranteed. Unlike other security or "security" holes, Microsoft will be sure to fix anything you do very quickly since they're defending their DRM systems. Almost all users have automatic Windows Update now, so most likely your users will already be patched by then.
As for how you'd get around the driver signing, it is straightforward but annoying. User-mode programs running as Administrator or LocalSystem still have raw disk access write authority. You can open \Device\Harddisk0\Partition0 (NT's/dev/hda) and overwrite the boot sector, usurping the boot process from the MBR on. Call NtShutdownSystem to reboot, and your code runs with full authority. (Microsoft's goal is to eventually prevent this with hardware validation of the boot state; we call this TCPA.)
The real reason XP 64 can't upgrade to Vista is because of DRM.
Vista 64 requires all drivers to be signed in order to load, no matter how much privilege you have or even if you own the computer. Microsoft says that this is to prevent rootkits, but that is total BS: a rootkit can get around this stuff in many ways. The real reason is DRM, the "Secure Audio Path".
By preventing anonymous people from writing stable kernel drivers, they're attempting to lock out DRM cracks. The easiest way to break Windows Media DRM is to make a fake sound card driver that simply dumps its input to disk. Microsoft, with their "Secure Audio Path", wants to make it so that DRM'd songs and movies are encrypted all the way from Microsoft to your speakers, so that nothing can tap into a digital stream. Since that's going to happen any time soon, they've decided to lock out unsigned drivers to prevent anonymous people (who must be anonymous because of the DMCA) from writing such drivers.
Microsoft has made several rather hidden statements that indicate that DRM is the real reason. If you run Vista 64 with "test-signed" drivers - what legitimate driver developers use to code in Vista 64 - the Windows Media DRM system disables itself, preventing playback of protected songs and movies. This was a single sentence in a long document on MSDN. I have the original document saved but it seems the URL to it has changed. I doubt Microsoft has deleted it, just moved it.
Microsoft knew that driver developers would be pissed, so they came up with a way to force them to make Vista 64 drivers. You cannot get your driver into Vista's Windows Update unless you provide both a 32 and 64 bit version.
You can't upgrade from XP 64 to Vista 64 simply because every single driver you have is incompatible and must first be replaced with drivers whose developers have paid the VeriSign Tax.
JavaScript is not *supposed* to be able to do bad things like this. It has many safeguards built into it to avoid this.
The real problem is that the browsers have bad code in their JavaScript implementations. This is what needs to be fixed.
Also, web browsers probably should run using CreateRestrictedToken. I wish web browsers would run with lower privilege than your normal user applications. You could have 2 processes, one that runs at normal privilege and one that runs as a restricted token. Almost the entire browser would be under the restricted token. Really, the only exceptions should be when downloading or uploading files, at the user's request of course. Such things can be done over interprocess communication with a well-defined and hardened interface.
I guess that the big problem is that NT and Linux don't really have a way to do this. The only way I can think of this working is for the browser to run as a separate user account. That requires administrator access to set up, as does running a second process as a different user.
I'm the parent poster (although not the other Anonymous Coward sibling to your post). I'm the type that would do the hormones and surgery immediately if I were able to. But I look too manly and could never look female. Let's just say I've had a shotgun in my mouth a few times but can never get the courage to pull the trigger.
I can definitely see how your gender identity may not be out of sync enough to actually do anything. It's just not how I am.
- Anonymous, because "her" employer knows "her" Slashdot name
WoW has absolutely no gameplay difference between male and female. The stats and items are identical for both genders. Men can even wear the item "White Wedding Dress". =)
You can also/kiss/flirt etc. to either gender no matter yours.
In Vista, programs normally run without admin privileges even when you're supposedly logged on as an administrator. It's much like OS X's handling of administrators, though not at the technical level (NT has no setuid).
The problem is that Microsoft is preventing certain things from happening even when you *are* running as a trusted user. In Vista 64, you *cannot* load an unsigned kernel driver, even if you are a maximum-privileged user mode program. This is retarded, because such a user mode program can take over the system anyway regardless of that.
This new kernel patch protection should be viewed as safety against badly coded legitimate drivers, not security against a rootkit.
Rootkit authors are some of the best programmers and reverse engineers in the world. Does anyone *really* think that rootkit authors won't find a way around ci.dll? Even Vista 64's requirement that all kernel drivers be signed is a real joke. As long as it is possible to write to \Device\Harddisk0\Partition0 (NT's/dev/hda) from user mode as administrator, a rootkit can simply take over the entire boot process starting with the MBR, and call NtShutdownSystem to force a reboot into the hacked MBR. If using EFI, it's a bit different but still not difficult.
All this really prevents are mainstream drivers hooking into the kernel. Companies whose drivers once patched the kernel won't do so anymore, because if you bypass ci.dll publicly, Microsoft will "force" an update onto almost all users within days (or next second Tuesday if you're not important enough). I suppose that this is a good thing - I'm tired of stupid kernel drivers like nProtect and SafeDisc compromising system security and stability just to prevent cheating or copying (respectfully) in some game.
every application that runs on your computer should have its own address space and it should not be allowed to cross into other applications' address spaces, however this is not the case in MS Windows OS.
Nor is it in Linux. A root program or program of the same user can manipulate another process - this is known as "ptrace". It's basically the same as Windows in that respect.
In fact, in Windows NT, the process creation system relies on cross-process memory writing. When a program runs another program, it actually does memory injection into the new process. The NT kernel isn't really aware of things like the user mode stack, the environment, and the command line *. The parent process actually allocates new memory into the new process as the stack, copies its own environment into the new process through injection, and creates the initial thread.
* I just mean that the kernel doesn't manage the user-mode stack. The kernel creates a structure in user memory called the Process Environment Block that points to the environment, but it's not filled in by the kernel.
xterm is a user-mode program. A user-mode virus can take over xterm. It will know anything that you type in that terminal, including a sudo password. Once it has that, the virus can do what it wants.
Windows NT does not have this problem, at least as of 6.0: you always type your password in a program that runs as root ("LocalSystem"). Vista's default of not having admin access when logged on as admin is actually going to be a good feature. It'll also encourage developers to require admin to run their word processor.
Slashdot Mirror
Despite what everyone seems to think, PatchGuard is not security. It's "security through obscurity", which is not security. If you are a rootkit running in kernel mode, you can patch out PatchGuard. It may be difficult to reverse engineer, but it CAN be defeated. I still think it's a great idea.
/dev/hda with a hacked MBR and reboot.
The "security" vendors out there have nobody to blame but themselves. For years now they've been installing badly designed "security" software that damages the integrity of the system. This software adds hooks into syscalls that frequently crash the system or make it easy for unprivileged user-mode programs to crash the system. Worse, some of these unintentionally add back doors to the system that allow privilege escalation.
PatchGuard prevents legitimate software developers from doing things they shouldn't be doing. If a legitimate software developer breaks PatchGuard, the next second Tuesday their software will stop working. Meanwhile, rootkits are completely unaffected; they've pwned your system for a month already.
Many people suggest that kernel drivers should need to be signed to solve these problems. This is a terrible "solution" for many reasons. For one, you have to severely restrict user mode in order for it to work. To explain it to UNIX users, "mkfs", "fsck", etc. would have to become kernel programs because otherwise bypassing signature checks becomes easy: overwrite
Driver signing throws the ability to write kernel software out the window for anyone not able to pay the VeriSign Tax - and only corporations, not individuals, can get such a signing key.
PatchGuard does have one problem from my perspective: you cannot implement features that Microsoft hasn't implemented or has removed. For example, I wanted to make my own NTVDM for Win64 since Microsoft removed it. I found out that it is impossible, because Microsoft removed support for LDTs in Win64. You can't add it yourself with a kernel driver, because you'd need to patch the context switch mechanism - the kernel doesn't have code to switch LDTR values between processes anymore.
Melissa
An integer overflow would imply that the string is the size of the address space minus 1. Where's the code that's executing the strcpy? =)
(Yes, this is theoretically possible in DOS and Win16...)
I hope "foo" is not direct user input from an insecure context, or its size is limited. Allocating hundreds of megabytes is bad even if it doesn't leave to a buffer overflow.
Melissa
Microsoft's PREfast stuff lets you mark up code to say how the parameters to functions work. If you accidentally put a "5" instead of "6" as your array size, the compiler would notice a violation of the rules and issue a warning. It won't pick up everything (see "halting problem") but at least it'll find the obvious things.
There are performance reasons to use strcpy.
I personally feel that strcpy on a buffer allocated by the same function is okay, but doing this across functions is bad because someone else (or you years from now) modifying your code won't know to do that.
Melissa
When presented with the choice between her and the competing Republican religious whackjob who would probably also support DRM, what am I supposed to do?
Melissa in California
As for promoting Arts and Sciences -- have you ever thought the fact that Copyright being Infinite could promote arts and sciences?
So you would like to pay the modern Shakespeare family for Hamlet? Or how about all Iraqis for the epic of Gilgamesh?
Melissa
Coverity sounds like a scam. It is not possible for a program to analyze another program and find all the bugs; see halting problem.
I would find heuristic analysis annoying. I'd get quite annoyed if the program says "fix this buffer overflow" 1000 times because I use "strcpy" somewhere - even though I'm very careful and only use it when I know it can't overflow.
I should write a program that searches for odd perfect numbers and terminates if it finds one. I wonder whether Coverity would say it is an infinite loop.
Coverity sounds like scare tactics to make money by claiming to do the impossible. They won't even disclose what their algorithm is. I would never trust them, especially on closed-source programs. Firefox doesn't have that risk, but they are wasting money.
Microsoft's PREfast is simpler but seems like a much more realistic solution: mark up your code to say how things are supposed to be used and the compiler can decidably sense problems. I'd just get tired of typing 2 underscores a million times.
Melissa
Vista has something known as "Protected Processes". These are user-mode processes that are protected against modification. The kernel continually hashes these processes' code sections and verifies that they have not changed. If they have changed, the system bugchecks (BSOD). Such processes run at ordinary user security levels - they are not privileged.
You might ask what these are for. The answer: DRM. Windows Media Player is such a process when playing protected media. If you try to mess with it, the system bugchecks.
DoS attack against Terminal Services machines, anyone?
Melissa
This is about x64 driver signing. In Vista 64, drivers *cannot* run if they are not signed by a corporation who has paid the "VeriSign Tax" *. Even if the administrator requests it, they will not run. This is retarded "security", and it will keep being broken until Microsoft either gives up or forces everyone to have TPM bootup (more likely the latter).
/dev/hda) and overwrite the MBR, then call NtShutdownSystem to reboot. If you take away raw disk access to user mode, then you get more esoteric. Detect when a blank CD or DVD has been inserted. When the user requests to burn it, intercept the write request and burn something else instead. Act like a system crash and reboot after it's done. Most computers are configured by default to boot from CD first.
It infuriates developers, yet doesn't do anything for preventing rootkits, as Joanna has demonstrated. As long as user-mode programs have raw disk access, they will be able to attack whatever they want.
I have a feeling that Microsoft's response to this will be to lock out raw disk access to user mode regardless of privilege. Keep in mind that even SELinux does not do this. All disk utilities would have to be written as signed drivers. The problem here is that developers won't stand for it, and will make signed drivers that grant access again. Then the rootkits can just copy these signed drivers then use them to do the same thing.
Even if Microsoft encrypts the page file or removes the ability for the kernel to page itself out, raw disk access is still an issue. You can always open \Device\Harddisk0\Partition0 (NT's
The real reason for driver signing appears to be DRM. The easiest way to "crack" song DRM is to install a fake audio driver that logs to disk. With the DMCA, it's illegal to make such a driver, and with driver signing, it's impossible to do it anonymously. If you temporarily disable driver signing - which is possible if you press F8 each boot - Vista's Windows Media Player refuses to play protected songs. Gee I wonder why.
By the way, I thought of the same pagefile hack as Joanna on my own and posted it on my weblog in early June. I'm sure Joanna figured it out long before me though.
* There are other root certificate companies that are countersigned, but this is a well-known phrase.
Melissa
She... >_<
Something big hit Mexico 250 000 000 years ago and wasn't enough to kill the dinosaurs; one of them crapped on my car from above this morning. >_<
Melissa
She... >__
Melissa
Clearly the police weren't wrong in this case about who did the crime, but they could have been. The laws and articles protecting citizens against police power are there because of that possibility.
There's also the point that it's often the criminals who need the most legal protection.
Ignorance of how the justice system was designed among the majority of Americans is what is going to turn this country into a police state.
Melissa
I'm tired of this mistake, because it's a very easy rule to learn.
Melissa
This is assuming that this damage to the oceans can continue indefinitely. A massive extinction of marine animals would make its way up the food chain. Land life would eventually be affected, both by the stuff we're already doing and by the extinction of their marine food. Eventually, it will affect humans. We'd start dying off too, leading to basically a collapse of civilization. It would return us to the stone age. With civilization gone, the damage to the oceans will stop.
It's very hard to kill all humans. Even now we don't have enough nukes and chemical weapons to kill every single person on Earth. You can probably get 99%, but that still leaves 62,000,000...
Melissa
"Since that's going to happen any time soon"
should be:
"Since that's not going to happen any time soon"
Sorry...
Melissa
(This is separate to be like footnotes)
/dev/hda) and overwrite the boot sector, usurping the boot process from the MBR on. Call NtShutdownSystem to reboot, and your code runs with full authority. (Microsoft's goal is to eventually prevent this with hardware validation of the boot state; we call this TCPA.)
I implied that rootkit developers would still be able to make rootkits, but fake audio drivers couldn't be made. This sounds contradictory, since fake audio drivers can be made the same way as a rootkit. However, it's not technically infeasible, it's socially infeasible.
A rootkit is typically very secretive. It is rather uncommon for the run-of-the-mill trojan to have a kernel rootkit. Almost all trojans remain in user mode. Rootkits are a tool of experts, not script kiddies. Probably most rootkits out there are unknown.
A fake audio driver is public. There's nothing they intend to hide; they get credit when lots of people use their crack software.
The problem is that if you make a public crack of the signing system, it will be fixed the next second Tuesday, guaranteed. Unlike other security or "security" holes, Microsoft will be sure to fix anything you do very quickly since they're defending their DRM systems. Almost all users have automatic Windows Update now, so most likely your users will already be patched by then.
As for how you'd get around the driver signing, it is straightforward but annoying. User-mode programs running as Administrator or LocalSystem still have raw disk access write authority. You can open \Device\Harddisk0\Partition0 (NT's
Melissa
The real reason XP 64 can't upgrade to Vista is because of DRM.
Vista 64 requires all drivers to be signed in order to load, no matter how much privilege you have or even if you own the computer. Microsoft says that this is to prevent rootkits, but that is total BS: a rootkit can get around this stuff in many ways. The real reason is DRM, the "Secure Audio Path".
By preventing anonymous people from writing stable kernel drivers, they're attempting to lock out DRM cracks. The easiest way to break Windows Media DRM is to make a fake sound card driver that simply dumps its input to disk. Microsoft, with their "Secure Audio Path", wants to make it so that DRM'd songs and movies are encrypted all the way from Microsoft to your speakers, so that nothing can tap into a digital stream. Since that's going to happen any time soon, they've decided to lock out unsigned drivers to prevent anonymous people (who must be anonymous because of the DMCA) from writing such drivers.
Microsoft has made several rather hidden statements that indicate that DRM is the real reason. If you run Vista 64 with "test-signed" drivers - what legitimate driver developers use to code in Vista 64 - the Windows Media DRM system disables itself, preventing playback of protected songs and movies. This was a single sentence in a long document on MSDN. I have the original document saved but it seems the URL to it has changed. I doubt Microsoft has deleted it, just moved it.
Microsoft knew that driver developers would be pissed, so they came up with a way to force them to make Vista 64 drivers. You cannot get your driver into Vista's Windows Update unless you provide both a 32 and 64 bit version.
You can't upgrade from XP 64 to Vista 64 simply because every single driver you have is incompatible and must first be replaced with drivers whose developers have paid the VeriSign Tax.
Melissa
JavaScript is not *supposed* to be able to do bad things like this. It has many safeguards built into it to avoid this.
The real problem is that the browsers have bad code in their JavaScript implementations. This is what needs to be fixed.
Also, web browsers probably should run using CreateRestrictedToken. I wish web browsers would run with lower privilege than your normal user applications. You could have 2 processes, one that runs at normal privilege and one that runs as a restricted token. Almost the entire browser would be under the restricted token. Really, the only exceptions should be when downloading or uploading files, at the user's request of course. Such things can be done over interprocess communication with a well-defined and hardened interface.
I guess that the big problem is that NT and Linux don't really have a way to do this. The only way I can think of this working is for the browser to run as a separate user account. That requires administrator access to set up, as does running a second process as a different user.
Melissa
I'm the parent poster (although not the other Anonymous Coward sibling to your post). I'm the type that would do the hormones and surgery immediately if I were able to. But I look too manly and could never look female. Let's just say I've had a shotgun in my mouth a few times but can never get the courage to pull the trigger.
I can definitely see how your gender identity may not be out of sync enough to actually do anything. It's just not how I am.
- Anonymous, because "her" employer knows "her" Slashdot name
WoW has absolutely no gameplay difference between male and female. The stats and items are identical for both genders. Men can even wear the item "White Wedding Dress". =)
/kiss /flirt etc. to either gender no matter yours.
You can also
Melissa
In Vista, programs normally run without admin privileges even when you're supposedly logged on as an administrator. It's much like OS X's handling of administrators, though not at the technical level (NT has no setuid).
The problem is that Microsoft is preventing certain things from happening even when you *are* running as a trusted user. In Vista 64, you *cannot* load an unsigned kernel driver, even if you are a maximum-privileged user mode program. This is retarded, because such a user mode program can take over the system anyway regardless of that.
Melissa
This new kernel patch protection should be viewed as safety against badly coded legitimate drivers, not security against a rootkit.
/dev/hda) from user mode as administrator, a rootkit can simply take over the entire boot process starting with the MBR, and call NtShutdownSystem to force a reboot into the hacked MBR. If using EFI, it's a bit different but still not difficult.
Rootkit authors are some of the best programmers and reverse engineers in the world. Does anyone *really* think that rootkit authors won't find a way around ci.dll? Even Vista 64's requirement that all kernel drivers be signed is a real joke. As long as it is possible to write to \Device\Harddisk0\Partition0 (NT's
All this really prevents are mainstream drivers hooking into the kernel. Companies whose drivers once patched the kernel won't do so anymore, because if you bypass ci.dll publicly, Microsoft will "force" an update onto almost all users within days (or next second Tuesday if you're not important enough). I suppose that this is a good thing - I'm tired of stupid kernel drivers like nProtect and SafeDisc compromising system security and stability just to prevent cheating or copying (respectfully) in some game.
Melissa
If they do something simple like CRC32 as the checksum, then you can simply make a firmware update that has the same checksum as the original...
Melissa
every application that runs on your computer should have its own address space and it should not be allowed to cross into other applications' address spaces, however this is not the case in MS Windows OS.
Nor is it in Linux. A root program or program of the same user can manipulate another process - this is known as "ptrace". It's basically the same as Windows in that respect.
In fact, in Windows NT, the process creation system relies on cross-process memory writing. When a program runs another program, it actually does memory injection into the new process. The NT kernel isn't really aware of things like the user mode stack, the environment, and the command line *. The parent process actually allocates new memory into the new process as the stack, copies its own environment into the new process through injection, and creates the initial thread.
* I just mean that the kernel doesn't manage the user-mode stack. The kernel creates a structure in user memory called the Process Environment Block that points to the environment, but it's not filled in by the kernel.
Melissa
xterm is a user-mode program. A user-mode virus can take over xterm. It will know anything that you type in that terminal, including a sudo password. Once it has that, the virus can do what it wants.
Windows NT does not have this problem, at least as of 6.0: you always type your password in a program that runs as root ("LocalSystem"). Vista's default of not having admin access when logged on as admin is actually going to be a good feature. It'll also encourage developers to require admin to run their word processor.
Melissa
Mario 3 for NES debuted at $75 and that was I think 1989.
Melissa