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:
Version-Release number of selected component (if applicable):
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.
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.
"ls -w 100000" working without system freeze or high load ;-)
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]
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
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
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:
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.