Skip navigation

.NET UPDATE--May 29, 2003

1. Commentary: Passport Plans Tempered by Security Flaw

Later this summer, Microsoft will unleash a completely new version of its .NET Passport online authentication service. The new version reveals Passport's functionality as XML Web services, a potentially exciting upgrade that should dramatically expand support for this little-used service. But a new security vulnerability in .NET Passport exposed earlier this month threatens to undo months of goodwill the company had built up through its Trustworthy Computing initiative. The security threat raises new questions about the viability of a single sign-on (SSO) service that operates on the public Internet.

The vulnerability, which a Pakistani security consultant found in Passport's password recovery functionality, is surprisingly obvious, which makes its existence all the more frustrating, especially considering that Passport sits at the center of Microsoft's plans for .NET. When a Passport user--typically a Hotmail user--wants to change his password, Microsoft sends that user an automatically generated URL that includes the user's email address in the URL. By replacing the email address with any valid Passport account email address, someone could reset the password for any Passport account on the planet.

Because all Passport accounts contain some personal data, and some include credit card information, this flaw could have been serious. Microsoft corrected the vulnerability before hackers could do much damage, although the company initially had to take the heavy-handed step of preventing users from changing their passwords until it could develop a solution. However, the consultant who found the flaw says he did so after a friend's Passport account was hacked and that the flaw has existed for years. Most alarming, the consultant told CNET that he repeatedly tried to warn Microsoft about the flaw by emailing Hotmail's security and abuse reporting addresses. When he received no reply and Microsoft didn't fix the flaw, he posted information about the flaw to a security mailing list. At that point, Microsoft responded within hours.

How the security flaw affects Passport is unclear. Microsoft has touted the service as the nexus of its .NET strategy, and the company will soon launch enterprisewide presence information based on the technology through its Real-Time Communications (RTC) Server product. Microsoft will update RTC in later versions to provide cross-company federation services that will let users check one another's presence information regardless of where--or how--those users are connected to the Internet. RTC Server is one of the products that emerged in the wake of Microsoft's failed .NET My Services, which would have let corporations provide and access presence and other information that the Passport service made available. Microsoft scrapped the My Services project when customers told the company that they want to control that information themselves.

A more recent problem, however, is Passport itself, which will soon be completely revamped as a .NET Web service. This version of Passport will work with new security standards such as WS-Security to provide encryption and digital signature capabilities. Microsoft says that by making Passport's services available as XML Web services, the company is essentially opening Passport's capabilities to a far wider range of third-party applications and services. Doing so will also speed application development time. So, theoretically, if Amazon.com wanted to let its users integrate with the wider Passport system to provide credit-card or shipping-address information, the task would be simpler and safer.

Because I've been traveling in Europe, I haven't been able to discuss the .NET-based product changes with Microsoft and determine whether the recent security vulnerability affects delivery of the next Passport version. I'll have an answer before the next issue of .NET UPDATE hits the street.

2. .NET Tech: "Just-in-Time" Compiling and .NET

I've mentioned "just-in-time" (JIT) compiling in passing in previous columns. Now let's talk more about how JIT compiling works.

Computers don't speak VBScript, C#, or any other high-level programming language. To let a computer understand what you're telling it, the code must be interpreted (as scripting languages such as VBScript are) or compiled. The act of compiling transforms source code into object code, which is similar to the machine language that a computer understands. Source code--the code written in the high-level programming language--is compiled for a particular processor design. Consequently, even though four different kinds of processors support Windows NT 4.0, you need different software to support PowerPC and x86-based computers--the two types of processors arrange storage in different ways and so can't read each other's compiled code.

Programs written in C++, for example, are already compiled from the source code for the appropriate platform. The Microsoft .NET platform, however, is designed to handle JIT compiling. The JIT compiling function compiles source code for an application as it's executed. Although this approach necessarily incurs a performance hit, JIT compiling has some advantages for code management. Updates to the source code are implemented each time you run the application, so the developer doesn't need to recompile the code each time the application runs. The JIT compiler can tell whether the computer the code will execute on has one processor or is a multiprocessor machine and compiles accordingly. Also, because the code is compiled as it's run, the addresses that the machine code references are correct. Precompiled code assumes that the OS loads code at a particular base address. If the code doesn't load at that base address, then the relative address locations will be incorrect, and the OS loader must sort out what those addresses should be, given the new location. JIT compilers make no assumptions about the base address.

A function within the Common Language Runtime (CLR) compiles the source code into machine code. The OS can detect managed code by looking for a value in the program. When managed code calls a particular method, the compiling function wakes up, looks up the intermediate code (processor-agnostic object code that's similar to the machine code), then compiles the intermediate code into instructions for the available processor. The managed code then saves those instructions in a dynamically allocated location in memory. The compiling function points back to the original method so that the two are linked: When the method in the assembly executes, it executes the processor instructions stored in memory. As long as these instructions stay in memory (in other words, as long as the application keeps running), the compiler function doesn't have to do anything when that method executes again. However, when the application terminates, all the processor instructions are unloaded from memory. Every time that application restarts, the code needs to be recompiled. A second instance of the application, or the same method called by another application, will need to be compiled as well because the mapping of processor instructions to the method's location in memory won't be accurate for the new process.

Precompiling .NET code is possible. You do this by running the compiling utility with the name of the managed code. Doing so loads the CLR, which then loads the assembly, which then compiles all the intermediate code associated with the assembly into processor instructions. However, you should use precompiling only to offset the performance hit that JIT compiling incurs because by using precompiled code you lose the advantages of managed code and JIT compiling, such as automatic updates and correct memory locations. (The precompiling approach assumes that code executes at a particular base location, and if the base location changes, the OS loader has to translate all the instruction addresses.) Precompiling is also irreversible.

That's a quick and dirty look at how JIT compiling works and why .NET applications use it. The point of JIT compiling is to make code execute more easily on various platforms.

 

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish