Bugtraq mailing list archives
commercial products and security [ + new bug ]
From: Michal Zalewski <lcamtuf () DIONE IDS PL>
Date: Thu, 28 Sep 2000 18:34:00 +0200
-- Standard disclaimer applies. This post reflects my personal beliefs and -- oppinions only, and I am speaking as a private person. These statements -- are not related to my eployer, don't have to be true, and are subject to -- futher investigation and consultation with your software vendor *only*. -- These statements are based on publicly available knowledge and -- observations. Vendor of described software has been informed before this -- publication, which isn't formal in any way, and has been written in -- best intentions: to warn administrators about information, which might -- be already available for attackers. Enough said. Hi, BUGTRAQ readers. I've been pretty busy last month (probably subscribers weren't especially sad ;). I have only one ot two vulnerabilities this time (bad day), but first of all, I'd like to make the most of this message and to start a discussion. The problem described below, another stack overflow, is quite similar to bug found (by me) days ago in open-source UW IMAPd (maybe except it's easier to exploit). So, here are some of my reflections: Most of bugs in commercial software are re-discoveries of old open-source vulnerabilities. My recent research can be a good example of it: - This vulnerability (obvious hole, similar to the one discovered in open-source code approx. 3 or 4 months ago and fixed immediately). - Lotus Domino SMTP vulnerabilities (some open-source daemons suffered of such problems for the last time maybe 8 years ago) - Netscape / iPlanet LDAP-enabled FTPD server format bugs (were present months after similar discoveries on wu-ftpd and proftpd code) - Netscape / iPlanet LDAP-enabled FTPD server "long path" buffer overflow; I haven't published this vulnerability - but yes, it's present. You can create extremely long path, and then, during next login attempt, when disk usage is re-calculated, buffer overflow will happen (such bugs were present in wu-ftpd code year ago, if I'm right). - and many other discoveries done by other people, including occassionally appearing problems like "rot13 encryption"... Quite often, I'm under impression only vendor information is changed, while problem is still the same. For me, these problems are showing the truth: in most cases, commercial product security is still based on "security by obscurity" scheme. Vendors keep claiming their products are much more secure than open-source solutions - and this "holly war", open-source vs closed-source, has a long tradition slashdot.org, microsoft.com, and securityfocus.com - but they are not audititing their sources, feeling safe with their closed-source solutions. Their security is not evolving when new class of vulnerabilities is discovered (or becomes more popular), but only when particular vulnerability is reported. Result? Obvious, remote, and really nasty bugs discovered and fixed years or months ago in GPL applications, are still appearing in _leading_ commercial code. No, I'm not saying commercial software is particularly less secure than GPL code, and not saying specific vendor is writing code less secure than other vendors. Netscape appears in above examples three times - but only because this software is quite popular, and thus become a subject of my investigation, not because it's more / less secure. But while in GPL case, lack of vendor's interest in product security can be easily compensated by hundreds of enthusiasts auditing sources (even using grep, which is quite powerful security-auditing tool, as practice shown ;), nothing can really compensate lack of vendor's interest in security of commercial product. The most alarming thing is that some of commercial vendors really focused on security, but we have no way to distinguish them from those giving vague promises. That's bad. Commercial vendors have to solve the problem together. But, of course, it only my humble point of view. I'd like to hear what other BUGTRAQ readers think. So, what we're talking about?;) Aaah! * OK xxx IMAP4 service (Netscape Messaging Server 4.15 Patch 2 (built xxx)) test login valid_login valid_password test OK User logged in test list <about-512-bytes-of-junk> / Connection closed by foreign host. 2107: siginfo: SIGSEGV SEGV_MAPERR addr=0x41414141 2107: Received signal #11, SIGSEGV [default] It's a DoS, because single-threaded server crashes. But no matter - it's trivially exploitable. Simple retaddr overwrite bug, input buffer is not stripped, there's no any kind of character validation. Local access with daemon privledges can be gained, allowing futher privledge escalation. This applies both to bare Netscape Messaging Server IMAP4, and to Netscape Messaging Server protected by Netscape Messaging Multiplexor (which is used in redundant / cluster solutions shipped by Sun / Netscape). Regards, _______________________________________________________ Michal Zalewski [lcamtuf () tpi pl] [tp.internet/security] [http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};: =-----=> God is real, unless declared integer. <=-----=
Current thread:
- commercial products and security [ + new bug ] Michal Zalewski (Sep 28)