Hi,
I've seen a potential problem in my patch; SYF_MPSAFE flag for MP safe syscalls
is not managed; maybe something like that is better:
===
kern/kern_syscalls.c:
--- kern_syscalls.c Sat Sep 18 13:42:21 2004
+++ kern_syscalls2.cWed Sep 22 20:25:22 2004
@@
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
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
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
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];
+
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) /
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
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
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
- 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
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
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]),
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
+
+
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
-- 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
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
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
==
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
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
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
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
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
- 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
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
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
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
-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
: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
[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
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,
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
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
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
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
- 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
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
All discussion refers to CURRENT-6.0, for other versions some things could
change (btw bugged).
Discussion involves a lot of arch x32 dependant mechanisms, so, in some
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
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
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
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
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
[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
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
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
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
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
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
47 matches
Mail list logo
