Description of problem: Both Firefox and Thunderbird (probably SeaMonkey too) are leaking file descriptors to external applications that they execute. Version-Release number of selected component (if applicable): firefox-2.0.0.14-1.fc7 firefox-2.0.0.14-1.fc8 firefox-3.0-0.60.beta5.fc9.x86_64 thunderbird-2.0.0.12-1.fc7 thunderbird-2.0.0.14-1.fc9.x86_64 How reproducible: Always. Steps to Reproduce: 1. Install zenity if not installed (used to demonstrate the bug). 2. Create an executable ~/firefox-test.sh script, containing: #!/bin/sh ls -l /proc/$$/fd | zenity --text-info 3. Start firefox. 4. Access menu Edit->Preferences, go to Applications tab. 5. Set the ~/firefox-test.sh script as the handler for "mailto" content type. 6. Type "example" in the address bar and press Enter. Actual results: The test script shows that it has all firefox file descriptors in its descriptor table. Expected results: The external application should be executed in a clean environment, without any access to Firefox file descriptors. Additional info: It is difficult to exploit this vulnerability, but since it is descriptor leakage, it should be considered critical. The worst scenario I can see is some external application invoked by the browser (ex: IRC client) having my password database, e-mails, browser history and other sensitive data in its descriptor table. Firefox inherits the vulnerabilities of all its invoked external applications. Perhaps, this could also be used to insert a sort of client-side man-in-the-middle attack, by making a child process steal Firefox descriptors.
I'm removing the Security keyword. This is a bug, but it's not really a security issue. This is a problem I agree, but it's really more of a correctness issue than anything else. The upstream bug explains it better than I can: https://bugzilla.mozilla.org/show_bug.cgi?id=147659#c9
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
We have decided given that this bug has been registered in the upstream database (https://bugzilla.mozilla.org/show_bug.cgi?id=147659) and because we believe that it is more appropriate to let it be resolved upstream, to close this bug as UPSTREAM. Red Hat will continue to track the issue in the centralized upstream bug tracker, and will review any bug fixes that become available for consideration in future updates. Thank you for the bug report.
Just a note... The upstream bug was filed in 2002, presumably against Mozilla, so this is a very very long term bug that causes all sorts of problems for many people, including most annoyingly blocking the audio device requiring the user to manually go killing processes such as xpdf, acrobat, and other plugins and application helpers, etc. This is an extreme inconvenience to Red Hat Enterprise Linux customers, Fedora users, etc. and as Linux becomes more attractive on the desktop, bugs like this stand in the way of making the desktop more usable for them IMHO. I agree that it is good to track the upstream issue, but I think this should be re-evaluated by Red Hat for RHEL6 / Fedora for F12 as a desktop usability bugfix candidate. Upstream probably will not commit a Linux-only fix for the problem, but Fedora/RHEL could potentially include such a workaround until a more portable solution is created for upstream by someone. Could we reopen this to keep this on the radar as a potential Fedora 12/RHEL6 candidate bug to fix, and put it on a tracker bug for investigation? If it doesn't make the cut, perhaps we can try again for F13 or later timeframe. Do any of the mozilla contributors @ Red Hat have any comments/suggestions (other than what's in the upstream bug) as to what approach might work best or at least be considered for RHEL/Fedora? I don't mind having a look into this myself, but would appreciate some guidance if someone more familiar with the source could comment. Thanks guys.
For Chris to investigate further.
OK, and I can fully reproduce with firefox-3.5.1-1.fc11.x86_64 xulrunner-1.9.1.1-1.fc11.x86_64
Yes, can reproduce with firefox-3.0.11-2.el5_3 and firefox-3.0.11-2.el5_3 on RHEL 5.
Created attachment 354906 [details] test script for reproduction
Just as a datapoint, this problem is reproduceable in firefox 3.0, 3.5, 3.6 codebases still. (OS distribution, release, etc. doesn't make a difference due to the nature of the problem)
Just reviewing bugs I'm CC'd on and thought I'd give a small update here. The upstream bug on this (linked to above), is still open so the problem is now 12 years old. That's award worthy! ;o) Unable to easily confirm the problem on RHEL or Fedora at the moment, but I presume it is still present since the upstream bug hasn't been resolved. The end of the world is in 6 months so it might not be worth fixing now. ;oP
Red Hat Enterprise Linux 5 shipped it's last minor release, 5.11, on September 14th, 2014. On March 31st, 2017 RHEL 5 exits Production Phase 3 and enters Extended Life Phase. For RHEL releases in the Extended Life Phase, Red Hat will provide limited ongoing technical support. No bug fixes, security fixes, hardware enablement or root-cause analysis will be available during this phase, and support will be provided on existing installations only. If the customer purchases the Extended Life-cycle Support (ELS), certain critical-impact security fixes and selected urgent priority bug fixes for the last minor release will be provided. The specific support and services provided during each phase are described in detail at http://redhat.com/rhel/lifecycle This BZ does not appear to meet ELS criteria so is being closed WONTFIX. If this BZ is critical for your environment and you have an Extended Life-cycle Support Add-on entitlement, please open a case in the Red Hat Customer Portal, https://access.redhat.com ,provide a thorough business justification and ask that the BZ be re-opened for consideration of an errata. Please note, only certain critical-impact security fixes and selected urgent priority bug fixes for the last minor release can be considered.