From: Vincent Danen <vdanen@annvix.org>
Subject: runit running under linux 2.4 with openwall patches
Date: Thu, 20 Jan 2005 15:14:38 -0700 [thread overview]
Message-ID: <AD0A7182-6B30-11D9-9341-000A9598BFB2@annvix.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 3106 bytes --]
One of the features of openwall is stack protection. I'm getting this
when I try to boot into a 2.4.29 kernel with openwall hardening
enabled:
Security: return onto stack from 0x0804812c to 0xbffffea0 running as
UID 0, EUID 0, process runit:1
Security more returns onto stack, logging disabled for a minute
I can manage to make the kernel boot, but runit isn't running and it's
consuming 100% cpu in my vmware test machine.
I have two ideas that may be causing the problem, and not being a
kernel person I don't really know for 100% which it is:
1) the Non-executable user stack area part of owl
2) the enforce RLIMIT_NPROC on execve(2)
I have a feeling that it's #1 tho. The question is, why is runit doing
this? This is a valuable feature to have in a security-hardened
distro, and having runit not running because of it is problematic. I'd
like to be able to do both (although, for testing, I'm going to compile
another kernel with this feature disabled just to isolate it). The
description of the feature according to
http://www.openwall.com/linux/README.shtml is:
===
Most buffer overflow exploits are based on overwriting a function's
return address on the stack to point to some arbitrary code, which is
also put onto the stack. If the stack area is non-executable, buffer
overflow vulnerabilities become harder to exploit.
Another way to exploit a buffer overflow is to point the return
address to a function in libc, usually system(). This patch also
changes the default address that shared libraries are mmap()'ed at to
make it always contain a zero byte. This makes it impossible to specify
any more data (parameters to the function, or more copies of the return
address when filling with a pattern), -- in many exploits that have to
do with ASCIIZ strings.
However, note that this patch is by no means a complete solution, it
just adds an extra layer of security. Many buffer overflow
vulnerabilities will remain exploitable a more complicated way, and
some will even remain unaffected by the patch. The reason for using
such a patch is to protect against some of the buffer overflow
vulnerabilities that are yet unknown.
Also, note that some buffer overflows can be used for denial of
service attacks (usually in non-respawning daemons and network
clients). A patch like this cannot do anything against that.
It is important that you fix vulnerabilities as soon as they become
known, even if you're using the patch. The same applies to other
features of the patch (discussed below) and their corresponding
vulnerabilities.
===
I'd like to be able to have both runit and this feature together; I
think it should be possible because the traditional init works with it.
Any ideas on how to go about this?
Right now I'm using runit 1.0.5 but plan to upgrade it soon; is this
something that may have been addressed in more recent versions?
Thanks for any info.
--
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C A2BC 2EBC 5E32 FEE3 0AD4}
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
next reply other threads:[~2005-01-20 22:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-20 22:14 Vincent Danen [this message]
2005-01-20 22:28 ` Charlie Brady
2005-01-20 22:52 ` Vincent Danen
2005-01-21 19:32 ` Gerrit Pape
2005-01-25 4:51 ` Vincent Danen
2005-01-25 10:58 ` Torne Wuff
2005-01-25 19:54 ` Vincent Danen
2005-01-25 23:33 ` Vincent Danen
2005-01-26 0:44 ` Csillag Tamás
2005-01-26 4:31 ` Vincent Danen
2005-01-26 8:52 ` Csillag Tamás
2005-01-27 19:52 ` Charlie Brady
2005-01-26 12:07 ` Milan P. Stanic
[not found] ` <20050205212555.GI20427@digitus>
2005-02-05 23:14 ` Vincent Danen
2005-03-14 14:11 ` Csillag Tamás
2005-03-14 17:40 ` Gerrit Pape
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AD0A7182-6B30-11D9-9341-000A9598BFB2@annvix.org \
--to=vdanen@annvix.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).