Microsoft Refuses To Fix NT 4.0 Exploit
shmigget writes "The Register is reporting that Microsoft is throwing in the towel as far as NT 4 is concerned on the latest security flaw to affect Windows 2000, XP, and NT 4. They quote Microsoft as saying 'The architectural limitations of Windows NT 4.0 do not support the changes that would be required to remove this vulnerability.'" There still is a workaround for NT 4.0. Instead of patching the problem, it's advised to firewall off port 135 on an affected machine.
No, I don't like it... but support for NT4 is dropped at 30 june 2003 and that's not really far away.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
I was going to say they had stopped supporting NT4 anyway so were within their rights, but I looked it up and it appears they are providing NT4 hotfixes until the end of 2004. Either way, a service pack or something equally dramatic for one flaw I think is overkill and blocking port 135 on a firewall is a better option.
They're not saying (publicly, anyway), "hah, we're not supporting this ancient operating system any more, go away."
The article quotes them saying they can't fix it, there's too much stuff to do.
Using your firewall to block port 135 is fine, unless you actually need RPC for something useful. In that case, I'd say that a firewall that discards all malformed packets (more complicated) is in order. Or an upgrade to Win2K. After all, it's been out for, what, 4 years now?
Get off my launchpad!
Way to go MS. Take the port used by the DCE endpoint mapper, use it in your own broken, buggy, and insecure version of DCE RPC (also known as DCOM), then refuse to fix it.
My University uses DCE all over the place, from a financial application to the distributed filesystem. Now people are going to start blocking this port (135) to protect against then start complaining when some of the applications they use and their file system access stops working.
Finkployd
More like :
Sorry, but due to the design limitation of your 1965 Ford, we are unable to retrofit your car to fix a recently-found problem in the braking system. Third-party companies may provide small fixes that can help alleviate (but not completely fix) the problem. This problem is not present in our current line of products.
Windows NT 4.0 hit end-of-life back on December 31, 2002. An IT department should know that commercial software companies, MS included, routinely EOL software and drop support for them. A 7-year-old OS is going to have moth holes in it. If your company cares about security, upgrade to something more modern and (theoretically) secure. If you can't afford it, then evaluate migrating to OSS solutions. If you can't afford that, well, you're in big trouble.
MS makes it clear on their Product Life Cycle pages what support they plan to give for all products. Anyone caught surprised by this probably shouldn't be making IT decisions for an organization any larger than 1.
The Windows NT 4.0 architecture is much less robust than the more recent Windows 2000 architecture, Due to these fundamental differences between Windows NT 4.0 and Windows 2000 and its successors, it is infeasible to rebuild the software for Windows NT 4.0 to eliminate the vulnerability. To do so would require rearchitecting a very significant amount of the Windows NT 4.0 operating system, and not just the RPC component affected. The product of such a rearchitecture effort would be sufficiently incompatible with Windows NT 4.0 that there would be no assurance that applications designed to run on Windows NT 4.0 would continue to operate on the patched system.
Sure it's idiotic that their system couldn't handle a patch. But if that's how it is, then it's a good thing they made their more recent versions dynamic enough to be fixable!
Any sufficiently simple magic can be passed off as mere advanced technology.