Bug 167704

Summary: CAN-2005-2802 ipt_recent crash
Product: Red Hat Enterprise Linux 3 Reporter: Mark J. Cox <mjc>
Component: kernelAssignee: David Miller <davem>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: davem, jmorris, lwang, petrides, security-response-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-08 00:32:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Mark J. Cox 2005-09-07 12:52:23 UTC
This issue also affected Red Hat Enterprise Linux 3 through the backport of this

+++ 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
A subset of this patch was commited to 2.6 kernel prior to 2.6.12:

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 17:05:06 UTC
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

Comment 3 Ernie Petrides 2005-09-07 19:35:02 UTC
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 19:50:11 UTC
James, you might want to look at this, too.

Comment 5 David Miller 2005-09-07 20:43:25 UTC
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-08 00:32:00 UTC
Thanks, Dave.

Closing as NOTABUG.