Description of problem: If I do "ls -w 100000" as user at an up2date Red Hat Enterprise Linux 3, I'm able to ddos it with that command...this behaviour refers to the following vulnerabilities: - http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0853 - http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0854 Version-Release number of selected component (if applicable): coreutils-4.5.3-26 How reproducible: Everytime. Steps to Reproduce: 1. ls -w 100000 2. Get the system freeze or only a high load for a few minutes, if you run a very fast computer. Actual results: Well, I'm able to slow or break down a RHEL3 system as user... ;-) I attached a patch solving this vulnerability (I'm using the Red Hat patch from coreutils-4.5.3-19.0.2 which was used for RHL 7/8/9) and also the diff of coreutils's spec file. Expected results: "ls -w 100000" working without system freeze or high load ;-) Additional info: The fix for CAN-2003-0853/-0854 was done for: - RHL 7/8/9: RHSA-2003:309-08 - RHEL AS 2.1: RHSA-2003:310-10 (bug #107821) - FC1: FEDORA-2004-091 (bug #117310) but NOT for RHEL 3! Maybe we should do that update very quickly (even if it is possible for U3?)...
Created attachment 101973 [details] Diff from coreutils.spec file
Created attachment 101974 [details] coreutils-4.5.3-lsw.patch
The attack vector for this vulnerability is wu-ftpd -- we do not ship wu-ftpd in Red Hat Enterprise Linux 3.
Well Tim, I'm also able to type without any wu-ftpd at a bash or another prompt as user "ls -w 100000"...however it is a issue ;-)
While this issue does exist, without wu-ftpd it's a non-issue. It becomes a simple local DOS, there are countless other ways to cause a local DOS.
What's up?! Is it a new Red Hat strategy to do no fixes for local DOS? Maybe Red Hat shouldn't fix any local DOS kernel bugs and so on, because they are only local and there are so many?! Of course, there are lots of ways to DOS a system, but if you don't fix them, you never get rid of them - that's logic, isn't it?! But I still don't want to start any basic discussion about Red Hat - and the update support for the products - with you. BTW, you even fixed the also "non-affected" and non-supported Fedora Core 1 against this issue (#117310)...why not RHEL3, too? I think, the people buying the expensive RHEL3 and its expensive update support, have the right to get fixes - even against local DOS vulnerabilities (otherwise we wouldn't need any local DOS fixes for example in the kernel). And I personally can't do more than provide pre-champed/ready-to-eat solutions for Red Hat to fix such vulnerabilities.
With any system where you have local users you have to have some level of trust for those users. Users on Unix systems can trivially write one-line programs designed to use up as much memory as possible or consume other resources such as disk space or CPU. Sysadmins who don't want this to happen can use things like the Linux system resource limits to try to prevent these flaws, preventing users from hogging system requirements. So if you're already setting resource limits then the flaw in ls won't let users bypass that. If you're not already setting resource limits then users could find many many other ways to have the same impact. Local DoS flaws in the kernel tend to have a greater impact; the recent floating point instruction flaw allowed a local user the ability to completely crash a system, irrespective of the resource limits or other limits (chroot etc) that might be imposed on them. So whilst it didn't qualify for a security advisory, it is a bug that we should fix during future update to coreutils.
(A colleague pointed me at this article that goes into a bit more detail about setting resource limits with PAM: http://www.securityfocus.com/infocus/1575 )
Fix applied in CVS and will be included in any future update to coreutils.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2005-544.html