Bug 160708 - possible security problem with RLIMIT_VMEM
Summary: possible security problem with RLIMIT_VMEM
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: threads (show other bugs)
Version: 9.0-CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-threads (Nobody)
Depends on:
Reported: 2011-09-13 15:20 UTC by misho
Modified: 2017-12-31 22:32 UTC (History)
0 users

See Also:

file.txt (2.21 KB, text/plain)
2011-09-13 15:20 UTC, misho
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description misho 2011-09-13 15:20:05 UTC
With thread application you may get all system memory for one process. 
Excellent DoS for hostings and other application providers.

When you use threads his stack not are restricted from system's quota
and you may get all memory.

Fix: Patch attached with submission follows:
How-To-Repeat: Compile and start program "pt" from PR

example: ./pt 10000
Comment 1 peter 2011-09-16 03:52:18 UTC
RLIMIT_STACK is more meant as a safety measure against runaway
processes rather than a security system.

The limit you are looking for is:
#define	RLIMIT_VMEM	10		/* virtual process size (incl. mmap) */

Given that you can freely move your stack, there is nothing to stop
you relocating your stack pointer to a blob of memory you got from
mmap. Or even the data segment.

And that is what RLIMIT_VMEM aka RLIMIT_AS are for.

Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
Comment 2 misho 2011-09-17 12:18:38 UTC
Hmm, you no so right Peter. 

	Yes I can move esp pointer in any other address, but please 
start program and see address of allocated memory for every thread. 
All this allocations is made in upper memory called stack. 
	Try same alloca() in main program thread and you see how 
system terminate program if you going over stack limit.

Best Regards
Michael Pounov
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:00:00 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped