Bug 902522 - Denial of service attack using /run
Denial of service attack using /run
Status: CLOSED DUPLICATE of bug 693253
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-01-21 15:56 EST by Jesse Pollard
Modified: 2013-01-22 18:34 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-01-22 15:49:51 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
A demonstration of a trivial denial of service attack. (843 bytes, application/octet-stream)
2013-01-21 15:56 EST, Jesse Pollard
no flags Details

  None (edit)
Description Jesse Pollard 2013-01-21 15:56:21 EST
Created attachment 684652 [details]
A demonstration of a trivial denial of service attack.

Description of problem:

Fedora 18 allows any logged in user to perform a denial of service attack against any other user.

Version-Release number of selected component (if applicable):
Fedora 18.

How reproducible:
Just put a file in the /run/users/<uid>/ directory with a file that fills the /run filesystem.

This is the same problem as bug #830433 with Fedora 16, 17. Though it was supposedly fixed in F18 (though it is still possible to carry out the DOS there too, but at least /var/run is not /run.)

Attached is a script log of an attack.

Steps to Reproduce:
1.User logs in
2.cd /var/run/user/<users uid>
3.cp /dev/zero ./test
Actual results:
The /run filesystem is filled with zeros, causing other users to be unable to log in, get credentials, and could also prevent system services from being restarted.

Expected results:
This is the expected result as long as /run is writable by user processes.

Additional info:
Comment 1 Jesse Pollard 2013-01-21 16:09:34 EST
It also prevents yum from updating (can't create lock file).
Comment 2 Bill Nottingham 2013-01-22 14:30:26 EST
Need quotas on tmpfs.
Comment 3 Jesse Pollard 2013-01-22 14:57:52 EST
Need to know how much the system requires so that admins can subtract that from the total size, then divide by the number of concurrent users.

Reasonable for small systems, and servers with a limited user base.

Doesn't work very well for clusters where users may have multiple logins with different credentials. Think multiple batch jobs where two or three might run simultaneously, and need a different set of credentials. But I need to think more on that.

The way things are set now, it looks like they all share the same credentials.

On the nice side, at least it all gets deleted when the user logs out. But there may be an issue until the last job of the user finishes.

Is there a way to reserve a specified amount for the system to use? That way a user (or a group for that matter) would be unable to DOS the system.
Comment 4 Josh Boyer 2013-01-22 15:49:51 EST

*** This bug has been marked as a duplicate of bug 693253 ***
Comment 5 Jesse Pollard 2013-01-22 17:43:23 EST
should also be the same as bug 830433.
Comment 6 Jesse Pollard 2013-01-22 18:34:41 EST
I just realized the tmpfs quotas referenced (I believe this http://lwn.net/Articles/466127/ for RLIMIT_TMPFSQUOTA) do not/can not specify WHICH tmpfs limit for which mount.

That appears to mean that if /run tmpfs is limited to say 10K, then /tmp (also a tmpfs) is also limited to 10k-what is used for /run.

And if /tmp is too limited, then user applications that use /tmp will be just as constrained as their use of /run/user. And if the RLIMIT_TMPFSQUOTA is large enough for /tmp, then the denial of service attack still exists.

This would make the RLIMIT_TMPFSQUOTA useless on any system with more than one tmpfs mount that users can access such as the situation with /tmp and /run.

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