eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
March was a bleak month for security and no doubt left many administrators figuratively tapping out Save Our Server signals on their wirelesses.
Advisories came out last month for root-level vulnerabilities on three major server applications: Sendmails namesake product, Microsofts Internet Information Services 5.0 Web server and the Samba Development Teams Samba file server. Together, these holes leave the vast majority of enterprises open to attack.
Looking at the vulnerabilities side by side reveals interesting similarities and also suggests the best defense tactics.
The IIS and Samba advisories stand out because in both cases, crackers were actively exploiting these holes before security bulletins could be issued. As I was writing this column, I got a call from Samba co-author Jeremy Allison to let me
know that the Samba team had just been notified of yet another root-level hole for Samba that will be fixed in Samba 2.2.8a. The newest problem was discovered through an attack on a honey pot Samba server, demonstrating that attackers are already exploiting this vulnerability and potentially have been for some time. The flaw has been in Samba since 1993, and so virtually every Samba server is affected.
Day 0 attacks such as these—for which no advisory or patch has been released before attacks are made—are the ones that prompt rapid changes of underwear. Theres no warning, no notification and no help to figure out why your servers got rooted.
Page Two
Both Sendmail and IIS are typically installed on publicly accessible servers, and the vulnerable ports arent firewalled, so these systems are wide open for attack. Sendmail, the most widely used mail transfer agent in the world, had two separate vulnerabilities last month. Both were the result of e-mail header information not being correctly checked for length and so allowing attacker-supplied data to overwrite other parts of program data and code.
The IIS vulnerability (MS03-007) is a classic Microsoft case of having too much software installed by default. The vulnerable component is not in IIS but in a core Windows 2000 file, ntdll.dll. However, IIS 5.0 (installed by default with Windows 2000 Server) has WebDAV turned on by default, and WebDAV calls ntdll.dll. (There are a number of other ways ntdll.dll could be reached—even Windows 2000 boxes without IIS installed should be patched.)
According to Web survey company Netcrafts March Web survey, IIS 5.0 runs about 9 million public Web sites. About 75 percent of IIS 5.0 sites leave WebDAV enabled, according to Netcraft, suggesting that more than 6 million IIS sites are vulnerable. With millions of sites and hundreds of thousands of servers at risk, I think a worm targeting this vulnerability is quite likely.
Regarding Samba, “[The 2.2.8 security hole] was a nightmare,” said Allison, in Cupertino, Calif. “All in my code, and it had been in there for five or six years. Its more widely known than the 2.2.7 problem.”
What are the similarities here? First, all these programs are written in C; that languages use of pointers and variables without automatic overflow protection makes security programming mistakes easy to make. Second, firewalls provided limited protection for affected organizations. (Only Samba would typically benefit here.) Third, all three servers typically run as root or LocalSystem and so offer complete control to an attacker.
Application portability, compatibility and speed are three reasons servers continue to be written in C, Allison says. But those advantages notwithstanding, I would urge programmers to use Java or .Net languages instead. Automated source-code-inspection tools can also help.
The hardest problem is to keep the root account from being able to do everything. Trusted operating system approaches such as Okenas StormWatch, an eWeek Excellence Awards finalist, can prevent even root-level accounts from breaching system integrity. Applications can be run in sandboxes that define precisely what files and network ports they can manipulate.
We need new thinking like this for long-term security. Application developers need to switch to safer languages, and IT staff needs to be aggressive in turning off defaults and using advanced security approaches such as trusted operating system add-ons.
Most Recent Stories by Timothy Dyck: