Posted on 03/28/2003 5:29:30 PM PST by chance33_98
Vulnerability hits NT 4, Windows 2000 and XP
By James Middleton [28-03-2003]
'Important' RPC flaw cannot be patched on NT 4, warns Microsoft
Microsoft has warned of a vulnerability affecting Windows 2000 and XP systems and that is especially bad news for NT 4. Labelled 'important', the vulnerability was discovered in the Remote Procedure Call (RPC) Endpoint Mapper protocol, which could allow denial of service (DoS) attacks to be carried out against systems.
Although patches have been issued for Windows 2000 and XP, NT 4's architecture makes one impossible, according to Microsoft.
"Due to the fundamental differences between Windows NT 4.0 and Windows 2000 and its successors, it is unfeasible to rebuild the software for Windows NT 4.0 to eliminate the vulnerability," the company said.
RPC provides an inter-process communication mechanism that allows a program running on one computer to execute code on a remote system. The vulnerability affects the part of RPC that deals with message exchange over TCP/IP.
To exploit the bug an attacker would have to establish a TCP/IP connection to the Endpoint Mapper process on a remote machine and begin the RPC connection negotiation before transmitting a malformed message.
Microsoft said this would cause the RPC service to fail, with the loss of any RPC-based services on the server.
"This vulnerability only permits a DoS attack and does not provide an attacker with the ability to modify or retrieve data on the remote machine," the company said.
Patches for Windows 2000 and XP are available on Microsoft's TechNet website, but the company can only recommend blocking port 135 to protect NT 4 boxes.
Upgrade revenue is the fundamental difference.
June 30, 2003 (the scheduled non-support date for WinNT) came a few months early.
One problem with network software is that getting applications to talk coherently is painstakingly difficult. Software wishing to utilize services running on another computer must get the other computer's attention, ask it questions, and interpret the responses. Similarly software wishing to provide services to other computers must make its presence known to the other computers, watch for incoming questions, interpret them, do whatever it is they're supposed to do, formulate a response, and send it back. While not conceptually difficult to manage there is so much housekeeping in this process that writing error-free network-aware applications has been extremely expensive and difficult.
Since much of the housekeeping procedures are common amongst network-aware software, the obvious thing to do is build a package such that you can describe the data you want to send and the data you expect to receive in a convenient, readable format and have a software package build you the code that handles all the details.
This same problem was encountered years ago as computer programs became more and more complex. Programmers spent so much time doing the same mundane tasks (and making the inevitable mistakes while doing it) that the obvious solution was to create a new language in which you could describe what you wanted to do, in convenient little pieces, and have a computer program translate that description into the native computer code. Those programs are today's compilers and the pieces are procedures. Procedures talk amongst themselves via procedure calls, which are standardized methods for passing information back and forth.
If this technique could be applied to a single application, why couldn't it be used to produce programs that operate across a network? And why couldn't it be done in such a way that the application thinks it is just making a normal procedure call?
The result of this realization is RPC, or remote procedure call. Using RPC an application can call what appears to be another procedure within itself without knowing that the procedure will actually be performed elsewhere on the network. This is done by creating proxy procedures (sometimes called stub procedures) whose only task is to manage the transfer of data over the network.
Similarly it's possible to take procedures which you'd like to make available to other programs on the network and wrap them in a standardized framework that calls them as if the call had been made from within the same application. This framework is known as the server stub.
Because they grew up more-or-less independently of computer languages, network applications use different terminology from the computer languages we all use today. The caller in a procedural languages is called a client in networking terminology, and the callee is known as the server. In some respects this terminology is more sensical; not only is it much more difficult to confuse but it also more adequately reflects the intent of each piece: a client is anything that is requesting a service, and a server is anything that is providing a service.
ps - if you ever want to know more about Solaris let me know, I am working on a series of Powerpoinr presentations on it for training for the sun exams.
I switched to Apple. And I'm happy to have done so. But I keep my Win98 laptop because MS does everything they can to make sure that files can't be shared with other systems.
Most of my correspondents have figured out how to send me files that I can read on the Mac, but every so often, I need to crank up the Win. And it annoys me more each time.
I guess I shouldn't complain since I wouldn't have a job if it wasn't for Microsoft!
Clinton supporter
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.