Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 8 Jul 2014 16:52:43 +0400
From: Solar Designer <>
Subject: Re: CVE-2014-4699: Linux ptrace bug

On Sat, Jul 05, 2014 at 10:25:47PM +0400, Solar Designer wrote:
> Red Hat's statement is:
> "This issue affects the versions of the Linux kernel as shipped with
> Red Hat Enterprise Linux 5, 6, 7 and Red Hat Enterprise MRG 2. Future kernel
> updates for Red Hat Enterprise Linux 5, 6, 7 and Red Hat Enterprise MRG 2 may
> address this issue."
> but it appears to have been posted before my unsuccessful attempts to
> trigger the error condition on RHEL5'ish and RHEL6'ish kernels yesterday.
> I fully agree that we need to treat these kernels as likely vulnerable
> unless we can show otherwise, though - obviously, simply not being able
> to trigger the problem with a particular PoC doesn't mean much.

Red Hat's statement has since been edited to:

"This issue does not affect the versions of the Linux kernel as shipped
with Red Hat Enterprise Linux 5.

Future kernel updates for Red Hat Enterprise Linux 6, 7 and Red Hat
Enterprise MRG 2 will address this issue."

I was subscribed to this Bugzilla entry, yet I didn't receive an e-mail
notification when this edit was made.  I guess Bugzilla does not send
those for edits to past comments.  While I think I understand why Red
Hat does it this way, and it's fine, maybe a better practice would be to
also add new comments like "I've just edited our statement in comment #4
above because ..." - that way, some revision history will be preserved,
rationale for the change given, and e-mail notifications will be sent.

Anyway, let me ask: Red Hat, how do you know RHEL5 kernels are not
vulnerable, whereas RHEL6 are?  There must have been some analysis to
arrive at these conclusions.  This will be very helpful to know for
downstream projects (as it relates to your kernels), including OpenVZ
and Owl.

Since we're past the weekend and since some distros have already
released security updates, I think it's OK to start talking about
specific code paths triggering the problem publicly.  In fact, I think
it's best to make this info public before the next weekend approaches.

Meanwhile, I've attached the patch for RHEL5.10/OpenVZ that we're using
on Owl (lacking convincing rationale, let alone proof, why those kernels
are not vulnerable).



diff -urpN linux-2.6.18-371.9.1.el5.028stab114.2/arch/x86_64/kernel/ptrace.c linux-2.6.18-371.9.1.el5.028stab114.2-owl/arch/x86_64/kernel/ptrace.c
--- linux-2.6.18-371.9.1.el5.028stab114.2/arch/x86_64/kernel/ptrace.c	2014-06-30 06:58:47 +0000
+++ linux-2.6.18-371.9.1.el5.028stab114.2-owl/arch/x86_64/kernel/ptrace.c	2014-07-07 08:09:18 +0000
@@ -314,6 +314,10 @@ static int putreg(struct task_struct *ch
 			return -EIO;
 		value &= 0xffff;
+	case offsetof(struct user_regs_struct,rip):
+		if (value >= TASK_SIZE_OF(child))
+			return -EIO;
+		break;
 	put_stack_long(child, regno - sizeof(struct pt_regs), value);
 	return 0;

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ