Windows Security: Path Interpretation

I've come across this MSDN article, which talks about how Windows interprets paths:
http://msdn.microsoft.com/en-us/library/aa365247%28v=vs.85%29.aspx

Why is this a security concern?
Let's say you have an application that allows a user to write a file path as input, and to get the content of the file as output. You want to restrict access to a specific file, let's say:

c:\secret location\passwords.txt

This code is a possible way of writing such functionality:

Code:

string GetFile(string path)
{
	if (isok(path))
	{
		return System.IO.File.ReadAllText(path);
	}
	else
	{
		throw new Exception("Access denied");
	}
}

Maybe the best option is limiting the permissions of the application so it can't access the file, but then what about a web server that needs to hide .htaccess from the user but must be able to read it?
So maybe you choose another option - examining the file path.
For example:

Code:

bool isok(string path)
{
	return path != @"c:\secret location\passwords.txt";
	// THIS CODE IS WRONG
}

But then an attacker could use uppercase or mixed to represent the same file:

Code:

GetFile(@"C:\SECRET LOCATION\PASSWORDS.TXT");
GetFile(@"C:\SeCrEt LoCaTiOn\PaSsWoRdS.TxT");

So maybe this might be a possible fix:

Code:

bool isok(string path)
{
	return path.ToLower() != @"c:\secret location\passwords.txt";
	// THIS CODE IS WRONG
}

Unfortunately this code isn't sufficient either, what about:

Code:

GetFile(@"c:\aaaa\..\secret location\passwords.txt");

Note that it works even if aaaa doesn't exist.
This can go on and on. I tried to put some of those "path features" in the following list.

1. Normal: @"c:\secret location\passwords.txt"
2. Upper/lower case: @"C:\Secret Location\Passwords.TxT"
3. Parent directory: @"c:\aaa\..\secret location\passwords.txt"
4. Current directory: @"c:\.\secret location\passwords.txt"
5. Current file: @"c:\secret location\passwords.txt\."
6. Spaces: @"c:\secret location\passwords.txt   "
7. Dots: @"c:\secret location\passwords.txt...."
8. Network share: @"\\localhost\c$\secret location\passwords.txt"
   or <ip_address> or <computer_name> or 127.0.0.1
9. Long path prefix: @"\\?\c:\secret location\passwords.txt"
10. MS-DOS style: @"C:\SECRET~1\PASSWO~1.TXT"
11. Relative path: @"c:secret location\passwords.txt"
    (Works if current directory is c:\, otherwise need to add ..)
12. Win32 device: @"\\.\c:\secret location\passwords.txt"
13. Long UNC: @"\\?\UNC\localhost\c$\secret location\passwords.txt"
14. ADS: @"c:\secret location\passwords.txt::$DATA"
15. Unix style: @"c:/secret location\passwords.txt"

Go on, try some of them!
There are probably many more ways that aren't on that list.
For conclusion, restricting access to a file simply by examining the input path is probably a bad idea. An alternative better solution should be chosen depending on the project requirements.

Tabnapping - A New Type of Phishing Attack

I admit that before I saw this video I could have been easily fooled by this attack...

http://www.azarask.in/blog/post/a-new-type-of-phishing-attack/


A New Type of Phishing Attack from Aza Raskin on Vimeo.

Windows 7 & HomeGroup: Sharing with Windows XP, Windows Vista, and other operating systems

http://www.microsoft.com/downloads/details.aspx?FamilyID=80b1aa5d-1b5a-4447-8036-acc918ba7af2&displaylang=en

Windows 7 - Remove User From Login Screen

The users on the log-in screen are all the users that belong to the "Users" group.

To remove a user invoke the following command:

  net localgroup users /delete <username>

Instead, on Windows 7 Ultimate and Professional, you can use the User Manager to do that:

Installing Windows XP Professional on HP Compaq nx6310

Four years ago I bought HP laptop nx6310. It came with Windows XP Pro already installed.
Today I reinstalled Windows, but it wasn't as smooth as I thought it would be.
First, Windows setup didn't recognize any hard disk:
"setup did not find any hard disk installed in your computer…"
After searching Google a bit, I found out that I should disable SATA on the Bios.
I disabled it, and continued setup until:
"Windows could not start because the following file is missing or corrupt C:\Windows\inf\Biosinfo.inf"
This time it was a bit harder, because all the solutions I found on the Internet suggested I should get SP2 and it will be solved by itself, because it has all the missing drivers. The only problem is that I already had SP2. Some sites offered to download an installation with all the needed drivers built-in. But I couldn't use it because I want to install Windows in Hebrew.
In the end, the solution was very simple, I went to the place on the Bios where I recently disabled SATA, and I disabled everything else.
It worked. Windows is now installed.
Drivers were downloaded from here:
http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareIndex.jsp?lang=en&cc=us&prodNameId=1839164&prodTypeId=321957&prodSeriesId=1839143&swLang=8&taskId=135&swEnvOID=1093
The only problem is I wanted to re-enable all the features I disabled, and I couldn't enable SATA without crashing Windows. So I found this post: http://mytechweblog.blogspot.com/2007/10/enabling-sata-native-mode-after-xp.html. The author forgot to mention something, but he did mention it here: http://forums13.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=1057792&admit=109447627+1258968594947+28353475, so it's better to follow the second link. Note that after following the instructions on the link you must re-enable SATA otherwise Windows won't load.
It works! :)

Telnet on Windows 7

By default Telnet is not installed on Windows7 and you get this error message:

'telnet' is not recognized as an internal or external command,

operable program or batch file.

Solution:
Turn on this feature in Control Panel as explained here:
http://www.tech-recipes.com/rx/4230/windows-7-install-the-telnet-client/

I found a link that explains the list of features for Windows Vista. Most of it is relevant to Windows 7 too:
http://www.bleepingcomputer.com/tutorials/tutorial134.html