Security
Mozilla and security
It looks like yet another in a series of bad weeks for Internet Explorer; exploitable bugs seem to come out more quickly than security firms can write up advisories about them. The web browser is an important piece of software from a security perspective; it has direct contact with random, external sites, some of which are almost certainly hostile. Web browsers are also large, complex programs, and thus hard to audit in any sort of thorough way. So it is not surprising that problems are found and exploited.Linux users, as usual, sit back and feel smug. We don't run Internet Explorer, and our browsers, being free software and thus inherently more secure, will not present us with this sort of unpleasant surprise.
Right?
As free browsers continue to grow in popularity, they will also attract more attention from the inhabitants of the darker side of the net. So it is worth looking at how Mozilla, which is the core of many free browsers, deals with security incidents.
Linux users may well have missed this security advisory that went out on July 7, because only Windows users are affected. For those users, however, the impact of this bug could be large. Essentially, Mozilla-based browsers (including Firefox and Thunderbird) pass "shell:" URIs directly to the operating system, which happily runs the command included in the URI. It is a direct path to a command interpreter on the local system; all it requires is getting the user to click on the wrong link.
Some commenters have said that this is really a Windows bug; Mozilla is just passing on the URI and Windows decides how to deal with it. But that is an evasive answer; a security-conscious application must sanitize any externally-supplied data that it passes on to the system. This vulnerability is a Mozilla bug; it was closed by having Mozilla do the checking it should have done in the first place.
Others have complimented Mozilla for its quick response: a patch was available about one day after the vulnerability was posted. This response time has been favorably compared with the rather slower pace characteristic of Internet Explorer fixes. The only problem with this point of view is that the Mozilla developers have known about this issue since 2002; Mozilla bug 163767 suggested the addition of a preference which would disable the use of external protocol handlers. The bug remained open for almost two years, however, until the project had no alternative to fixing it. It seems that developers of free software are entirely capable of sitting on a vulnerability in the absence of an immediate exploit threat.
The point here is not to flame the Mozilla project for shipping code with a vulnerability, or even for not realizing the importance of a known hole. These things happen, and Mozilla's record is better than that of many other projects. The point is that we cannot assume that, by accessing the web with a free browser, we are immune from exploits. Vulnerabilities are a fact of life, and the incentives for finding and exploiting vulnerabilities in free browsers are growing.
In that context, it is encouraging to see this MozillaZine article which talks about some recent changes made by the Mozilla hackers. The Mozilla extension mechanism is a powerful way of adding new capabilities to the browser, but it could also become a mechanism by which attackers load hostile code directly into target systems. It should, thus, be hard to add an extension; it shouldn't happen automatically. The Mozilla hackers have noticed an increase in attempts to load unwanted extensions, and have responded with some new mechanisms designed to block those attempts. These include a whitelist of sites allowed to propose the addition of extensions.
One should also note this vulnerability which could be of use to the perpetrators of the increasing number of "phishing" attacks out there. Through the use of some Javascript and frames trickery, an attacker can falsify somebody else's page while having the location bar show a legitimate URL. Internet Explorer is vulnerable, but so is Mozilla. (Thanks to Chester Young for the pointer).
With luck, the Mozilla hackers (and khtml hackers too) will increasingly keep security in mind as they write their code. And we know they will fix problems quickly when they become apparent. But we cannot assume that our free browsers are immune from security problems; the world is, sooner or later, going to prove otherwise.
New vulnerabilities
Ethereal: Multiple security problems
| Package(s): | ethereal | CVE #(s): | CAN-2004-0633 CAN-2004-0634 CAN-2004-0635 | ||||||||||||||||||||||||||||||||||||
| Created: | July 9, 2004 | Updated: | August 19, 2004 | ||||||||||||||||||||||||||||||||||||
| Description: | There are multiple vulnerabilities in versions of Ethereal earlier than
0.10.5, including: * In some cases the iSNS dissector could cause Ethereal to abort. * If there was no policy name for a handle for SMB SID snooping it could cause a crash. * A malformed or missing community string could cause the SNMP dissector to crash. See this advisory for more information. | ||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||
MoinMoin Group ACL Bypass
| Package(s): | moinmoin | CVE #(s): | |||||
| Created: | July 12, 2004 | Updated: | August 26, 2004 | ||||
| Description: | MoinMoin contains a flaw that may allow a malicious user to gain access to unauthorized privileges. The issue is triggered when an attacker creates a user with the same name as an administrative group. This flaw may lead to a loss of integrity. See this osvdb entry for additional information. | ||||||
| Alerts: |
| ||||||
php: remotely exploitable memory errors
| Package(s): | php | CVE #(s): | CAN-2004-0594 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | July 14, 2004 | Updated: | February 7, 2005 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | Stefan Esser has issued an advisory regarding a remotely exploitable hole in PHP (through version 4.3.7). If the memory_limit feature is in use (as it should be, to prevent denial of service attacks), allocation failures can be forced at highly inopportune times, and those failures can be exploited to execute arbitrary code. The exploit is described as "quite easy," and it can be done regardless of whether Apache1 or Apache2 is in use. Upgrading to PHP 4.3.8 fixes the problem; yesterday's PHP 5.0 release also contains the fix (but the final release candidate did not). | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
wv: buffer overflow
| Package(s): | wv | CVE #(s): | CAN-2004-0645 | ||||||||||||||||||||||||||||||||||||
| Created: | July 14, 2004 | Updated: | February 10, 2005 | ||||||||||||||||||||||||||||||||||||
| Description: | wv, a viewer for MS Word files, contains a buffer overflow which may be exploited by a suitably-crafted file. Version 1.0.0-r1 fixes the problem. | ||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||
Resources
Phrack #62
Phrack issue #62 is out, with discussion of the latest in cracking techniques. This issue has a relatively high number of Windows-oriented articles, but there are also articles on attacking Apache and "UTF8 shellcode." Click below for the full table of contents.
Page editor: Jonathan Corbet
Next page:
Kernel development>>