Re: FreeBSD Kernel buffer overflow
machine/param.h which is installed from
src/sys/{alpha,amd64,i386,ia64,etc}/param.h would be a more appropriate
location. There may be cases where you would want to know this value in
userland, in which case including machine/md_var.h would definitely
not be appropriate.
My preference would be to name it MAX_SYSCALL_ARGS.
I followed your suggestions and I made changes. Now this is patch available.
I did for amd64, sparc64, i386 and alpha since ia64 is not affected. I report
i386 solution (for complete diffs tree and other architectures support download
patch http://www.gufi.org/~rookie/args-diff.tar.gz):
$arch/include/param.h
cat i386_param.diff
--- param2.hMon Sep 20 14:09:44 2004
+++ param.h Mon Sep 20 13:59:05 2004
@@ -122,6 +122,8 @@
#define VM_BCACHE_SIZE_MAX (200 * 1024 * 1024)
#endif
+#define MAX_SYSCALL_ARGS 8
+
/*
* Mach derived conversion macros
*/
=
$arch/$arch/trap.c
cat i386_trap.diff
--- trap2.c Mon Sep 20 14:09:27 2004
+++ trap.c Mon Sep 20 14:03:23 2004
@@ -902,7 +902,7 @@
u_int sticks;
int error;
int narg;
- int args[8];
+ int args[MAX_SYSCALL_ARGS];
u_int code;
/*
kern/kern_syscalls.c
cat kern_syscalls.diff
--- kern_syscalls.c Sat Sep 18 13:42:21 2004
+++ kern_syscalls2.cMon Sep 20 14:18:45 2004
@@ -58,6 +58,16 @@
syscall_register(int *offset, struct sysent *new_sysent,
struct sysent *old_sysent)
{
+#ifndef __ia64__
+ if (new_sysent-sy_narg 0 || new_sysent-sy_narg MAX_SYSCALL_ARGS)
+ {
+ printf(Invalid sy_narg for syscall: boundary is [0 - %d]\n,
+ MAX_SYSCALL_ARGS);
+ return EINVAL;
+ }
+#endif
+
+
if (*offset == NO_SYSCALL) {
int i;
The other architectures patches has similar body.
I hope you will commit it.
rookie
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
On Sat, 18 Sep 2004, Mike Meyer wrote: In [EMAIL PROTECTED], Matt Emmerton [EMAIL PROTECTED] typed: I disagree. It really comes down to how secure you want FreeBSD to be, and the attitude of we don't need to protect against this case because anyone who does this is asking for trouble anyway is one of the main reason why security holes exist in products today. (Someone else had brought this up much earlier on in the thread.) You haven't been paying close enough attention to the discussion. To exploit this security problem you have to be root. If it's an external attacker, you're already owned. That leaves trojans. Those are always a problem for OSS - and for proprietary software. With OSS, you have the option of auditing the code yourself, though that has been beaten (by Ritchie, I believe *). Personally, I trust the FreeBSD committers to not trojan my system - and if they were going to, there are *so* many easier ways to do it. Should I ever decide to run a third party kernel module, I may well audit the code for that module. But I take that risk everytime I install software - whether it's from ports, commercial, or just grabbed off the web. mike *) There was at one time a hacked C compiler that did two evil things. The first evil thing was to recognize the password checking code in login, and generate code that always accepted a back door password as well as the real password. The second evil thing was to recognize the place in the C compiler where the two hacks were, and reinsert them into the generated code. So a source audit would turn up nothing, but the system was thoroughly compromised. http://www.acm.org/classics/sep95/ Cheers, Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
On 20 Sep, [EMAIL PROTECTED] wrote:
cat kern_syscalls.diff
--- kern_syscalls.c Sat Sep 18 13:42:21 2004
+++ kern_syscalls2.cMon Sep 20 14:18:45 2004
@@ -58,6 +58,16 @@
syscall_register(int *offset, struct sysent *new_sysent,
struct sysent *old_sysent)
{
+#ifndef __ia64__
+ if (new_sysent-sy_narg 0 || new_sysent-sy_narg MAX_SYSCALL_ARGS)
+ {
+ printf(Invalid sy_narg for syscall: boundary is [0 - %d]\n,
+ MAX_SYSCALL_ARGS);
+ return EINVAL;
+ }
+#endif
+
+
It would probably be better to change the #ifndef to
#ifdef MAX_SYSCALL_ARGS
I would also add new_sysent-sy_narg to the printf().
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
On Sat, Sep 18, 2004 at 09:13:42PM -0700, Julian Elischer wrote: + +#if (__i386__) (INVARIANTS) + + KASSERT(new_sysent-nargs = 0 new_sysent-nargs = + i386_SYS_ARGS, + + invalid number of syscalls); + +#endif + + +*old_sysent = sysent[*offset]; +sysent[*offset] = *new_sysent; +return 0; + + + Why panic the machine at this point? Just refuse to install the syscall + and return an error. + + and the test for INVARIANTS is un-needed.. KASSERT only compiles to anything + when INVARIANTS is defined. ...and it should be '#ifdef', not '#if'. ...and the panic message should be inside (). -- Pawel Jakub Dawidek http://www.FreeBSD.org [EMAIL PROTECTED] http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! pgpzjpAm2AMY1.pgp Description: PGP signature
Re: FreeBSD Kernel buffer overflow
On 2004-09-18 11:02, Pawel Jakub Dawidek [EMAIL PROTECTED] wrote:
On Fri, Sep 17, 2004 at 12:37:12PM +0300, Giorgos Keramidas wrote:
+ % +#ifdef INVARIANTS
+ % + KASSERT(0 = narg narg = 8, (invalid number of syscall args));
+ % +#endif
Maybe:
KASSERT(0 = narg narg = sizeof(args) / sizeof(args[0]),
(invalid number of syscall args));
So if we decide to increase/decrease it someday, we don't have to remember
about this KASSERT().
This might actually be good to have for kernels with INVARIANTS regardless
of the small penalty paid for every syscall. Debugging kernels are known
to be slower than non-debugging ones. It won't come as a very big surprise
for those who are really interested to turn it on.
Is there some way we can measure the extra slowness of a kernel compiled
with this KASSERT turned on?
Then, if we find out that turning this on for all the developers who use
INVARIANTS is too big a penalty to pay we remove it or add a special
category of invariants (INVARIANTS_SLOW anyone?) that will act as a toggle
for INVARIANTS that are known to cause extreme slowness and should only be
enabled with care...
On 2004-09-18 02:18, Don Lewis [EMAIL PROTECTED] wrote:
If you think we really need this bit of extra security, why not just
prevent the syscall with too many arguments from being registered by
syscall_register()? At least that keeps the check out of the most
frequently executed path.
Don,
This sounds excellent. Can an src-committer verify that the following is
ok and commit it along with the manpage diff I posted earlier to HEAD?
The hard-wired number 8 in there seems like something that could probably
be improved a lot, but after looking for a short while I couldn't find a
good way of finding out from the arguments of syscall_register() some way
to calculate it. Of course, I'm far from an experienced kernel hacker and
I'm probably missing something. Feel free to correct the following diff or
even replace it entirely.
: Index: kern_syscalls.c
: ===
: RCS file: /home/ncvs/src/sys/kern/kern_syscalls.c,v
: retrieving revision 1.11
: diff -u -r1.11 kern_syscalls.c
: --- kern_syscalls.c 15 Jul 2004 08:26:05 - 1.11
: +++ kern_syscalls.c 19 Sep 2004 16:38:21 -
: @@ -58,6 +58,8 @@
: syscall_register(int *offset, struct sysent *new_sysent,
: struct sysent *old_sysent)
: {
: + if (new_sysent-sy_narg 0 || new_sysent-sy_narg 8)
: + return EINVAL;
: if (*offset == NO_SYSCALL) {
: int i;
:
P.S. I noticed that the kern_syscall.c file has many whitespace ``issues''
(i.e. it uses 7 SPACE characters for the first level of indentation in
syscall_register() but 8 SPACES for the deeper levels of nesting), which
should probably be taken care of in future commits, but that's really a
different another topic.
- Giorgos
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
Don,
This sounds excellent. Can an src-committer verify that the following
is
ok and commit it along with the manpage diff I posted earlier to HEAD?
The hard-wired number 8 in there seems like something that could probably
be improved a lot, but after looking for a short while I couldn't find
a
good way of finding out from the arguments of syscall_register() some way
to calculate it. Of course, I'm far from an experienced kernel hacker
and
I'm probably missing something. Feel free to correct the following diff
or
even replace it entirely.
Maybe you can get a look at this approach:
==
$arch/include/md_var.h:
cat md_var.diff
--- md_var2.h Sun Sep 19 22:43:56 2004
+++ md_var.hSun Sep 19 22:46:23 2004
@@ -41,6 +41,12 @@
extern int (*copyin_vector)(const void *udaddr, void *kaddr, size_t
len);
extern int (*copyout_vector)(const void *kaddr, void *udaddr, size_t
len);
+/*
+ * Arguments number syscalls definition
+ */
+
+#define MAGIC_SYSCALL_ARGS 8
+
extern longMaxmem;
extern u_int basemem;/* PA of original top of base memory */
extern int busdma_swi_pending;
kern/kern_syscall.c:
cat kern_syscall.diff
--- kern_syscalls.c Sat Sep 18 13:42:21 2004
+++ kern_syscalls2.cSun Sep 19 23:00:44 2004
@@ -27,6 +27,8 @@
#include sys/cdefs.h
__FBSDID($FreeBSD: src/sys/kern/kern_syscalls.c,v 1.11 2004/07/15 08:26:05
phk Exp $);
+#include machine/md_var.h
+
#include sys/param.h
#include sys/sysproto.h
#include sys/sysent.h
@@ -58,6 +60,9 @@
syscall_register(int *offset, struct sysent *new_sysent,
struct sysent *old_sysent)
{
+ if (new_sysent-sy_narg 0 || new_sysent-sy_narg MAGIC_SYSCALL_ARGS)
+ return EINVAL;
+
if (*offset == NO_SYSCALL) {
int i;
==
i386/i386/trap.c
--- trap.c Sat Sep 18 14:30:19 2004
+++ trap2.c Sun Sep 19 22:47:33 2004
@@ -902,7 +902,7 @@
u_int sticks;
int error;
int narg;
- int args[8];
+ int args[MAGIC_SYSCALL_ARGS];
u_int code;
/*
The idea is that for every architecture MAGIC_SYSCALL_ARGS can be defined
in md_var.h (it's alredy included in handlers sources). Here just i386 example
is done to show approach. It could be more flexible than a static approach.
I hope you will enjoy it.
rookie
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
On 19 Sep, [EMAIL PROTECTED] wrote:
Don,
This sounds excellent. Can an src-committer verify that the following
is
ok and commit it along with the manpage diff I posted earlier to HEAD?
The hard-wired number 8 in there seems like something that could probably
be improved a lot, but after looking for a short while I couldn't find
a
good way of finding out from the arguments of syscall_register() some way
to calculate it. Of course, I'm far from an experienced kernel hacker
and
I'm probably missing something. Feel free to correct the following diff
or
even replace it entirely.
Maybe you can get a look at this approach:
==
$arch/include/md_var.h:
cat md_var.diff
--- md_var2.h Sun Sep 19 22:43:56 2004
+++ md_var.hSun Sep 19 22:46:23 2004
@@ -41,6 +41,12 @@
extern int (*copyin_vector)(const void *udaddr, void *kaddr, size_t
len);
extern int (*copyout_vector)(const void *kaddr, void *udaddr, size_t
len);
+/*
+ * Arguments number syscalls definition
+ */
+
+#define MAGIC_SYSCALL_ARGS 8
+
extern longMaxmem;
extern u_int basemem;/* PA of original top of base memory */
extern int busdma_swi_pending;
machine/param.h which is installed from
src/sys/{alpha,amd64,i386,ia64,etc}/param.h would be a more appropriate
location. There may be cases where you would want to know this value in
userland, in which case including machine/md_var.h would definitely
not be appropriate.
My preference would be to name it MAX_SYSCALL_ARGS.
kern/kern_syscall.c:
cat kern_syscall.diff
--- kern_syscalls.c Sat Sep 18 13:42:21 2004
+++ kern_syscalls2.cSun Sep 19 23:00:44 2004
@@ -27,6 +27,8 @@
#include sys/cdefs.h
__FBSDID($FreeBSD: src/sys/kern/kern_syscalls.c,v 1.11 2004/07/15 08:26:05
phk Exp $);
+#include machine/md_var.h
+
#include sys/param.h
sys/param.h includes machine/param.h, so if the #define is added to
machine/param.h you won't have to include machine/md_var.h here.
The rest of the changes look ok, though you might want to add a printf()
before return EINVAL so that the reason for failure gets logged.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
On 18 Sep, Matt Emmerton wrote:
- Original Message -
From: Mike Meyer [EMAIL PROTECTED]
To: Matt Emmerton [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Avleen Vig
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Saturday, September 18, 2004 1:22 AM
Subject: Re: FreeBSD Kernel buffer overflow
In [EMAIL PROTECTED], Matt Emmerton
[EMAIL PROTECTED] typed:
I disagree. It really comes down to how secure you want FreeBSD to be,
and
the attitude of we don't need to protect against this case because
anyone
who does this is asking for trouble anyway is one of the main reason
why
security holes exist in products today. (Someone else had brought this
up
much earlier on in the thread.)
You haven't been paying close enough attention to the discussion. To
exploit this security problem you have to be root. If it's an
external attacker, you're already owned.
I'm well aware of that fact. That's still not a reason to protect against
the problem.
If your leaky bucket has 10 holes in it, would you at least try and plug
some of them?
If an attacker is allowed to install arbitrary syscalls, he might as
well install one that is easier to exploit.
struct write2kernel_args {
void*ubuf;
void*kbuf;
size_t nbyte;
};
void
write2kernel(td, uap)
struct thread *td;
struct write2kernel_args *uap;
{
copyin(uap-ubuf, uap-kbuf, nbyte);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
- Original Message - From: Devon H. O'Dell [EMAIL PROTECTED] To: Matt Emmerton [EMAIL PROTECTED]; Mike Meyer [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, September 18, 2004 4:01 AM Subject: Re: FreeBSD Kernel buffer overflow - Original Message From: Matt Emmerton [EMAIL PROTECTED] To: Mike Meyer [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: FreeBSD Kernel buffer overflow Date: 18/09/04 05:41 - Original Message - From: quot;Mike Meyerquot; lt;[EMAIL PROTECTED]gt; To: quot;Matt Emmertonquot; lt;[EMAIL PROTECTED]gt; Cc: lt;[EMAIL PROTECTED]gt;; quot;Avleen Vigquot; lt;[EMAIL PROTECTED]gt;; lt;[EMAIL PROTECTED]gt;; lt;[EMAIL PROTECTED]gt; Sent: Saturday, September 18, 2004 1:22 AM Subject: Re: FreeBSD Kernel buffer overflow gt; In lt;[EMAIL PROTECTED]gt;, Matt Emmerton lt;[EMAIL PROTECTED]gt; typed: gt; gt; I disagree. It really comes down to how secure you want FreeBSD to be, and gt; gt; the attitude of quot;we don't need to protect against this case because anyone gt; gt; who does this is asking for trouble anywayquot; is one of the main reason why gt; gt; security holes exist in products today. (Someone else had brought this up gt; gt; much earlier on in the thread.) gt; gt; You haven't been paying close enough attention to the discussion. To gt; exploit this quot;security problemquot; you have to be root. If it's an gt; external attacker, you're already owned. I'm well aware of that fact. That's still not a reason to protect against the problem. If your leaky bucket has 10 holes in it, would you at least try and plug some of them? -- Matt Emmerton So should we stop the command ``shutdown -h now'' from working for root? After all, he can DoS the system with it? How about this: let's disallow root from loading kernel modules! That way this can't ever happen. Even better: Why don't we just not boot into a usable environment! Then we have NO security holes. You guys are failing to see: ROOT HAS OMNIPOTENT POWER. SOMEBODY MUST HAVE OMNIPOTENT POWER. THIS IS NOT A BUG. THERE IS NOTHING TO SEE HERE, MOVE ON. Not to be sarcastic, but you guys are missing the problem. The problem was that someone was unaware of a kernel API. When you start programming for the kernel, you need to make sure that the code is secure. If you think this is a problem, take a look at init(8) and learn about securelevels. What happened: someone was unfamiliar with the syscall API. They crashed their system. They screamed wildly, believing they'd found a buffer overflow, when they'd merely overloaded the function stack and screwed up the call. This caused the system to reboot. Solution: make it more clear that syscalls take only 8 arguments. Make it clear that you can pass arguments in a struct to a syscall. Make it clear that many/most syscalls do this anyway. If there's beef on this, take it to [EMAIL PROTECTED] Mike and I discussed this offline. Can someone just step up to work on and commit the KASSERT code which handles the problem and end the thread? The only reason I piped up was because nothing had been done yet, and suggested two alternate ways of hardening the system that could be enabled/disabled by the system administrator, instead of being always enabled (like a KASSERT, which always incurs a run-time check and thus could hurt performance.) -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
On Fri, Sep 17, 2004 at 12:37:12PM +0300, Giorgos Keramidas wrote: + % +#ifdef INVARIANTS + % + KASSERT(0 = narg narg = 8, (invalid number of syscall args)); + % +#endif Maybe: KASSERT(0 = narg narg = sizeof(args) / sizeof(args[0]), (invalid number of syscall args)); So if we decide to increase/decrease it someday, we don't have to remember about this KASSERT(). -- Pawel Jakub Dawidek http://www.FreeBSD.org [EMAIL PROTECTED] http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! pgpSWfnBU9LRz.pgp Description: PGP signature
Re: FreeBSD Kernel buffer overflow
On 18 Sep, Pawel Jakub Dawidek wrote: On Fri, Sep 17, 2004 at 12:37:12PM +0300, Giorgos Keramidas wrote: + % +#ifdef INVARIANTS + % + KASSERT(0 = narg narg = 8, (invalid number of syscall args)); + % +#endif Maybe: KASSERT(0 = narg narg = sizeof(args) / sizeof(args[0]), (invalid number of syscall args)); So if we decide to increase/decrease it someday, we don't have to remember about this KASSERT(). What keeps the attacker from installing two syscalls, the first of which pokes NOPs over the KASSERT code, and the second of which accepts too many arguments? If you think we really need this bit of extra security, why not just prevent the syscall with too many arguments from being registered by syscall_register()? At least that keeps the check out of the most frequently executed path. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
On Sat, Sep 18, 2004 at 02:18:55AM -0700, Don Lewis wrote: + On 18 Sep, Pawel Jakub Dawidek wrote: + On Fri, Sep 17, 2004 at 12:37:12PM +0300, Giorgos Keramidas wrote: + + % +#ifdef INVARIANTS + + % + KASSERT(0 = narg narg = 8, (invalid number of syscall args)); + + % +#endif + + Maybe: + KASSERT(0 = narg narg = sizeof(args) / sizeof(args[0]), + (invalid number of syscall args)); + + So if we decide to increase/decrease it someday, we don't have to remember + about this KASSERT(). + + What keeps the attacker from installing two syscalls, the first of which + pokes NOPs over the KASSERT code, and the second of which accepts too + many arguments? First of all, this is not protection from an attacker, but help for bad programmers. + If you think we really need this bit of extra security, why not just + prevent the syscall with too many arguments from being registered by + syscall_register()? At least that keeps the check out of the most + frequently executed path. Good point, this is much better place for it. -- Pawel Jakub Dawidek http://www.FreeBSD.org [EMAIL PROTECTED] http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! pgp95AlGUtH0A.pgp Description: PGP signature
Re: FreeBSD Kernel buffer overflow
In [EMAIL PROTECTED], Matt Emmerton [EMAIL PROTECTED] typed: I disagree. It really comes down to how secure you want FreeBSD to be, and the attitude of we don't need to protect against this case because anyone who does this is asking for trouble anyway is one of the main reason why security holes exist in products today. (Someone else had brought this up much earlier on in the thread.) You haven't been paying close enough attention to the discussion. To exploit this security problem you have to be root. If it's an external attacker, you're already owned. I'm well aware of that fact. That's still not a reason to protect against the problem. If your leaky bucket has 10 holes in it, would you at least try and plug some of them? In my post I told that this is *NOT* exploitable but if somebody finds a method? what you can say? In underground comunities it's not so rare, patching is better than having a new exploits for freebsd. I was very deluded by this approach to potential security problem... (I repeat: *POTENTIAL*). rookie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
-- Messaggio originale -- Date: Sat, 18 Sep 2004 11:02:27 +0200 From: Pawel Jakub Dawidek [EMAIL PROTECTED] To: Giorgos Keramidas [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: FreeBSD Kernel buffer overflow On Fri, Sep 17, 2004 at 12:37:12PM +0300, Giorgos Keramidas wrote: + % +#ifdef INVARIANTS + % + KASSERT(0 = narg narg = 8, (invalid number of syscall args)); + % +#endif Maybe: KASSERT(0 = narg narg = sizeof(args) / sizeof(args[0]), (invalid number of syscall args)); So if we decide to increase/decrease it someday, we don't have to remember about this KASSERT(). Maybe better: #define ARGS_MAGIC 8 ... int args[ARGS_MAGIC]; #ifdef INVARIANTS KASSERT(0 = narg narg = ARGS_MAGIC, (invalid number of syscall args)); #endif (preprocession work) rookie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
What keeps the attacker from installing two syscalls, the first of which pokes NOPs over the KASSERT code, and the second of which accepts too many arguments? If you think we really need this bit of extra security, why not just prevent the syscall with too many arguments from being registered by syscall_register()? At least that keeps the check out of the most frequently executed path. This is not intended like a security check, just like a prevention against accidental buffer overflow (like my proof of concept). This is a quite simple concept, take care. rookie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: FreeBSD Kernel buffer overflow
== cat kern_syscalls.diff --- kern_syscalls.c Sat Sep 18 14:37:53 2004 +++ kern_syscalls2.cSat Sep 18 14:37:53 2004 @@ -73,6 +73,11 @@ sysent[*offset].sy_call != (sy_call_t *)lkmressys) return EEXIST; +#if (__i386__) (INVARIANTS) + KASSERT(new_sysent-nargs = 0 new_sysent-nargs = i386_SYS_ARGS, + invalid number of syscalls); +#endif + *old_sysent = sysent[*offset]; sysent[*offset] = *new_sysent; return 0; Sorry, a little problem here. There correct text chunk: cat kern_syscalls.diff --- kern_syscalls.c Sat Sep 18 14:37:53 2004 +++ kern_syscalls2.cSat Sep 18 14:37:53 2004 @@ -73,6 +73,11 @@ sysent[*offset].sy_call != (sy_call_t *)lkmressys) return EEXIST; +#if (__i386__) (INVARIANTS) + KASSERT(new_sysent-sy_nargs = 0 new_sysent-sy_nargs = i386_SYS_ARGS, + invalid number of syscalls); +#endif + *old_sysent = sysent[*offset]; sysent[*offset] = *new_sysent; return 0; (tgz is correct) rookie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Avoiding programmer invariant violations (was: Re: FreeBSD Kernel buffer overflow)
On Sat, 18 Sep 2004 [EMAIL PROTECTED] wrote: Here i report a patch different from Giorgos' one. The approch is completely different: working on syscall_register() function in kern/kern_syscalls.c file. I'd suggest that we need to look at this in two ways: (1) There's a compile-time INVARIANT that needs to be maintained by developers in adding new system calls. When building the kernel, it would be useful to have a compile-time assertion that causes a kernel compile to fail if an invalid system call is defined. I.e., when init_sysent.c is generated, it should build in __CTASSERT's that all argument counts are consistent with the requirements of the hardware architecture being built for. (2) There's a run-time INVARIANT issue for loadable modules built by third parties who may not understand the limits on arguments on system calls for various architectures. This can be handled by a check in the system call registration code, although since that's a non-critical performance path, I suggest testing the invariant even if INVARIANTS isn't compiled in. In some ways, I'd rather handle this at compile-time for the module, but I think the infrastructure for hooking up system calls at compile-time for modules will make that more difficult as compared to statically compiled system calls. Note that the discussion so far has not addressed the compile-time issue: which is a much better time to perform the tests -- it's something we can test when the kernel is compiled, so why not?. It also hasn't addressed non-i386 systems, such as amd64, which have similar or identical concerns. With all due respect to the submitter, I think bugtraq was not the forum to post this issue to, as that forum is typically preferred for exploitable vulnerabilities. A follow-up post to clarify that the initial post described a possible avenue for programmer error when extending the kernel, rather than an immediately exploitable vulnerability, might reduce confusion. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Principal Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Avoiding programmer invariant violations (was: Re: FreeBSD Kernel buffer overflow)
I'd suggest that we need to look at this in two ways: (1) There's a compile-time INVARIANT that needs to be maintained by developers in adding new system calls. When building the kernel, it would be useful to have a compile-time assertion that causes a kernel compile to fail if an invalid system call is defined. I.e., when init_sysent.c is generated, it should build in __CTASSERT's that all argument counts are consistent with the requirements of the hardware architecture being built for. (2) There's a run-time INVARIANT issue for loadable modules built by third parties who may not understand the limits on arguments on system calls for various architectures. This can be handled by a check in the system call registration code, although since that's a non-critical performance path, I suggest testing the invariant even if INVARIANTS isn't compiled in. In some ways, I'd rather handle this at compile-time for the module, but I think the infrastructure for hooking up system calls at compile-time for modules will make that more difficult as compared to statically compiled system calls. Completely agree Note that the discussion so far has not addressed the compile-time issue: which is a much better time to perform the tests -- it's something we can test when the kernel is compiled, so why not?. It also hasn't addressed non-i386 systems, such as amd64, which have similar or identical concerns. I was thinking exactly to it while coding patch, but I'm not so experienced with SPARC and/or other architectures to do that With all due respect to the submitter, I think bugtraq was not the forum to post this issue to, as that forum is typically preferred for exploitable vulnerabilities. A follow-up post to clarify that the initial post described a possible avenue for programmer error when extending the kernel, rather than an immediately exploitable vulnerability, might reduce confusion. You're completely right again. I posted on bugtraq beacause somebody else could get a good idea to break code, something I not thought...(so I post this email in hackers@ to let other undestand mine wasn't a exploitable bug report; nobody told exploitable bug user - root or something like that). So what we I have to do? remove INVARIANTS dependency? thanks, rookie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
In [EMAIL PROTECTED], Matt Emmerton [EMAIL PROTECTED] typed: I disagree. It really comes down to how secure you want FreeBSD to be, and the attitude of we don't need to protect against this case because anyone who does this is asking for trouble anyway is one of the main reason why security holes exist in products today. (Someone else had brought this up much earlier on in the thread.) You haven't been paying close enough attention to the discussion. To exploit this security problem you have to be root. If it's an external attacker, you're already owned. That leaves trojans. Those are always a problem for OSS - and for proprietary software. With OSS, you have the option of auditing the code yourself, though that has been beaten (by Ritchie, I believe *). Personally, I trust the FreeBSD committers to not trojan my system - and if they were going to, there are *so* many easier ways to do it. Should I ever decide to run a third party kernel module, I may well audit the code for that module. But I take that risk everytime I install software - whether it's from ports, commercial, or just grabbed off the web. mike *) There was at one time a hacked C compiler that did two evil things. The first evil thing was to recognize the password checking code in login, and generate code that always accepted a back door password as well as the real password. The second evil thing was to recognize the place in the C compiler where the two hacks were, and reinsert them into the generated code. So a source audit would turn up nothing, but the system was thoroughly compromised. -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
In [EMAIL PROTECTED], Matt Emmerton [EMAIL PROTECTED] typed: - Original Message - From: Mike Meyer [EMAIL PROTECTED] To: Matt Emmerton [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Avleen Vig [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, September 18, 2004 1:22 AM Subject: Re: FreeBSD Kernel buffer overflow In [EMAIL PROTECTED], Matt Emmerton [EMAIL PROTECTED] typed: I disagree. It really comes down to how secure you want FreeBSD to be, and the attitude of we don't need to protect against this case because anyone who does this is asking for trouble anyway is one of the main reason why security holes exist in products today. (Someone else had brought this up much earlier on in the thread.) You haven't been paying close enough attention to the discussion. To exploit this security problem you have to be root. If it's an external attacker, you're already owned. I'm well aware of that fact. That's still not a reason to protect against the problem. If your leaky bucket has 10 holes in it, would you at least try and plug some of them? In this case, you're trying to plug holes in a bucket that doesn't have a bottom. Not only that - once you fix the bottom, the holes will be fixed as well. If this qualifies as a security hole, then so does /bin/sh being executable by root. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
- Original Message From: Matt Emmerton [EMAIL PROTECTED] To: Mike Meyer [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: FreeBSD Kernel buffer overflow Date: 18/09/04 05:41 - Original Message - From: quot;Mike Meyerquot; lt;[EMAIL PROTECTED]gt; To: quot;Matt Emmertonquot; lt;[EMAIL PROTECTED]gt; Cc: lt;[EMAIL PROTECTED]gt;; quot;Avleen Vigquot; lt;[EMAIL PROTECTED]gt;; lt;[EMAIL PROTECTED]gt;; lt;[EMAIL PROTECTED]gt; Sent: Saturday, September 18, 2004 1:22 AM Subject: Re: FreeBSD Kernel buffer overflow gt; In lt;[EMAIL PROTECTED]gt;, Matt Emmerton lt;[EMAIL PROTECTED]gt; typed: gt; gt; I disagree. It really comes down to how secure you want FreeBSD to be, and gt; gt; the attitude of quot;we don't need to protect against this case because anyone gt; gt; who does this is asking for trouble anywayquot; is one of the main reason why gt; gt; security holes exist in products today. (Someone else had brought this up gt; gt; much earlier on in the thread.) gt; gt; You haven't been paying close enough attention to the discussion. To gt; exploit this quot;security problemquot; you have to be root. If it's an gt; external attacker, you're already owned. I'm well aware of that fact. That's still not a reason to protect against the problem. If your leaky bucket has 10 holes in it, would you at least try and plug some of them? -- Matt Emmerton So should we stop the command ``shutdown -h now'' from working for root? After all, he can DoS the system with it? How about this: let's disallow root from loading kernel modules! That way this can't ever happen. Even better: Why don't we just not boot into a usable environment! Then we have NO security holes. You guys are failing to see: ROOT HAS OMNIPOTENT POWER. SOMEBODY MUST HAVE OMNIPOTENT POWER. THIS IS NOT A BUG. THERE IS NOTHING TO SEE HERE, MOVE ON. Not to be sarcastic, but you guys are missing the problem. The problem was that someone was unaware of a kernel API. When you start programming for the kernel, you need to make sure that the code is secure. If you think this is a problem, take a look at init(8) and learn about securelevels. What happened: someone was unfamiliar with the syscall API. They crashed their system. They screamed wildly, believing they'd found a buffer overflow, when they'd merely overloaded the function stack and screwed up the call. This caused the system to reboot. Solution: make it more clear that syscalls take only 8 arguments. Make it clear that you can pass arguments in a struct to a syscall. Make it clear that many/most syscalls do this anyway. If there's beef on this, take it to [EMAIL PROTECTED] --Devon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
On 18 Sep, [EMAIL PROTECTED] wrote: Here i report a patch different from Giorgos' one. The approch is completely different: working on syscall_register() function in kern/kern_syscalls.c file. == cat kern_syscalls.diff --- kern_syscalls.c Sat Sep 18 14:37:53 2004 +++ kern_syscalls2.cSat Sep 18 14:37:53 2004 @@ -73,6 +73,11 @@ sysent[*offset].sy_call != (sy_call_t *)lkmressys) return EEXIST; +#if (__i386__) (INVARIANTS) + KASSERT(new_sysent-nargs = 0 new_sysent-nargs = i386_SYS_ARGS, + invalid number of syscalls); +#endif + *old_sysent = sysent[*offset]; sysent[*offset] = *new_sysent; return 0; Why panic the machine at this point? Just refuse to install the syscall and return an error. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
On Sat, Sep 18, 2004 at 12:10:14PM +0200, [EMAIL PROTECTED] wrote: In my post I told that this is *NOT* exploitable but if somebody finds a method? what you can say? In underground comunities it's not so rare, patching is better than having a new exploits for freebsd. I was very deluded by this approach to potential security problem... (I repeat: *POTENTIAL*). You have some different idea from ours. However, I think it might be useful to clarify our idea. 1. A kernel must trust itself in order for it to be efficient. It is not bad to have sanity checks, but checking it repeatly will pose a performance pain. With this in mind, the correct approach might be to have sanity check in the entry point, rather than having it everywhere. This is say, a input procedure must have everything in a sanity state in its early stage and, in addition, same check should not be done in elsewhere because it just repeatly check what is guaranteed to be true, in a production kernel this is not quite useful and even in a debug kernel it is not perferred approach because we don't have to explicitly have if(1==1) or something like this. 2. As many people in this discussion has pointed out, it is necessary to have root access in order to alter a system call. That is say, that in order to successfully exploit this vulnerablity you have to be root first, and we have infinite exploits in this situation, because the attacker already got the ultimate power. We don't need to fear someone who already killed us, right? 3. Security is determined by the weakest tach. With this in concern, let's think about the following scenario: Every system calls have correct sanity check in their entry point while foo() have not. Someone has injected foo() with another way to have some code in kernel. The kernel code exploited the issue you mentioned. But is it actually wrong with the issue? Isn't it the weakest tach within the foo() system call? Shouldn't it be fixed? Hope this is helpful for the debate, and hope I have expressed my idea correctly. With these consideration, I think it is not very necessary to have the sanity check of parameter numbers for a system call entry because it need root access already and if the gain of root is considered harmful, then it's not the sanity of parameter numbers check but the actual problem should be fixed. Cheers, -- Xin LI delphij frontfree net http://www.delphij.net/ See complete headers for GPG key and other information. pgp2eRoGcBFKL.pgp Description: PGP signature
Re: FreeBSD Kernel buffer overflow
Don Lewis wrote: On 18 Sep, [EMAIL PROTECTED] wrote: Here i report a patch different from Giorgos' one. The approch is completely different: working on syscall_register() function in kern/kern_syscalls.c file. == cat kern_syscalls.diff --- kern_syscalls.c Sat Sep 18 14:37:53 2004 +++ kern_syscalls2.cSat Sep 18 14:37:53 2004 @@ -73,6 +73,11 @@ sysent[*offset].sy_call != (sy_call_t *)lkmressys) return EEXIST; +#if (__i386__) (INVARIANTS) + KASSERT(new_sysent-nargs = 0 new_sysent-nargs = i386_SYS_ARGS, + invalid number of syscalls); +#endif + *old_sysent = sysent[*offset]; sysent[*offset] = *new_sysent; return 0; Why panic the machine at this point? Just refuse to install the syscall and return an error. and the test for INVARIANTS is un-needed.. KASSERT only compiles to anything when INVARIANTS is defined. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2004-09-17 03:37, [EMAIL PROTECTED] wrote: If we put your patch in but as a KASSERT then anyone ruinning with debugging turned on (and no-one in their right mind would write a kernel module without turning on debugging, right?) will immediatly find the problem. What you can't understand is that having a limit about arguments is wrong (it's not documented too). Why limiting to 8 and not to 20? or 65? i don't understand... As you have noted in a previous post it's probably more efficient to have a static limit than a fully dynamic implementation. I'm sure we can find a good way to document this and warn the developer who's about to shoot his feet off about potential problems. Would you feel that this limitation of syscall() is not really so important or dangerous if we documented the 8-argument limit, described a good way to pass more arguments and added a KASSERT in trap.c that is only enabled for kernels compiled with INVARIANTS turned on? % Index: lib/libc/sys/syscall.2 % === % RCS file: /home/ncvs/src/lib/libc/sys/syscall.2,v % retrieving revision 1.11 % diff -u -r1.11 syscall.2 % --- lib/libc/sys/syscall.2 10 Sep 2003 19:24:33 - 1.11 % +++ lib/libc/sys/syscall.2 17 Sep 2004 09:35:44 - % @@ -56,14 +56,26 @@ % interface has the specified % .Fa number % with the specified arguments. % +If non-zero, the number of arguments that a system call can have in % +.Fx % +should be at most 8. % Symbolic constants for system calls can be found in the header file % .In sys/syscall.h . % The % .Fn __syscall % form should be used when one or more of the arguments is a % 64-bit argument to ensure that argument alignment is correct. % -This system call is useful for testing new system calls that % +.Pp % +The % +.Fn syscall % +and % +.Fn __syscall % +functions are useful for testing new system calls that % do not have entries in the C library. % +If new system calls require more than 8 arguments you can always wrap % +these arguments in a % +.Vt struct % +and pass a pointer to the new system call. % .Sh RETURN VALUES % The return values are defined by the system call being invoked. % In general, a 0 return value indicates success. % % Index: sys/i386/i386/trap.c % === % RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v % retrieving revision 1.269 % diff -u -r1.269 trap.c % --- sys/i386/i386/trap.c31 Aug 2004 07:34:53 - 1.269 % +++ sys/i386/i386/trap.c17 Sep 2004 09:21:55 - % @@ -965,6 +965,9 @@ % callp = p-p_sysent-sv_table[code]; % % narg = callp-sy_narg SYF_ARGMASK; % +#ifdef INVARIANTS % + KASSERT(0 = narg narg = 8, (invalid number of syscall args)); % +#endif % % /* % * copyin and the ktrsyscall()/ktrsysret() code is MP-aware In my opinion a patch would be better (and even quicker respect KASSERT). A KASSERT() wrapped in #ifdef INVARIANTS has zero overhead for normal, non-debugging kernels. The developers who are responsible for writing and testing new system calls should use INVARIANTS anyway, so they'll quickly catch the mistake. - - Giorgos -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBSrBI1g+UGjGGA7YRAk7RAJ9mfyFTYEzZNK5mDel0lqUom+UayACgpwU1 BF+ypfahuqM4ADVIx6HzO9I= =HLEr -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
:pass more arguments and added a KASSERT in trap.c that is only enabled for :kernels compiled with INVARIANTS turned on? :... : :A KASSERT() wrapped in #ifdef INVARIANTS has zero overhead for normal, :non-debugging kernels. The developers who are responsible for writing and :testing new system calls should use INVARIANTS anyway, so they'll quickly :catch the mistake. : :- - Giorgos KASSERT()'s are only compiled in if INVARIANTS is turned on anyway. If you don't have INVARIANTS turned on, all your KASSERT's go poof. Look at the #define KASSERT in sys/systm.h. I strongly recommend that all kernels always be compiled with INVARIANTS turned on. Even production kernels. I believe GENERIC defaults to INVARIANTS turned on. I'm not sure what is done during release cycles but presumably INVARIANTS is left on for the release build as well (if it isn't it should be). -Matt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
[EMAIL PROTECTED] wrote: Some architectures are limited in the numer of arguments that they allow to be passed as direct values in a syscall. It is considerred pretty bad style to use too many. If one wants to pass more data then it is preferable to have a structure and pass a POINTER to it. I wonder why you repeat obvious things... Because you are not listenning maybe? (as just about everyone on IRC has commented, so it's not just me. I'm just he guy who decided to answer you..). Suggesting that the linit of 8 be upped however is a lot different from coming out of nowhere claining that there is a big problem with buffer over-runs (which are interpretted as security flaws) You don't seem so practice in security. Let me say one thing. A lot of exploits are done for parts initially not exploitable. The fact you and me haven't found a way to do that doesn't mean it can't be done... LISTEN! YOU CAN NOT CHANGE THE NUMBER OF ARGUMENTS ON A SYSCALL UNLESS YOU ARE ROOT ALREADY! OK? if you can then there are much more interesting targets to go after than that.. Nowhere did you suggest that your aim is to increase the number of arguments acceptable to a syscall but rather you presented the problem as a consistency problem. Maybe you need to read again my first advisory. And maybe the whole topic... You did you give an advisory. you gave a misinformed misleading email about something that is not a problem. As a matter of style ond consistency the way that I perceive the developers as taking in our discussions is that 8 is far more than enough and that a debug failure for 8 would be just fine. IMHO is not a good patch, but if you want... If you can show your patch and it is of a high quality then it will be a lot more useful to your cause than making a lot of misleading and misdirected claims on the mailing lists, and wasting everyone's time for a problem that really doesn't exist.. The problem exists. Even a good You can't add more than 8 arguments to your syscall (without wrapping in struct) in some handbook could be useful. I don't thing I'm wasting time of everyone, that's just a bug report and the fact *you* thing is not a problem doesn't mean it doesn't exist. Asking for this fact to be documented somewhere is a far cry from your initial advisory. What you SHOULD have done is as follows. In a private project I am doing I need to add a syscall with more than 8 arguments. In order to allow me to do this I needed to add the following patch. .. [shows patch].. Since this patch is of no real cost and adds functionality, could it please be incorporated. I have submitted it in pr kern/xyzzy That would have gotten you a lot more positive response than a false advisory. (though you would have probably been told by most people to use copyin/copyout and a structure because the syscall interface is one of the parts of the system that is under current scrutiny for improvement and optimisation and people aretupid a likely to consider mor ethan 8 arguments as not a necessity if it slows things down at all. I've been doing this for 30 years and on BSD for 15 years so I DO know what I am talking about when I say that what you pointed out is understood as NOT A SECURITY ISSUE by everyone concerned. It's like complaining that the seats on a jumbo cannot withstand 800C temperature... if you have 800C on the seats you have bigger problems to worry about. so if you decide to rephrse what you want we'll listen to you. if you want to go around making false bug reports then that's ok too but we won't listen.. it's your choice. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
Nobody can write a syscall with more than 8 arguments and this is conceptually wrong. In my opinion this is a mistake, no assumptions might be done on I'd argue that a syscall with 9 or more arguments is conceptually wrong in the first place. Anything with that many knobs needs to be an object, not a simple list of parameters. In other words, you should bundle the parameters up into a struct, and pass a pointer to the struct. Take a look at namei (which used to have a very long argument list) for an example of what I mean. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
On 2004-09-17 02:46, Matthew Dillon [EMAIL PROTECTED] wrote: :A KASSERT() wrapped in #ifdef INVARIANTS has zero overhead for normal, :non-debugging kernels. The developers who are responsible for writing and :testing new system calls should use INVARIANTS anyway, so they'll quickly :catch the mistake. I strongly recommend that all kernels always be compiled with INVARIANTS turned on. Even production kernels. I believe GENERIC defaults to INVARIANTS turned on. In -CURRENT it's enabled for all platforms: : $ grep 'INVARIANTS[[:space:]]' */conf/GENERIC : alpha/conf/GENERIC:options INVARIANTS #Enable calls of extra sanity checking : amd64/conf/GENERIC:options INVARIANTS # Enable calls of extra sanity checking : i386/conf/GENERIC:options INVARIANTS # Enable calls of extra sanity checking : pc98/conf/GENERIC:options INVARIANTS # Enable calls of extra sanity checking : powerpc/conf/GENERIC:optionsINVARIANTS #Enable calls of extra sanity checking : sparc64/conf/GENERIC:optionsINVARIANTS # Enable calls of extra sanity checking I'm not sure what is done during release cycles but presumably INVARIANTS is left on for the release build as well (if it isn't it should be). I'm not sure either. I've been running HEAD for a long time; for an informed answer I'd have to ask the RE people. - Giorgos ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
On Fri, Sep 17, 2004 at 12:59:36AM +0100, [EMAIL PROTECTED] wrote: Inside the kernel? i can define a syscall accepting 30 args and it could send in panic freebsd kernel. I think it's a problem and a patch 'must' occur. You could also define a syscall with no arguments and have it call panic(9). So what? The difference is, that calling panic(9) is not a bug, it's a designed mechanism to panic a kernel. The behaviour reported is NOT designed behaviour (at least, no-one has said it is). Therefore, if the man wants to write a patch to fix unintended behaviour, what's wrong with that? -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
On Fri, Sep 17, 2004 at 07:52:18PM -0700, Avleen Vig wrote: The difference is, that calling panic(9) is not a bug, it's a designed mechanism to panic a kernel. The behaviour reported is NOT designed behaviour (at least, no-one has said it is). Therefore, if the man wants to write a patch to fix unintended behaviour, what's wrong with that? Extra code on a time-critical path with no sane use whatsoever. Note that anyone who adds a syscall (or a library function, for that matter) with that many arguments deserves public humiliation for terminal lack of taste, so it's not going to help anything that wouldn't be worth rm -rf... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
On Fri, Sep 17, 2004 at 07:52:18PM -0700, Avleen Vig wrote: The difference is, that calling panic(9) is not a bug, it's a designed mechanism to panic a kernel. The behaviour reported is NOT designed behaviour (at least, no-one has said it is). Therefore, if the man wants to write a patch to fix unintended behaviour, what's wrong with that? Extra code on a time-critical path with no sane use whatsoever. Note that anyone who adds a syscall (or a library function, for that matter) with that many arguments deserves public humiliation for terminal lack of taste, so it's not going to help anything that wouldn't be worth rm -rf... I disagree. It really comes down to how secure you want FreeBSD to be, and the attitude of we don't need to protect against this case because anyone who does this is asking for trouble anyway is one of the main reason why security holes exist in products today. (Someone else had brought this up much earlier on in the thread.) An article posted today on Slashdot ( http://www.onlamp.com/pub/a/security/2004/09/16/open_source_security_myths.html ) points out that this attitude as a key reason why OSS code isn't neccessarily more secure than commercial counterparts, even though there are more eyes on the source. We have to realize the fact that there *are* insecure FreeBSD installations out there, and because of the OSS nature of FreeBSD, the availability of the source code and public mailing lists like this one (which highlight possible security holes) makes the development of exploits much, much easier. The argument of extra code on a time-critical path is valid, but only if we're concerned about building the fastest BSD out there. However, we can provide a choice to system administrators by wrapping these sanity checks with a runtime if-check of a sysctl value, or a compile-time #define, much like we use for WITNESS or INVARIANTS today. I'm reminded of the old adage of good, fast, cheap -- choose two. There's nothing preventing us from implementing all three and leaving the choice of which two to use up to the end-user. -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
- Original Message - From: Mike Meyer [EMAIL PROTECTED] To: Matt Emmerton [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Avleen Vig [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, September 18, 2004 1:22 AM Subject: Re: FreeBSD Kernel buffer overflow In [EMAIL PROTECTED], Matt Emmerton [EMAIL PROTECTED] typed: I disagree. It really comes down to how secure you want FreeBSD to be, and the attitude of we don't need to protect against this case because anyone who does this is asking for trouble anyway is one of the main reason why security holes exist in products today. (Someone else had brought this up much earlier on in the thread.) You haven't been paying close enough attention to the discussion. To exploit this security problem you have to be root. If it's an external attacker, you're already owned. I'm well aware of that fact. That's still not a reason to protect against the problem. If your leaky bucket has 10 holes in it, would you at least try and plug some of them? -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD kernel buffer overflow
As you point out, [EMAIL PROTECTED] wrote: Topic: Buffer Overflow in FreeBSD Versions: All the versions of FreeBSD are broken (4.x, 5.x, 6.0) Arch: x86 Date: 16/09/2004 A buffer overflow has been found in i386/i386/trap.c syscall() function of FreeBSD official source tree. [...] As you say below this is not exploitable except for root. The number of arguments for a syscall is defined within the kernel and is not supplied from an untrusted source. This means that this is not a security problem.. to load a kernel module you must be root (and not in a jail) meaning that if you wanted to, the quicker and easier exploit would be /bin/sh :-) The arg mask is not there for security, but rather to allow other values to be store in the same longword. It's exploitable, but the only one way I discovered is to link a new syscall to the sysent array and to do this you need to be root; I've no time to work on this vulnerability, but i think another way could be found. However it could give serious problems (e.g. kernel crashes). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
As you point out, Seen i said alredy, why repeating? I was pointing out about the problem, not security issue. Like FreeBSD user I want the patch for this code and I think is useful reporting bug. It's an important part of the kernel so I didn't prepared a patch alredy, I would like to know how core team will move. The number of arguments for a syscall is defined within the kernel and is not supplied from an untrusted source. This means that this is not a security problem. Inside the kernel? i can define a syscall accepting 30 args and it could send in panic freebsd kernel. I think it's a problem and a patch 'must' occur. to load a kernel module you must be root (and not in a jail) meaning that if you wanted to, the quicker and easier exploit would be /bin/sh nice but it doesn't solve the problem. cheers, rookie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
This is standard proceedure. there is no security problem. There is not even a practical problem.. No-one is going to be able to break into your machine because of this unless they have already broken into your machine by some other method. There is an implicit understanding in the kernel that it trusts itrself to be done right.. If you wan to check this I can show you many more things we trust ourselves on in the kernel for example do you check the function pointers in vfs method arrays before calling them? If we checked everything we would never get anything done.. In the end we draw the line at we check values that come from userspace. We trust values that come from root indirectly e.g. when root mounts a filesystem or a kld module. As you have raise dth issue we might add a KASSERT checking that it is within bounds but the check would not be turned on for normal kernels just debug kernels. [EMAIL PROTECTED] wrote: As you point out, Seen i said alredy, why repeating? I was pointing out about the problem, not security issue. Like FreeBSD user I want the patch for this code and I think is useful reporting bug. It's an important part of the kernel so I didn't prepared a patch alredy, I would like to know how core team will move. The number of arguments for a syscall is defined within the kernel and is not supplied from an untrusted source. This means that this is not a security problem. Inside the kernel? i can define a syscall accepting 30 args and it could send in panic freebsd kernel. I think it's a problem and a patch 'must' occur. to load a kernel module you must be root (and not in a jail) meaning that if you wanted to, the quicker and easier exploit would be /bin/sh nice but it doesn't solve the problem. what problem would that be? If you are writing a kernel module then we assume yuo are truted otherwise whoever gave you root privs is in more trouble than a crashed system. cheers, rookie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
On Fri, Sep 17, 2004 at 01:29:22AM +0200, [EMAIL PROTECTED] wrote: Inside the kernel? i can define a syscall accepting 30 args and it could send in panic freebsd kernel. I think it's a problem and a patch 'must' occur. You could also define a syscall with no arguments and have it call panic(9). So what? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
This is standard proceedure. there is no security problem. There is not even a practical problem.. No-one is going to be able to break into your machine because of this unless they have already broken into your machine by some other method. We all agree with it, i worte 3 e-mails ago. There is an implicit understanding in the kernel that it trusts itrself to be done right.. If you wan to check this I can show you many more things we trust ourselves on in the kernel for example do you check the function pointers in vfs method arrays before calling them? This is not the same situation... why an user might change vfs method pointers? Instead if I want to code a syscall accepting 9 arguments I can't do it... and it could be happen! I repeat, a check might be there... If we checked everything we would never get anything done.. In the end we draw the line at we check values that come from userspace. We trust values that come from root indirectly e.g. when root mounts a filesystem or a kld module. Ok, but a syscall of 9 arguments it's not so strange and nobody knows is impossible to realize. As you have raise dth issue we might add a KASSERT checking that it is within bounds but the check would not be turned on for normal kernels just debug kernels. I'm very sorry for this decision. However i will write my patch (would be enough simple) and put it in the web to let other download, but, sincerely, I hoped to cooperate with FreeBSD core team. greetings, rookie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
[EMAIL PROTECTED] wrote: This is standard proceedure. there is no security problem. There is not even a practical problem.. No-one is going to be able to break into your machine because of this unless they have already broken into your machine by some other method. We all agree with it, i worte 3 e-mails ago. There is an implicit understanding in the kernel that it trusts itrself to be done right.. If you wan to check this I can show you many more things we trust ourselves on in the kernel for example do you check the function pointers in vfs method arrays before calling them? This is not the same situation... why an user might change vfs method pointers? Instead if I want to code a syscall accepting 9 arguments I can't do it... and it could be happen! I repeat, a check might be there... If we checked everything we would never get anything done.. In the end we draw the line at we check values that come from userspace. We trust values that come from root indirectly e.g. when root mounts a filesystem or a kld module. Ok, but a syscall of 9 arguments it's not so strange and nobody knows is impossible to realize. If we put your patch in but as a KASSERT then anyone ruinning with debugging turned on (and no-one in their right mind would write a kernel module without turning on debugging, right?) will immediatly find the problem. As you have raise dth issue we might add a KASSERT checking that it is within bounds but the check would not be turned on for normal kernels just debug kernels. I'm very sorry for this decision. However i will write my patch (would be enough simple) and put it in the web to let other download, but, sincerely, I hoped to cooperate with FreeBSD core team. greetings, rookie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
A couple of points: 1) No-one from the FreeBSD core team has participated in this discussion so far. 2) Because you initially claimed that this was a security problem, you prejudiced people against you because it's quite obviously not security-related, as has been discussed. If you'd initially just asked for the sanity check for developers who might accidentally shoot their feet off (this is what Julian suggested in response to you), there would have been little controversy. Kris Hi Kris, you're quite right but: former what I mean to say is that the problem *exists*. Nobody can write a syscall with more than 8 arguments and this is conceptually wrong. In my opinion this is a mistake, no assumptions might be done on number of arguments (I've not seen a documentation about that somewhere too...). Latter, it could be a security problem. I've seen a lot of bug declared *not exploitable* exploitted by other coders after some times. Nothing is impossible. I wanted to point out that. I think this is different respect VFS pointers, don't you agree? rookie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
On Fri, Sep 17, 2004 at 02:50:35AM +0200, [EMAIL PROTECTED] wrote: A couple of points: 1) No-one from the FreeBSD core team has participated in this discussion so far. 2) Because you initially claimed that this was a security problem, you prejudiced people against you because it's quite obviously not security-related, as has been discussed. If you'd initially just asked for the sanity check for developers who might accidentally shoot their feet off (this is what Julian suggested in response to you), there would have been little controversy. Kris Hi Kris, you're quite right but: former what I mean to say is that the problem *exists*. Nobody can write a syscall with more than 8 arguments and this is conceptually wrong. In my opinion this is a mistake, no assumptions might be done on number of arguments (I've not seen a documentation about that somewhere too...). Latter, it could be a security problem. I've seen a lot of bug declared *not exploitable* exploitted by other coders after some times. Nothing is impossible. I wanted to point out that. I think this is different respect VFS pointers, don't you agree? No, it's just another example of what can go wrong if you already have root privileges or make a coding mistake. By the way, thanks for copying my private mail to the mailing list :P Kris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
If we put your patch in but as a KASSERT then anyone ruinning with debugging turned on (and no-one in their right mind would write a kernel module without turning on debugging, right?) will immediatly find the problem. What you can't understand is that having a limit about arguments is wrong (it's not documented too). Why limiting to 8 and not to 20? or 65? i don't understand... In my opinion a patch would be better (and even quicker respect KASSERT). rookie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
On Thursday 16 September 2004 08:50 pm, [EMAIL PROTECTED] wrote: A couple of points: 1) No-one from the FreeBSD core team has participated in this discussion so far. 2) Because you initially claimed that this was a security problem, you prejudiced people against you because it's quite obviously not security-related, as has been discussed. If you'd initially just asked for the sanity check for developers who might accidentally shoot their feet off (this is what Julian suggested in response to you), there would have been little controversy. Kris Hi Kris, you're quite right but: former what I mean to say is that the problem *exists*. Nobody can write a syscall with more than 8 arguments and this is conceptually wrong. In my opinion this is a mistake, no assumptions might be done on number of arguments (I've not seen a documentation about that somewhere too...). Latter, it could be a security problem. I've seen a lot of bug declared *not exploitable* exploitted by other coders after some times. Nothing is impossible. I wanted to point out that. I think this is different respect VFS pointers, don't you agree? You can pass as much as you want by wrapping it in a structure and passing a pointer to the structure as the argument to the system call. See ioctl(2) for examples. People who write system calls that are supposed to be useful are expected to not panic the kernel. :) You demonstrated that in that you found the limit (8 args) and now know to not go over it. :) It's ok to require kernel programmers to think. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
On Fri, Sep 17, 2004, [EMAIL PROTECTED] wrote: If we put your patch in but as a KASSERT then anyone ruinning with debugging turned on (and no-one in their right mind would write a kernel module without turning on debugging, right?) will immediatly find the problem. What you can't understand is that having a limit about arguments is wrong (it's not documented too). Why limiting to 8 and not to 20? or 65? i don't understand... In my opinion a patch would be better (and even quicker respect KASSERT). Hey, until recently, Linux on i386 required a special case for any syscall with over 4 arguments. Supporting 8 makes us twice as good! ;-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
