WONTFIX: No patch for Windows Server 2003 IIS critical bug – Microsoft Microsoft will not patch a critical security hole recently found and exploited in IIS 6 on Windows Server 2003 R2 – the operating system it stopped supporting roughly two years ago. The buffer overflow bug can be exploited to inject malicious code into a vulnerable machine and execute it, allowing an attacker to gain control …
"but there's a limit to how long Redmond – or indeed the vast majority of software companies – will continue to support outmoded operating systems."
If it were really outmoded, no one would be using it, and this would not be an issue. More and more, it seems that the only reason to stop using a Windows version is that it is arbitrarily declared EOL, not because of any technical reason that the successor is actually better.
That's the joy of "tightly-coupling" applications with the OS - it makes upgrades so much more... exciting.
If you had written your applications in perl or php, do you think you'd be stuck being unable to upgrade to a later OS or a later httpd version?
Of course, if you're still running the old stuff just because you can't be bothered to upgrade, well, that's another issue.
"If you had written your applications in perl or php, do you think you'd be stuck being unable to upgrade to a later OS or a later httpd version?"
In our case it's a program written using a specific version of PHP, and relying on a specific version of PHP-GTK, which can't be upgraded without a full re-write. However, this version of PHP only does HTTP, no SSL.
So yeah, this sort of thing does happen with other OSes.
"That's the joy of "tightly-coupling" applications with the OS - it makes upgrades so much more... exciting.
If you had written your applications in perl or php, do you think you'd be stuck being unable to upgrade to a later OS or a later httpd version?"
If you had written your apps in PHP they would have had a critical exploit far more often than on IIS6.
I'm not aware of any difficulties in migration to a later Windows OS from Server 2003. It still supports IIS6 features and management tools in the later IIS versions...
Let me translate the situation to Linux speak for you: This is like a distro vendor not providing new versions of packages after
a) the distro version has been declared EOL; and/or
b) this major version of the software in question no longer being maintained by upstream.
I'm sure you can't find updated Apache packages for some dist you installed in 2003.
PS. For your information, you can run Perl or PHP under IIS. And ASP.NET under your favorite *ix httpd. There was even ASP Classic for *ix at some point.
Not that you'd want to run Perl, PHP or ASP Classic though since they're all awful for anything past "my little toy web site".
>Is that a policy or a habit?
For some clients policy - the system carries an accredited security rating, applying updates would require the system to be reassessed...
This naturally raises a question over the comparitive security of W2K3 EAL4+ and W2K12 EAL4+
Also W2K3 did have variants that were deployed in appliances.
"For some clients policy - the system carries an accredited security rating, applying updates would require the system to be reassessed..."
If the accreditation doesn't mandate being kept to current patch levels (subject to testing/review of the patches) it's the accreditation that needs to be reassessed.
That is usually the "don't touch a running system" ethos. Updates are something new, which could disrupt the stable, running system... The fact that they should normally protect the computer and possibly improve stability is neither here nor there, the production system is running and you shalt not touch!
A real pain for security concious admins who are told to leave well alone and only pulled in to clean up in the aftermath of an incident.
I do sympathise with both sides of that argument. Changes break things; I've seen an OS upgrade push a (just) working system into serious thrashing*. That's why you either have to go with a system for which you trust the vendors not to break things or have a test system.
*This was back in the days when memory was really, really expensive. I finally got the budget for the extra sticks I'd been asking for.
>A number of customers I work for have a policy of not patching"
Is that a policy or a habit? Or, more likely, a lack of a habit of patching?
Policy, in the IT world, is the excuse for stupid behavior, often resulting from complete lack of common sense, it is the excuse they throw into a conversation ... in which other industry would you get these ?
We have a policy of not wearing protective outfits when we remove asbestos from buildings. Our F1 team has a policy of not wearing seat-belts in Silverstone Grand Prix. Nooooo, never hear that, do you ? Well, in IT, you hear this BS all the bloody time....
Paris because I think she has a policy of bending over for anyone who can count to 5, without using fingers.
That's not right though is it. There are good reasons not to use this OS, the least of which being that it's shit. Modern windows does have better protections than 2003.
I can't think of many good reasons why 2003 can't be migrated away from and you'd be nuts to expose it to the internet.
If budget is a concern, use Linux. If you rely on some archaic microsoft technology that is no longer in use, you are doing it wrong, and should re-write your app anyway.
"Assuming you mean licensing and not TCO"
I mean both - Linux is still cheaper, especially at scale.
"it's only free if your time has no value "
Our time has value, but Linux is still cheaper. Remember that software licensing itself requires time to manage and audit, and lots of valuable company lawyer time to negotiate contracts. Linux doesn't need any of that.
The majority of our workload runs on Linux boxes, so we have around twice as many Linux boxes as Windows. The Linux team is smaller than the Windows team. Less people managing more kit. How is that higher TCO?
"and you don't need long supported OS version lifetime / enterprise grade vendor support..."
We don't. 1000s of nodes and we manage to keep everything running smoothly and securely. If we really needed vendor hand-holding we'd only buy it for the small dev network anyway so that would keep the cost down substantially over doing it for the entire infrastructure. That's an option you simply can't do with an old-fashioned rigid and restrictive licensing regime like Microsoft's.
Where Linux is more time expensive is that a big deployment tends to be a bit more front-loaded. In terms of central auth, config management, monitoring, patching, etc. it doesn't take as long to set up a Windows network compared to a Linux one. Even taking that into account though, the benefits above still far outweigh this drawback.
"Modern windows does have better protections than 2003."
how about "Linux has WAY better security than ANY windows.". Then do a one-time conversion to LAMP, and save money over time with maintenance, security, licenses, etc..
(post edit, should've already credited you for mentioning Linux)
Linux has enough problems of its own and often relies on good knowledge of how it works and how the individual components can be tied down.
Given the securtiy holes that keep cropping up in GNU/Linux and its tools and the relatively short support timescales, compared to Windows, from most distributions, I would rather be running a 10 year old Windows server than a 10 year old Linux installation (RHEL being an exception).
I don't know many Linux admins who would be comfortable taking patched source code for newer Kernel versions and integrating them into a 10 year old Kernel and compiling it.
Linux has enough problems of its own and often relies on good knowledge of how it works and how the individual components can be tied down.
Of course you have to know what you are doing, that is how it should be regardless of platform.
Given the securtiy holes that keep cropping up in GNU/Linux and its tools
Mostly issues in obscure drivers, remember, Linux is NOT monolithic but modular.
short support timescales
In Linux, they do not change the whole system as massively as on Windows with every new release - you get small incremental changes. Support lifecycles are usually 5 years, agreed, but upgrading is less of a pain (sic) than on Windows Server, massively so. Besides, you can have your ENTIRE config in version control software, nothing beats that. IIS 6 still had the metabase abomination, in 7, they switched to XML files, better, yet, can you control XML files via GPO ? Thought not ...
As usual, thanks for the laugh, big_D!
Saying "if it were really outmoded, no one would be using it" shows a very limited knowledge of how IT actually works - many really outdated software are left in operation, sometimes because you have no choice (i.e some specific machinery), often because of a combination of laziness, incompetence, and greed.
Windows and RHEL have one of the longest support cycles - many other OS are EOLed far sooner.
Ubuntu 12 LTS is EOLed in April, and I know people who never bothered to upgrade in the past months, and which aren't going to patch it themselves nor pay someone (I know of someone still using Debian 5, also...). "Technically", all of them still work - just you have very little return in maintaining them, and more version you have to maintain, the harder it becomes.
True, but if you're also giving it an internet connection you're doing it wrong.
Not necessarily. The question is the level of internet connection. So I would agree if the connection allowed for all ports to be accessible and no filtering/firewalling has been applied.
For example, a client has a legacy XML gateway running on a W2K3 box due to backend integration issues, naturally it is connected to the Internet, however the connection is through an application firewall, so the only direct exploit is to send it a specially crafted XML file, that fully adheres to the XML schema defined for the interface (otherwise the application firewall will reject the submission), which causes something unintended to happen...
I worked for an IT company that was still using SUSE from 1999/2000 in 2016! Despite repeatedly informing them that this was not a sensible thing to install on customer sites, they argued that their software was compiled for that kernel and the servers were behind a firewall, so to hell with installing updates on their customers' servers!
They did finally have to start migrating as the drivers wouldn't work properly with some more modern hardware and VM environments...
To make that stick they'd also have to argue that either they'd lost the source or that it was so bad it could only be compiled for that kernel.
Alternatively and given some of the experiences related in El Reg comments, the team that wrote the software are long gone and the new team don't have the experience, inclination, funding etc. to want to take a look...
Certainly, take something as simple as an MS-Word style sheet or Unix Printcap definition, both very simple in concept but to create one and then maintain it over an extended period of time...
I think the real issue here is one that in part MS have created. MS did much to assist the largescale adoption and embedding of WS2K3 and XP in the enterprise then when these reached 'EOL' MS basically disowned them; even though enterprises were in the main the one's paying annual licence and support fees to MS.
The other part is something the IT industry has to face up to, the longevity of many business applications and thus the need to maintain code over extended periods of time. The problem is that this isn't a new issue, the CCTA laid much of the foundations of ITIL in the late 1980's...
I think the real issue here is one that in part MS have created. MS did much to assist the largescale adoption and embedding of WS2K3 and XP in the enterprise then when these reached 'EOL' MS basically disowned them; even though enterprises were in the main the one's paying annual licence and support fees to MS.
On the other hand, MS let everybody know in 2003 when support for these products would run out and that at that point customers would have to move to a newer platform. This information crept up in the press a lot over the years, especially towards the end of the lifecycle.
People still putting 2003 / XP on new machines post 2010 and then moaning that support has stopped only have themselves to blame for not dealing with the realities of the situation. There is a difference between an archaic system installed in 2003/2004 that is still chugging along and people are reluctant to touch, compared to people putting old software on new hardware, after the product has gone into extended support or support has been discontinued.
If the software is that mission critical, then there should be a budget to get it running on supported hardware, or for finding a replacement. Especially if it is in a regularted industry.
People still putting 2003 / XP on new machines post 2010 and then moaning that support has stopped only have themselves to blame for not dealing with the realities of the situation. There is a difference between an archaic system installed in 2003/2004 that is still chugging along and people are reluctant to touch
I have some sympathy for your viewpoint, but note that MS only managed to deliver Win7 (XP's replacement in Oct 2009), which given the recent experience with Vista, everyone were wary of deploying. So we do need to tread a little carefully, particularly with respect to business where as I noted they were paying MS an annual fee; unlike joe public and hence MS had an opportunity to reflect on it's success and build on it rather than take a wrecking ball to it....
As for "archaic system", XP/2003 only became 'archaic' when MS released a usable successor product set, until then it was effectively the only choice in the market.
@Roland6 by archaic, I was meaning the application layer, running on top of the OS. Something that won't migrate to newer versions of the OS. Here, you have to bite the bullet and look at getting it updated or replaced, before the OS goes out of support.
And if the application itself is out of support, then your shareholders should be worried.
As they were constantly updating the code for new features... But the libraries they had bought in used an ancient version of QT and a VT100 terminal to Windows form converter library and the original source code was written around 1995.
It was actively extended with new features, but nobody would invest the time getting it to work with modern hardware or newer libraries, until the OS refused to install on modern hardware / the old RAID controller was no longer available and the new controllers didn't have any drivers for such an old Kernel...
Did they update QT? No, did they move to a more modern architecture? No, they just got the old code to compile on a newer Kernel.
Heck, for the anniversary celebration of the company, they wanted to display a guess the weight game on one of their terminals. I came up with a nice background image, but the application couldn't do background images on a windows in Windows and couldn't do a transparent background on text and graphic objects. I argued, that that is something Windows could do in 3.1... The reply? The app was written in Visual C++6 and used such an old version of QT, that it didn't understand background images - they actually had to manually redraw the image on every refresh and that it couldn't do transparent backgrounds on text objects!
Buying a newer version of QT was not even considered!
The old director also thought that the firewall didn't need support, because it was just a firewall and therefore didn't need such things as security patches, because "it is just a firewall"!
>their software was compiled for that kernel
Why do I sense bullshit, here ? I had Suse 7, which you are referring to ... it had a 2.2 Linux kernel which was patched until 2004. Software that ran on 2.2 was easily compiled for 2.4, many changes in 2.6 meant that you had to patch minor thingies in your code for that, but hey, that came much later ...
Either they hired a temp to write code and run gcc as a one-timer, or were n00bs?
@Hans1 the problem is, if you only have binaries and they are no longer supported, you are stuffed, regardless of which OS you use. That was part of the problem, which I alluded to in my earlier posts. Only when the old version of SUSE no longer booted on new hardware, did they look at paying to get hold of the source code...
The other is budget. If a customer pays for a new feature, that is income. If you have to spend a few thousand man hours going through legacy code and getting it working with a newer OS version, that is pure cost and is not generally seen as a needed thing by management, as long as the existing configuration works on new hardware...
If the customers don't understand OS upgrades etc. or are a Windows house and let you manage the Linux server, you can pretty much get away with murder... Until there is a breach.
"but there's a limit to how long Redmond – or indeed the vast majority of software companies – will continue to support outmoded operating systems."
Which is fine, however this is an exploit of an Application, not an OS. The fact that some class-1 a-hole at Microsoft (marketing) decided that an Application, such as IIS should be inexplicably linked to the Operating System is the cause behind these problems. Yes, at some point an application may go beyond the native capabilities of the host OS, however these points should be relatively rare and more related to underlying hardware or just-above-hardware abstraction levels and as time goes by these points should become rarer due to feature saturation. However, this doesn't sell, or more accurately force the sale of, new Operating System licences therefore this is not a business model that the likes of Microsoft (they're not the only ones) operate.
"Which is fine, however this is an exploit of an Application, not an OS. The fact that some class-1 a-hole at Microsoft (marketing) decided that an Application, such as IIS should be inexplicably linked to the Operating System"
What OS version / vendor would you recommend instead that comes with zero applications and has enterprise grade support?
nb - To save sys admins who are still running this stuff hunting: FYI - IIS6 is not installed by default on Server 2003, and when you do install IIS6, WebDAV is also not enabled by default.
See https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/4beddb35-0cba-424c-8b9b-a5832ad8e208.mspx?mfr=true
"anything relying on WebDAV should have been replaced once or twice in that 14+ year period to address existing security issues..."
Not running MS platforms here, but there have been various security patches for WebDAV much more recently than 14 years ago.
Searching for "webdav security issues" brings up quite a few.
E.g. MS Security bulletin for WebDAV, February 2016
This security update resolves a vulnerability in Microsoft Windows. The vulnerability could allow elevation of privilege if an attacker uses the Microsoft Web Distributed Authoring and Versioning (WebDAV) client to send specifically crafted input to a serve
Does Outlook Web Access still rely on WebDAV? If so I'd bet a bunch of those are OWA servers in small companies and thus also a domain controller.
Of course this is still better than my last employer in manufacturing. They finally switched away from Windows NT 4 and Exchange 5.5 in 2010. No, not kidding.
Shodan.io – a search engine for internet-facing devices – has found hundreds of thousands of servers still using IIS 6.0, and about 20,000 machines using Windows Server 2003.
My understanding was that IIS 6.0 was only available for WS2K3 and XP and wasn't available as a separate download there seems to be a massive mismatch in the figures Shodan.io is reporting.
>The others could be running on XP?
Definitely a possibility, according to Shodan, the vast majority are in the USA and China.
From memory, there was nothing on XP that required IIS to be running, so I presume many of these XP boxes belong to developers... many of whom probably harangue others for running old insecure OS's...
To help maintainers of Windows Server 2003 computers block almost inevitable attacks under these unfavorable circumstances, we decided to provide them a free solution: a micropatch for CVE-2017-7269, which they can apply on their machines not only without rebooting, but also without even restarting Internet Information Services.
Maybe they could teach Microsoft how they did this, as Microsoft appear to be incapable of writing any update which doesn't require a reboot.
Ok; a few years ago now, but I did indeed upgrade our servers to a maintained OS: Debian! Oh, and for anybody considering it we have never looked back. We replaced exchange server with Postfix and Dovecot, For calendar, tasks and contacts we use davical and for the web httpd (or Apache as most people call it). It is far more stable than its MS equivalent ever was; and not only that; it hasn't cost us a penny!
I actually found some 2003 servers in production not long ago (6 months perhaps). Reason they were still on 2003 was that they ran an old version of some shitty proprietary software that somehows managed to break on newer Windowses.
They are upgrade now though... I recall a ~500 day uptime on one of them so maybe that's when the last updates were delivered.
One of them which was hosting stuff for a customer actually had Remote Desktop exposed to the World. I was quite surprised it wasn't hacked to pieces!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
