Tetsuo Handa wrote:
> and the victim server process executes
>
> while (1) {
> update_condition();
> if (condition_is_met) execve("/bin/sh");
> };
>
> while execve("/bin/sh") is denied by security policy.
>
> The result is that the victim server process eats
> 100% of CPU resource and will affect other normal processes.
>
What is special about execve()? If the attacker can inject arbitrary
shell code, they can do any kind of DoS attack, such as "while (1) {}"
or "while (1) {system=("cat /var/log/messages >/dev/null");}"
A MAC system only notices if the process is doing something that
violates policy. AppArmor is addressing this in that we are adding a
configurable feature per profile for what should happen on violation of
a policy. The current options are:
* Complain: allow the violation and log it
* Audit: log *every* action whether it violates or not
additional actions may include:
* Enforce: block violations and log the violation
* Quiet: block violations but do not log the violation
* Kill: kill the process if it violates policy
We are also going to add management of rlimits to AppArmor profiles, so
you can specify in policy the limits of disk, CPU, memory, etc. So in
principle, you could combine rlimits on CPU with the Kill option to kill
a runaway CPU hog. However, this would also kill processes that simply
exceeded their CPU allocation, so use this judiciously.
> So, I wonder somehow we can avoid eating CPU resource
> without external monitoring process.
> For example, parry attacker's demand by replacing
> the current process's image with different program (e.g. /bin/true)
> rather than just returning an error code.
> For example, sleep for a few seconds before returning an error code.
>
That sounds very intrusive. How would you know that a given exec is an
attack? If it violates policy, then you apply the above actions
(Enforce, Kill, etc.) and if it does not violate policy, why are you
meddling?
Another approach is the behavioral intrusion detector, where the
defender uses patterns of system calls to detect non-typical behavior in
the confined process, and does something about it. This was pioneered by
Stephanie Forrest and her group in the mid 1990s, see "sense of self" at
the IEEE symposium on security and privacy.
However, behavioral detection can generate false positives, so the
severe reactions of Enforce, or even Tetsuo's suggestion of replacing
the exec target with /bin/true, are quite arduous. In an interesting
paper, Anil Somayaji proposed a tar-baby defense, where atypical syscall
patterns result in exponential slowdown of the system calls. The kernel
puts that process to sleep for 1 second, 2 seconds, 4 seconds .... etc.
until the behavior returns to normal. This is a great idea for a
defensive action if you don't know whether you have an attack or not.
The other problem with behavioral defenses is that they are subject to
Mimicry attacks. See Wagner et al in the ACM Computing and
Communications Security conference.
> There are some LSM hooks that are related with do_execve().
> I thought I can replace execve("/bin/sh") by execve("/bin/true")
> like what load_script() in fs/binfmt_script.c is doing.
> /bin/true can be any program (e.g. dummy-shell or /usr/bin/logger
> or /bin/mail to collect attacking information and share with other hosts).
>
> Any opinions?
>
I don't like the /bin/true response at all. I think it is weak if you
are sure it is an attack, and it is meddlesome if you are unsure. The
exponential slowdown is a much better response if you have a maybe-attack.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
