XP 64 is actually a non-server build of 2003 (NT 5.2), not XP (NT 5.1). I can't tell whether XP 64 is affected, because Microsoft just says this:
"Customers who are running Windows Server 2003 and Windows Server 2003 Service Pack 1 in their default configurations, with the Enhanced Security Configuration turned on, are not affected. Customers would need to visit an attacker's Web site to be at risk. We will continue to investigate these public reports."
For all the legitimate uses of public-key cryptography, I seem to think that most uses of it are bad. I see the Xbox, Xbox 360, Vista, Leopard and Tivo using public-key cryptography for nothing but removing the authority of computer owners to decide what software they run on their computer. I see VeriSign getting rich off the VeriSign Tax.
I personally think that it would be far better to make use of shared-secret systems for when you need communication security, like logging onto banks. The solution to phishing is clearly to use a shared secret system, because things like IE7's anti-phishing filtering can be worked around. SRP6 is great, but unfortunately that is based on public-key technology (though doesn't actually involve a public key, like Diffie-Hellman).
I hope that someday it is proven that public-key cryptography cannot be securely attached to an NP-complete problem, and that either a fast discrete logarithm algorithm (*) is found or quantum computers take off.
(*) A fast solution to the discrete logarithm problem implies a fast solution to integer factorization.
Vista 64's driver signing system is touted as preventing rootkits. Security researchers trust Microsoft that driver signing will help with this. However, as the parent poster says, once code is running at supervisor level it's all over. It's absurd to try to make administrators not administrators. Also, why are corporations magically trusted but not the computer's owner?
The whole thing is really about DRM, protecting wmplayer.exe from debuggers' eyes. (Of course, you could just virtualize the whole OS and dump out data from the sound card that way, regardless of any stupid driver signing...)
I am still angry at Joanna. When she presented at Black Hat, she stated that she was in favor of Vista 64's driver signing, and presenting it was a way to get it fixed. I was incensed, because I'd discovered the same hole independently (before her presentation but after she'd found it), and wanted to wait until after Vista's consumer release to do maximum credibility to Microsoft. I didn't even code it - I described the whole thing in 1 sentence, and any competent NT programmer could have implemented it. On the Xbox Linux Team I fought for years against operating systems' use of digital signatures to restrict whose programs you can run; I wasn't about to help Microsoft do that for Vista.
Guess what the result of her presentation is: user-mode programs, even Administrator/LocalSystem, cannot raw write to disks in Vista. This is going to be loads of fun for disk utilities. Suddenly they have to be made by corporations, and the entire utility must be in kernel mode or it will break the driver signing "security".
Microsoft has already stated their intention on MSDN that in the next version of Windows, only corporation-signed programs will be able to run as Administrator regardless of the wishes of the computer's owner. Microsoft wants to make all PCs into Xbox 360s.
I found two more attacks against their digital signature system, and like hell am I going to tell them (or anyone else). Since I now know it's DRM related, it would be a felony for me to disclose it to anyone but Microsoft, and I'm not going to tell them.
People will use something for whatever suits them best, not what the marketer says to use it for. Clearly slashdotters want to use tags for one-word comments, so that's what they get used for. Music didn't really occur to the inventors of the phonograph, and look how that turned out.
Reading the comments here, I think that most people aren't aware of what PatchGuard is.
PatchGuard, quite simply, is "security through obscurity". Basically, while the kernel is running, a hidden background thread continuously hashes the code sections of the kernel and validates that nothing has changed. If something changes, the system bugchecks (blue screens). PatchGuard's security comes from it being obfuscated.
PatchGuard doesn't offer true security. It has nothing to do with escalation of privilege - if you're able to modify the kernel, it's already too late. PatchGuard was intended to stop commercial products from patching the kernel because frequently they do so improperly, and end up causing instability and local privilege elevation exploits. If a company got around PatchGuard, their product would only work until the next second Tuesday. However, rootkit authors may not care about that "time limit".
Certainly PatchGuard helps slightly with DRM. However its more important use is preventing companies from doing improper kernel hacks. With Microsoft bowing to these companies, PatchGuard's only use is now DRM.
By the way, the only reason Microsoft is doing this is because of Europe's antitrust complaints. No full page ad will convince Microsoft of anything.
Reading the comments here, I think that most people aren't aware of what PatchGuard is.
PatchGuard, quite simply, is "security through obscurity". Basically, while the kernel is running, a hidden background thread continuously hashes the code sections of the kernel and validates that nothing has changed. If something changes, the system bugchecks (blue screens). PatchGuard's security comes from it being obfuscated.
PatchGuard doesn't offer true security. It has nothing to do with escalation of privilege - if you're able to modify the kernel, it's already too late. PatchGuard was intended to stop commercial products from patching the kernel because frequently they do so improperly, and end up causing instability and local privilege elevation exploits. If a company got around PatchGuard, their product would only work until the next second Tuesday. However, rootkit authors may not care about that "time limit".
Certainly PatchGuard helps slightly with DRM. However its more important use is preventing companies from doing bad kernel hacks. With Microsoft bowing to these companies, PatchGuard's only use is now DRM. Now I dislike it.
There needs to be a way to have SRP6 authentication for HTTP. One of the reasons that phishing is so easy is because the server never proves to the client that it knows your password (or a hash of it). SRP6 authenticates in both directions without revealing the password hash to an eavesdropper, or to an impostor client or server. Combined with a secure password entry dialog box that can't be spoofed, this would do a lot to prevent phishing.
Note that SSL alone is not enough to combat the problem. There exist phishing sites with valid SSL certificates. Sure, the domain name is different in the address bar, but phishing would never work if users actually read the address bar to begin with.
The best would be SRP over SSL, although this is quite expensive because it would require double the number of large-exponent modular exponentiations on the server side.
It's trivially easy to prevent Intel's VT from being able to emulate your OS. There's likely a way to detect the VM based on this. Just put the CPU into so-called unreal mode, because Intel's virtualization cannot handle it.
Unlike Intel, AMD's virtualization supports real mode and the segment descriptor cache holding nonstandard values.
You may install unsigned kernel drivers, but your Video Path no longer counts as Protected and you may not play DRM'd disks.
You may not install unsigned kernel drivers on Vista 64.
Vista is not "full" or "riddled" with DRM.
Vista has the ability to mark a process as "protected". Such processes cannot be tampered with by anything, regardless of privilege level. The only right granted to administrators to such processes are "terminate" and "set priority". The kernel, in ci.dll ("Code Integrity"), continuously hashes the code pages of all such protected user processes. If any page changes, the kernel immediately bugchecks. This mechanism is severely obfuscated so as to make it difficult to work around. The mechanism has absolutely no value to preventing malware; in fact, it gives an opportunity for malware to hide if they can get around the digital signature requirements.
It seems rather biased to me to say that we can have America's Army and (the original) Counter-Strike but they can't make their own games that put them in a good light instead of us. If you don't like what they're "saying" in the game, don't play it.
Besides, I'd rather them kill American soldiers and presidents in a video game than in real life.
The FSF doesn't need to convince Linus and the other kernel developers. All they really need to do is make everything *but* the kernel GPLv3. Linux is not very useful without bash or a number of other programs.
Another trick would be to put glibc under an LGPLv3 that has the same restriction on software signing systems.
Switch lobbying efforts to trying to get Samba to use GPLv3.
The endgame of the Trusted Computing fight is that within a few years an operating system that isn't TCG-signed will not be able to fully access the Internet, with various games, web sites, and DRM systems refusing access to "untrusted" operating systems. Linux will exist, but only the large corporations will be able to build it.
The chart is missing the most valuable game of all: Earthbound for NES. Unlike other prototypes, that one had the final ROM image. It was approved for release but marketing did not want to (see Wikipedia).
By the way, I thought there were a lot of those Star Fox competition cartridges. Is this some special version that also had Donkey Kong Country?
I dislike Microsoft, but I like Windows NT much more than Linux. Win32 is crap, but the NT kernel is great. NT's security model is much better than Linux's. Note that this is the model; NT being insecure is not because of its model.
Privilege separation - essentially having different types of "root" - is something NT does better than Linux. NT has the concept of "privileges". Privileges are special flags that "tokens" may have. (A token is a set of security credentials assigned to a process; compare to UID and GID in UNIX.) Each privilege grants its holder the ability to override one feature of the security system.
Some examples of privilege: - "Backup": Able to read any file on the system regardless of ACLs. - "Restore": Able to set file ownership to anyone, not just themselves. - "Take ownership": Able to take ownership of any file, which grants the right to change the ACLs. - "Debug": Able to do the equivalent of ptrace() on any process regardless of ACLs. - "Load driver": Able to load kernel driver. - "Lock pages": Able to lock memory pages (prevent swapping to disk). - "Create token": Able to create tokens, basically allowing forging of credentials (this is how processes get tokens).
There is an account called "SYSTEM" that is considered to have all privileges. However, in general you want to avoid this for obvious reasons. You create an account for the service with these privileges. Trusted services don't have to always be root when they do special things.
However, there is always the problem that certain privileges are privilege-complete: they can be leveraged to gain all privileges. "Create token" makes it easy to become a SYSTEM process. "Load driver" is obvious. "Debug" lets you inject machine code into privileged processes like winlogon.exe. Thus, this privilege system can become a safety system instead of a security system. Likewise, "limited root" in UNIX is an arcane way of doing the same thing, and has the same issues.
I hope this comparison with another OS helps with understanding the many issues brought up. Limiting root is like making water not wet. Or radium not radioactive, if you want to say that you can make water not wet.
Both Microsoft and Firefox find security bugs in their own software from time to time. However, they differ widely in what they will do once they find out this information.
Unless Microsoft sees that someone else knows the bug, they won't release a patch. They will fix it in the source tree for the next major release, but they will not release a patch for the current version. They do this because when they release a patch, security researchers, both good and bad, will do a "BinDiff" and find out what exploit they've fixed. Bad people will then use that bug on unpatched users. If a bug isn't externally rediscovered before the release of the next major version, it's kept secret forever. You can't bindiff major releases, because there's too many changes.
Firefox, in contrast, will generally release a patch for the current version, even if only the Firefox security team knew about it.
Under these circumstances, of course Firefox will have more listed exploits.
NtCreateFile on \Device\Harddisk0\Partition0, NtWriteFile 512 bytes, NtShutdownSystem to reboot.
However, BitLocker prevents this attack: the contents of the disk would be unreadable garbage to a fake MBR because it would not pass the TPM's signature check.
I am still angry at Joanna Rutkowska for publicizing the page file attack against the driver signing, because Microsoft has now made the kernel and drivers nonpageable. I came up with the same method independently and wanted to wait until Vista was released to demonstrate it to do maximum damage to Microsoft's credibility.
Unfortunately, because it's now known that the driver signing system is tied to DRM, it is illegal to work around it in the United States under the DMCA.
The option to disable driver signing protection permanently will not be in the final version of Vista. The only option to disable it will be pressing F8 every time you boot the system and select that option.
There is something called "test signing", but this is a pain to enable. Also, if either test signing is enabled or driver signature checking is disabled, Windows Media Player refuses to play protected songs and movies. Protection against rootkits my ass.
"JUSTIN BAILEY -------- --------" just happens to be a valid password by the game's password checksum algorithm. The state of the game you get just happens to be what matches the setting of those bitflags. I would guess that a player named Justin Bailey tried this and found it worked well - and no other password at the time was known to allow a suitless Samus. In modern times, a password is known that gives you a suitless Samus at the starting point with no power-ups.
There is only one special-cased Metroid password: "NARPAS SWORD0 000000 000000", probably meaning "Narihiro's password". It gives you infinite life and ammo, and was not discovered until the assembly code behind the password system was analyzed.
...they've probably had a fix for a month but have spent the rest of the time scrambling the executable so you can't "bindiff" them to figure out what has been changed.
Microsoft won't release a patch for a flaw they find themselves until someone else finds it because of the bindiff risk. They typically just fix it in the next OS, which you can't bindiff anyway because they're too different.
Why can't we use SRP6 for authentication? In SRP6, in addition to the client proving to the server that it knows the password, the server proves to the client that it knew the password as well (or rather a hash of the password). The server does not end up knowing the client's password either. This makes it basically impossible to set up a phishing site from a technical standpoint. It's also impossible to do a man-in-the-middle attack, because the client and server exchange a nonce to use for following encryption.
The only risk is setting up a web form that looks like the real thing, but actually passes the password as plaintext to the server instead of using SRP. For this, you can modify the web browser to show an unfakeable screen when you are trying to use SRP to log in. If you attempt an SRP logon to a fake server, the only information the site learns is your username.
Getting Microsoft to implement something is basically impossible, but Firefox, Opera and Safari would be much easier. The banks could recommend Firefox to their customers.
Copyright existed in 1913. Theft existed in 1913. It wasn't called theft then, and it isn't called theft now. If you really have to, go find a modern law dictionary.
If you look at Firefox security bugs and IE security bugs, you'll see that there are more Firefox bugs than MSIE bugs in the exploit lists. There is, however, a big difference.
When Microsoft finds a security hole themselves, they don't tell anyone, and they don't release a patch. They fix it in the tree for the next release of the OS. The only time they release a patch is when someone else finds the bug. The reason they do this is because if they release a patch, people will "bindiff" it against the previous version and find what is changed so that they can make exploits to use against unpatched users. You can't realistically "bindiff" XP vs. Vista, so they can obscure their security updates inside Vista.
Firefox instead will issue patches no matter who finds them. This is why Firefox appears to have more bugs - you always see them get fixed.
I think eventually laptops will be banned from planes - even in checked baggage. Batteries these days are basically spontaneously flammable, and you can't allow that on a plane. It wouldn't be very hard for terrorists to rig laptops with batteries that short themselves at a certain altitude. Get a bunch of terrorists to fly together and have a bunch of rigged laptops in the luggage, and you have a nice probability of starting a big fire in the cargo hold.
Not to mention that the fire risk is bad enough by accident.
XP 64 is actually a non-server build of 2003 (NT 5.2), not XP (NT 5.1). I can't tell whether XP 64 is affected, because Microsoft just says this:
"Customers who are running Windows Server 2003 and Windows Server 2003 Service Pack 1 in their default configurations, with the Enhanced Security Configuration turned on, are not affected. Customers would need to visit an attacker's Web site to be at risk. We will continue to investigate these public reports."
I'm on XP 64 SP1, equivalent to 2003 SP1.
Melissa
For all the legitimate uses of public-key cryptography, I seem to think that most uses of it are bad. I see the Xbox, Xbox 360, Vista, Leopard and Tivo using public-key cryptography for nothing but removing the authority of computer owners to decide what software they run on their computer. I see VeriSign getting rich off the VeriSign Tax.
I personally think that it would be far better to make use of shared-secret systems for when you need communication security, like logging onto banks. The solution to phishing is clearly to use a shared secret system, because things like IE7's anti-phishing filtering can be worked around. SRP6 is great, but unfortunately that is based on public-key technology (though doesn't actually involve a public key, like Diffie-Hellman).
I hope that someday it is proven that public-key cryptography cannot be securely attached to an NP-complete problem, and that either a fast discrete logarithm algorithm (*) is found or quantum computers take off.
(*) A fast solution to the discrete logarithm problem implies a fast solution to integer factorization.
Melissa
Vista 64's driver signing system is touted as preventing rootkits. Security researchers trust Microsoft that driver signing will help with this. However, as the parent poster says, once code is running at supervisor level it's all over. It's absurd to try to make administrators not administrators. Also, why are corporations magically trusted but not the computer's owner?
The whole thing is really about DRM, protecting wmplayer.exe from debuggers' eyes. (Of course, you could just virtualize the whole OS and dump out data from the sound card that way, regardless of any stupid driver signing...)
I am still angry at Joanna. When she presented at Black Hat, she stated that she was in favor of Vista 64's driver signing, and presenting it was a way to get it fixed. I was incensed, because I'd discovered the same hole independently (before her presentation but after she'd found it), and wanted to wait until after Vista's consumer release to do maximum credibility to Microsoft. I didn't even code it - I described the whole thing in 1 sentence, and any competent NT programmer could have implemented it. On the Xbox Linux Team I fought for years against operating systems' use of digital signatures to restrict whose programs you can run; I wasn't about to help Microsoft do that for Vista.
Guess what the result of her presentation is: user-mode programs, even Administrator/LocalSystem, cannot raw write to disks in Vista. This is going to be loads of fun for disk utilities. Suddenly they have to be made by corporations, and the entire utility must be in kernel mode or it will break the driver signing "security".
Microsoft has already stated their intention on MSDN that in the next version of Windows, only corporation-signed programs will be able to run as Administrator regardless of the wishes of the computer's owner. Microsoft wants to make all PCs into Xbox 360s.
I found two more attacks against their digital signature system, and like hell am I going to tell them (or anyone else). Since I now know it's DRM related, it would be a felony for me to disclose it to anyone but Microsoft, and I'm not going to tell them.
Melissa
They know that the only way to win is to use mathematics, because it simply does not matter how smart you are.
Melissa
People will use something for whatever suits them best, not what the marketer says to use it for. Clearly slashdotters want to use tags for one-word comments, so that's what they get used for. Music didn't really occur to the inventors of the phonograph, and look how that turned out.
Melissa
Reading the comments here, I think that most people aren't aware of what PatchGuard is.
PatchGuard, quite simply, is "security through obscurity". Basically, while the kernel is running, a hidden background thread continuously hashes the code sections of the kernel and validates that nothing has changed. If something changes, the system bugchecks (blue screens). PatchGuard's security comes from it being obfuscated.
PatchGuard doesn't offer true security. It has nothing to do with escalation of privilege - if you're able to modify the kernel, it's already too late. PatchGuard was intended to stop commercial products from patching the kernel because frequently they do so improperly, and end up causing instability and local privilege elevation exploits. If a company got around PatchGuard, their product would only work until the next second Tuesday. However, rootkit authors may not care about that "time limit".
Certainly PatchGuard helps slightly with DRM. However its more important use is preventing companies from doing improper kernel hacks. With Microsoft bowing to these companies, PatchGuard's only use is now DRM.
By the way, the only reason Microsoft is doing this is because of Europe's antitrust complaints. No full page ad will convince Microsoft of anything.
Melissa
Reading the comments here, I think that most people aren't aware of what PatchGuard is.
PatchGuard, quite simply, is "security through obscurity". Basically, while the kernel is running, a hidden background thread continuously hashes the code sections of the kernel and validates that nothing has changed. If something changes, the system bugchecks (blue screens). PatchGuard's security comes from it being obfuscated.
PatchGuard doesn't offer true security. It has nothing to do with escalation of privilege - if you're able to modify the kernel, it's already too late. PatchGuard was intended to stop commercial products from patching the kernel because frequently they do so improperly, and end up causing instability and local privilege elevation exploits. If a company got around PatchGuard, their product would only work until the next second Tuesday. However, rootkit authors may not care about that "time limit".
Certainly PatchGuard helps slightly with DRM. However its more important use is preventing companies from doing bad kernel hacks. With Microsoft bowing to these companies, PatchGuard's only use is now DRM. Now I dislike it.
Melissa
There needs to be a way to have SRP6 authentication for HTTP. One of the reasons that phishing is so easy is because the server never proves to the client that it knows your password (or a hash of it). SRP6 authenticates in both directions without revealing the password hash to an eavesdropper, or to an impostor client or server. Combined with a secure password entry dialog box that can't be spoofed, this would do a lot to prevent phishing.
Note that SSL alone is not enough to combat the problem. There exist phishing sites with valid SSL certificates. Sure, the domain name is different in the address bar, but phishing would never work if users actually read the address bar to begin with.
The best would be SRP over SSL, although this is quite expensive because it would require double the number of large-exponent modular exponentiations on the server side.
Melissa
It's trivially easy to prevent Intel's VT from being able to emulate your OS. There's likely a way to detect the VM based on this. Just put the CPU into so-called unreal mode, because Intel's virtualization cannot handle it.
Unlike Intel, AMD's virtualization supports real mode and the segment descriptor cache holding nonstandard values.
Melissa
You may not install unsigned kernel drivers on Vista 64.
Vista has the ability to mark a process as "protected". Such processes cannot be tampered with by anything, regardless of privilege level. The only right granted to administrators to such processes are "terminate" and "set priority". The kernel, in ci.dll ("Code Integrity"), continuously hashes the code pages of all such protected user processes. If any page changes, the kernel immediately bugchecks. This mechanism is severely obfuscated so as to make it difficult to work around. The mechanism has absolutely no value to preventing malware; in fact, it gives an opportunity for malware to hide if they can get around the digital signature requirements.
If this isn't DRM, what is?
Melissa
It seems rather biased to me to say that we can have America's Army and (the original) Counter-Strike but they can't make their own games that put them in a good light instead of us. If you don't like what they're "saying" in the game, don't play it.
Besides, I'd rather them kill American soldiers and presidents in a video game than in real life.
Melissa
The worst part about Vista 64 is you need signed drivers. Not a single XP64 driver will work, even if it would work were it able to load.
Melissa
The FSF doesn't need to convince Linus and the other kernel developers. All they really need to do is make everything *but* the kernel GPLv3. Linux is not very useful without bash or a number of other programs.
Another trick would be to put glibc under an LGPLv3 that has the same restriction on software signing systems.
Switch lobbying efforts to trying to get Samba to use GPLv3.
The endgame of the Trusted Computing fight is that within a few years an operating system that isn't TCG-signed will not be able to fully access the Internet, with various games, web sites, and DRM systems refusing access to "untrusted" operating systems. Linux will exist, but only the large corporations will be able to build it.
Melissa
The chart is missing the most valuable game of all: Earthbound for NES. Unlike other prototypes, that one had the final ROM image. It was approved for release but marketing did not want to (see Wikipedia).
By the way, I thought there were a lot of those Star Fox competition cartridges. Is this some special version that also had Donkey Kong Country?
meow
I dislike Microsoft, but I like Windows NT much more than Linux. Win32 is crap, but the NT kernel is great. NT's security model is much better than Linux's. Note that this is the model; NT being insecure is not because of its model.
Privilege separation - essentially having different types of "root" - is something NT does better than Linux. NT has the concept of "privileges". Privileges are special flags that "tokens" may have. (A token is a set of security credentials assigned to a process; compare to UID and GID in UNIX.) Each privilege grants its holder the ability to override one feature of the security system.
Some examples of privilege:
- "Backup": Able to read any file on the system regardless of ACLs.
- "Restore": Able to set file ownership to anyone, not just themselves.
- "Take ownership": Able to take ownership of any file, which grants the right to change the ACLs.
- "Debug": Able to do the equivalent of ptrace() on any process regardless of ACLs.
- "Load driver": Able to load kernel driver.
- "Lock pages": Able to lock memory pages (prevent swapping to disk).
- "Create token": Able to create tokens, basically allowing forging of credentials (this is how processes get tokens).
There is an account called "SYSTEM" that is considered to have all privileges. However, in general you want to avoid this for obvious reasons. You create an account for the service with these privileges. Trusted services don't have to always be root when they do special things.
However, there is always the problem that certain privileges are privilege-complete: they can be leveraged to gain all privileges. "Create token" makes it easy to become a SYSTEM process. "Load driver" is obvious. "Debug" lets you inject machine code into privileged processes like winlogon.exe. Thus, this privilege system can become a safety system instead of a security system. Likewise, "limited root" in UNIX is an arcane way of doing the same thing, and has the same issues.
I hope this comparison with another OS helps with understanding the many issues brought up. Limiting root is like making water not wet. Or radium not radioactive, if you want to say that you can make water not wet.
Melissa
Both Microsoft and Firefox find security bugs in their own software from time to time. However, they differ widely in what they will do once they find out this information.
Unless Microsoft sees that someone else knows the bug, they won't release a patch. They will fix it in the source tree for the next major release, but they will not release a patch for the current version. They do this because when they release a patch, security researchers, both good and bad, will do a "BinDiff" and find out what exploit they've fixed. Bad people will then use that bug on unpatched users. If a bug isn't externally rediscovered before the release of the next major version, it's kept secret forever. You can't bindiff major releases, because there's too many changes.
Firefox, in contrast, will generally release a patch for the current version, even if only the Firefox security team knew about it.
Under these circumstances, of course Firefox will have more listed exploits.
Melissa
NtCreateFile on \Device\Harddisk0\Partition0, NtWriteFile 512 bytes, NtShutdownSystem to reboot.
However, BitLocker prevents this attack: the contents of the disk would be unreadable garbage to a fake MBR because it would not pass the TPM's signature check.
I am still angry at Joanna Rutkowska for publicizing the page file attack against the driver signing, because Microsoft has now made the kernel and drivers nonpageable. I came up with the same method independently and wanted to wait until Vista was released to demonstrate it to do maximum damage to Microsoft's credibility.
Unfortunately, because it's now known that the driver signing system is tied to DRM, it is illegal to work around it in the United States under the DMCA.
Melissa
The option to disable driver signing protection permanently will not be in the final version of Vista. The only option to disable it will be pressing F8 every time you boot the system and select that option.
There is something called "test signing", but this is a pain to enable. Also, if either test signing is enabled or driver signature checking is disabled, Windows Media Player refuses to play protected songs and movies. Protection against rootkits my ass.
Melissa
"JUSTIN BAILEY -------- --------" just happens to be a valid password by the game's password checksum algorithm. The state of the game you get just happens to be what matches the setting of those bitflags. I would guess that a player named Justin Bailey tried this and found it worked well - and no other password at the time was known to allow a suitless Samus. In modern times, a password is known that gives you a suitless Samus at the starting point with no power-ups.
There is only one special-cased Metroid password: "NARPAS SWORD0 000000 000000", probably meaning "Narihiro's password". It gives you infinite life and ammo, and was not discovered until the assembly code behind the password system was analyzed.
Melissa
...they've probably had a fix for a month but have spent the rest of the time scrambling the executable so you can't "bindiff" them to figure out what has been changed.
Microsoft won't release a patch for a flaw they find themselves until someone else finds it because of the bindiff risk. They typically just fix it in the next OS, which you can't bindiff anyway because they're too different.
Melissa
Why can't we use SRP6 for authentication? In SRP6, in addition to the client proving to the server that it knows the password, the server proves to the client that it knew the password as well (or rather a hash of the password). The server does not end up knowing the client's password either. This makes it basically impossible to set up a phishing site from a technical standpoint. It's also impossible to do a man-in-the-middle attack, because the client and server exchange a nonce to use for following encryption.
The only risk is setting up a web form that looks like the real thing, but actually passes the password as plaintext to the server instead of using SRP. For this, you can modify the web browser to show an unfakeable screen when you are trying to use SRP to log in. If you attempt an SRP logon to a fake server, the only information the site learns is your username.
Getting Microsoft to implement something is basically impossible, but Firefox, Opera and Safari would be much easier. The banks could recommend Firefox to their customers.
Melissa
Copyright existed in 1913. Theft existed in 1913. It wasn't called theft then, and it isn't called theft now. If you really have to, go find a modern law dictionary.
Melissa
If you look at Firefox security bugs and IE security bugs, you'll see that there are more Firefox bugs than MSIE bugs in the exploit lists. There is, however, a big difference.
When Microsoft finds a security hole themselves, they don't tell anyone, and they don't release a patch. They fix it in the tree for the next release of the OS. The only time they release a patch is when someone else finds the bug. The reason they do this is because if they release a patch, people will "bindiff" it against the previous version and find what is changed so that they can make exploits to use against unpatched users. You can't realistically "bindiff" XP vs. Vista, so they can obscure their security updates inside Vista.
Firefox instead will issue patches no matter who finds them. This is why Firefox appears to have more bugs - you always see them get fixed.
Melissa
I think eventually laptops will be banned from planes - even in checked baggage. Batteries these days are basically spontaneously flammable, and you can't allow that on a plane. It wouldn't be very hard for terrorists to rig laptops with batteries that short themselves at a certain altitude. Get a bunch of terrorists to fly together and have a bunch of rigged laptops in the luggage, and you have a nice probability of starting a big fire in the cargo hold.
Not to mention that the fire risk is bad enough by accident.
Melissa
Nothing, he was replaced by grub.