Bug 437114 (CVE-2008-1294)

Summary:	CVE-2008-1294 kernel: setrlimit(RLIMIT_CPUINFO) with zero value doesn't inherit properly across children
Product:	[Other] Security Response	Reporter:	Jan Lieskovsky <jlieskov>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	anton, dhoward, kreilly, mjc, nhorman, skakar
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-12-23 16:41:07 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	437121, 437122
Bug Blocks:

Description Jan Lieskovsky 2008-03-12 14:36:56 UTC

Description of problem:

David Peer has reported the following problem in the kernel handling
of "ulimit" function:


<cite>

Hi,

I'm using zsh 4.3.2-25 on debian, and noticed that when any user
run: ulimit -t 0 from its shell, he manages to disable the cputime
limitation if any. for example:

I have a debian system that has cpu time limitation of 1 minute soft,
and 2 minutes hard. If the user run: ulimit -t 0, he can run jobs without
any cputime limitation: You can see the output from "top" command, that it ran
the job "testload" for more then 6 minutes.

Thanks in advanced,

David Peer.

</cite>

Comment 1 Jan Lieskovsky 2008-03-12 14:38:44 UTC

Comment to Micah Cowan to this issue:

David Peer wrote:
> > If the user run: ulimit -t 0, he can run jobs without any cputime
> > limitation:

This sounds more like a kernel problem to me than a zsh bug. I get the
same behavior on my Ubuntu 7.04 (beta) system, in _bash_.

I note that getrlimit(2) says:

 In 2.6.x kernels before 2.6.17, a RLIMIT_CPU limit of 0 is wrongly
 treated as "no limit" (like RLIM_INFINITY). Since kernel 2.6.17, set‐
 ting a limit of 0 does have an effect, but is actually treated as a
 limit of 1 second.

However, I'm running 2.6.20(-14-generic), and still experiencing that
symptom.

Comment 2 Jan Lieskovsky 2008-03-12 14:39:17 UTC

Another Tom reaction: 

I checked the problem earlier today (by reference of David who pointed
it out to me - thanks, David).  The problem is apparently in the Linux
kernel, where the check for trying to set RLIMIT_CPU = 0 is done a bit
too late, and has nothing to do with zsh.  Specifically, the same
symptoms were visible with other shells (ash, bash) too.

I checked the Linux kernel sources and found the solution in
kernel/sys.c.  Attached is a copy of my message with the patch to the
Linux-Kernel Mailing List.

One issue that may be relevant within zsh, though, is that it appears
that zsh caches the limits set, and since that check in Linux "cheats"
by setting the value to 1 when 0 is requested, entering "ulimit -a"
does not call getrlimit(...) at all and does show 0 after issuing the
command "ulimit -t 0", although getrlimit(RLIMIT_CPU, ...) would
return 1.  The correct limit is seen in a subshell where this is not
yet cached.

I expect my patch to be in the next Linux 2.6.21 release candidate.

  Cheers,
  -- Tom

Comment 3 Jan Lieskovsky 2008-03-12 14:40:08 UTC

Proposed upstream patch:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9926e4c74300c4b31dee007298c6475d33369df0

Comment 6 Jan Lieskovsky 2008-03-12 16:15:48 UTC

Link with more detailed information:

http://marc.info/?l=oss-security&m=120527771109026&w=4

Comment 7 Vincent Danen 2010-12-23 16:41:07 UTC

This was addressed via:

Red Hat Enterprise Linux version 5 (RHSA-2008:0612)