Slashdot Mirror
SecurityFocus On MS Security "Hole"
friday2k writes "There is an interesting writeup at SecurityFocus that puts the latest security 'hole' in XP into perspective. It is a worthy read and should remind us all of the real issues out there." And it collects into one place much of the flak I caught after posting about the claimed security hole opened by the XP Recovery Console.
This appears to be a problem using the win2k recovery console on a winxp install, not the XP console.
And all it allows you to do is copy files around. Whoopty do. Pop in a linux boot floppy with ntfs support and do the same thing, only easier (because the win2k recovery console doesn't support wildcarding; lame.)
Reread the original article -- the password for EFS eencrypted files is tied to the user's password. If a user is part of a Workgroup, not a domain (think "laptop, remote user") then you can change the password locally and unencrypt the files.
Learning HOW to think is more important than learning WHAT to think.
This isn't a security flaw.
This is desired administration behavior. The Win2k disc can't deal with the WinXP registry properly, so it goes straight to recovery mode. Recovery mode is pretty much useless to begin with, and you can't really do anything to a system in recovery mode
Besides, if you can physically walk up to the computer in question and boot it from a CD in your pocket, your security problem doesn't come from Windows - it either comes from a BIOS that doesn't support changing the boot order, or it comes from between your ears.
Here's a sample of Mr. Mullen's "unbiased" approach to Microsoft security:
http://www.securityfocus.com/columnists/127
Paper Pusher
So what's the deal? You see an article with "Windows" or "Microsoft" and "hole" or "exploit" or "fundies" and you automatically hit reply and type in some snively childish remark to whore some karma? Or are you just plain bored?
Yes, but one would still:
Step 3: Set BIOS password
Step 4: Disable floppy and CD boot
etc.
etc.
and restrict physical access.
Same difference.
If this is a hole then so is the fact I can mount your ex2fs /home partition from a boot floppy and ftp all the filez there to whereever I want them to reside. Actually the linux "hole" is worse, as it has infinitely more powerful command-line tools available to a bootflopper.
/]% rm /*/* on my way out. Know your enemy, he's probably a family member.
People fear the Internet and what a hax0r could do to their PC, but (as this article proves) give me physical access to your machine and I could do more damage to you than 99.999% of crackers ever possibly could - and that's only because I'm not enough of a bastard to [root@localhost
-Mark
Problem is, we're talking about Windows XP, so Mr. Pfeil is wrong.
Assuming one can get Admin access to the installed OS (re-installing OS destroys access to EFS-protected files), resetting the password on WinXP in a Workgroup (as opposed to changing it) destroys access to DPAPI-protected keys, and hence access to EFS-protected files.
Win2000 EFS is vulnerable to this sort of attack, but not WinXP.
With WinXP, an attacker should endeavor to crack the user's password rather than change it to a known value. Even so, this attack can be mitigated by a) using strong passwords, and b) using SYSKEY to protect the SAM from offline attack.
Other notes:
1) EFS was principally designed to protect data when the hardware has been compromised, so the premise of this whole comment is wrong.
2) EFS is one layer of defense-in-depth. It should be combined with strong passwords, SYSKEY, and proper recovery key management.
3) Windows XP Key security is discussed here.
4) EFS does not support keys on removeable devices as of WinXP.
In a domain, the Administrator account for the forest root domain is the recovery agent. Additional recovery agents can be assigned through the domain group policy object. The certificates are self-signed if no CA (Certificate Authority) is configured. Any recovery agent should export the private key to removable media and lock it up in a secure place and keep another secured copy off site. Delete the copy from the forest root's first domain controller.
On a stand alone server or workstation (Not a member of a domain), a self signed certificate is generated for use and the local Administrator account is the recovery agent. The private keys for the administrator and your own user account can be exported to a floppy or other removable media and deleted off the computer. Another copy should be kept in another secured location in case the first gets burned down, stolen, corrupt, etc. Make sure the floppy isn't in the laptop carrying case, otherwise, the theif will have your private key when he takes the whole bag.
Another important thing to note is that the document is decrypted in memory and a clear text copy isn't put on the drive. A hacker going through your drive, looking for deleted temp files will be wasting time. If you want to be extra paranoid, configure windows to clear the page file at shutdown.
For more reading:
Click Here
If you really want to learn this stuff, read this book. I found it to be extremely educational and was the only book to explain certificate server to me effectively.
Click Here
-Lucas
Windows NT and 2000 MCSE
If someone can boot from a configuration other than the default OS, they have free reign
I've seen one PC based O/S do this correctly. OS/2. Don't laugh, but I learned the hard way one weekend at a finacial services firm. It seems the OS/2 HPFS386 (comes with OS/2 server) driver uses a combination ACL+Hardware code to encrypt the drive. We were upgrading an old server to a new one and just moved the data drive over to the new box. Nada, zilch, nothing. The computer saw the drive but none of the contents. It didn't matter what we did, (rescue disk, etc.) we couldn't see the file system.
To make a long story short (what was supposed to take two hours took eight), we had to put the drive back into the original box and run a special administrators tool (separate locked away disk) to remove the ACL's from the file system. Only then could we move the drive to the new server and re-apply the ACL's. Not a fun weekend.
Enjoy,
It's just the normal noises in here.
> Is there user-level security in OS X
> similar to Unix?
Yes
> Does the user have to enter a root password to
> do admin tasks like adding new software?
Yes (actually: a password for the 'wheel' group; the standard installation does not even enable root as login)
> correct me if I'm wrong
You are.