Bug 167704 - CAN-2005-2802 ipt_recent crash
CAN-2005-2802 ipt_recent crash
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Miller
Brian Brock
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-07 08:52 EDT by Mark J. Cox (Product Security)
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-07 20:32:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Mark J. Cox (Product Security) 2005-09-07 08:52:23 EDT
This issue also affected Red Hat Enterprise Linux 3 through the backport of this
functionality.

+++ This bug was initially created as a clone of Bug #167703 +++

A flaw has been reported in the ipt_recent module along with a patch
http://blog.blackdown.de/static/kernel/ipt_recent-fix.patch
A subset of this patch was commited to 2.6 kernel prior to 2.6.12:
http://linux.bkbits.net:8080/linux-2.6/cset@42b0f732P_VGfvCBAVpq1Grl7HtA_Q

It was originally reported that this flaw can cause a remote crash but in other
messages mentioned that this was just on 64-bit systems.  The security team
haven't yet analysed this flaw to determine the exact consequences or likelyhood
of exploitation.

The CVE entry states:
         The ipt_recent kernel module (ipt_recent.c) in Linux kernel
         before 2.6.12, when running on 64-bit processors such as
         AMD64, does not properly perform certain time tests when the
         jiffies value is greater than LONG_MAX, which can allow
         remote attackers to cause a denial of service (kernel panic)
         via certain attacks such as SSH brute force.
Comment 1 Ernie Petrides 2005-09-07 13:05:06 EDT
Mark, I think the crash potential on upstream 2.6 was due to the fact
that the variable "hold" was declared as "unsigned long *" but that the
buffer was allocated as a set of "u_int32_t" data items (at least in 2.6.11).
This allowed an overflow of the buffer in certain cases on 64-bit arches.

But in RHEL3, "hold" is declared as "u_int32_t *", which matches the buffer
allocation, so I don't think there is any vulnerability there.

Do you have a specific report of RHEL3 crashing due to this?

If not, and DaveM concurs with my analysis, then I suggest this be closed
as NOTABUG.
Comment 3 Ernie Petrides 2005-09-07 15:35:02 EDT
Thanks, Mark.  Correcting state to ASSIGNED.

Dave, please check out my analysis in comment #1.  If you agree that there is
no vulnerability on RHEL3, please close this as NOTABUG.  Thanks in advance.
Comment 4 Ernie Petrides 2005-09-07 15:50:11 EDT
James, you might want to look at this, too.
Comment 5 David Miller 2005-09-07 16:43:25 EDT
RHEL3 is not affected by the crash bug, but ipt_recent is mostly
non-functional on 64-bit systems, even with the upstream 2.6.x
fix applied.

The blog.blackdown.de patch is not to be considered seriously, it
has many flaws in it, which is why it was not applied upstream.  His
use of get_seconds() is very error prone, and adds the problem that
if you set the time of day to some point in the past, all of his time
comparison checks fail.  That's why jiffies was being used in this file,
so that time always monotonically increases and thus all the time comparisons
work out.  He's also not handling time overflows properly with his new tests.
In short, his patch is buggy. :-)

ipt_recent needs to be rewritten from scratch
Comment 6 Ernie Petrides 2005-09-07 20:32:00 EDT
Thanks, Dave.

Closing as NOTABUG.

Note You need to log in before you can comment on or make changes to this bug.