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: "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 > > 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]"
FreeBSD Kernel buffer overflow
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; == > cat trap.diff --- trap.c Sat Sep 18 14:38:00 2004 +++ trap2.c Sat Sep 18 14:38:00 2004 @@ -902,7 +902,7 @@ u_int sticks; int error; int narg; - int args[8]; + int args[i386_SYS_ARGS]; u_int code; /* == > cat cdefs.diff --- cdefs.h Sat Sep 18 14:37:38 2004 +++ cdefs2.hSat Sep 18 14:37:38 2004 @@ -467,4 +467,6 @@ #endif #endif +#define i386_SYS_ARGS 8 + #endif /* !_SYS_CDEFS_H_ */ The main improvement is that it doesn't affect handler performance (even in INVARIANTS compiled kernels) and check is done once. It could be enough clear. You can download tgz in http://www.gufi.org/~rookie/args-diff.tar.gz goodbye, 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: Editing and compiling FreeBSD source
On 2004-09-17 21:31, Andrew Novikov <[EMAIL PROTECTED]> wrote: > On Tue, 14 Sep 2004 08:54:02 +, [EMAIL PROTECTED] wrote: > > This is my first e-mail for this list. > > I am interested in studing to better understand FreeBSD?s source code. > > With 'make buildkernel' and 'make installkernel' is it possible to > > compile the changes that I have made? > > The changes are simple (just some printf). I am just beginning this > > trip through FreeBSD?s source code. > > yes, as long as your changes were made under /usr/src/sys/ If the changes are trivial (i.e. just an extra printf() call, as suggested above) you might even get away with something faster: # cd /usr/src # make -DNOCLEAN buildkernel or even, by directly using "make" in the object directory, i.e.: # cd /usr/obj/usr/src/sys/SOLERO # make && make install Before you start taking such shortcuts though, you should definitely get acquainted with the build process of FreeBSD. The Handbook contains an entire chapter on building and installing from the sources. Please read it carefully. As many times as it takes... Regards, 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
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. 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: Editing and compiling FreeBSD source
In <[EMAIL PROTECTED]>, Cantarella <[EMAIL PROTECTED]> typed: > >This is my first e-mail for this list. >I am interested in studing to better understand FreeBSD´s source code. >With 'make buildkernel' and 'make installkernel' is it possible to >compile the changes that I have made? >The changes are simple (just some printf). I am just beginning this >trip through FreeBSD´s source code. That will work, but it's the painfull way to do it. The old way is easier to do development with: 1) cd /usr/src/sys/i386/conf 2) config YOURCONFIG 3) cd ../../compile/YOURCONFIG 4) make depend 5) make install You only have to go back to step 1 if you touch the config file. You only have to go back to step 4 if you add #include statements to a source file. Most of the time, you simply redo the "make install", and it only recompiles what you've changed and relinks the kernel. buildkernel and installkernel will recompile everything every time. This won't remake kernel modules - but you can do "make's" in /usr/src/sys/modules/* to deal with those. 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. 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: "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 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 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: add-symbol-file
Greg, I am not using remote debugging, that's why I made a call to kldsyms (local system) but it only loaded acpi.ko. May be I should try over a serial console. The system wasn't crashed or in db prompt though. As for the question regarding where I got the addresses from, I typed: asf -k -f -s -x modulepath .asf, this created the ".asf" file and its contain was "add-symbol-file /usr/local/src/nren-6.0current/osr_src/if_osr.ko 0xc24b3184 -s .data 0xc24b6900 -s .bss 0xc24b6cc0" then I copied and past it to the kgdb prompt, all went ok. but when I want to list *0xc24b3184, it complained about "No source code available" or something like that. That's where I am puzzled. I will do what you suggested and over serial console and repost if any problems. Thank you, Jerry > > It looks like you're not doing it the way it was intended. As it > > says: > > Type 'getsyms' after connection to load kld symbols. > > This does the add-symbol-file for you. Take a look at gdb(4) for more > details. > > > If you're debugging a local system, you can use 'kldsyms' instead > > to load the kld symbols. That's a less obnoxious interface. > > doadump () at pcpu.h:159 > > (kgdb) add-symbol-file /usr/local/src/nren-6.0current/osr_src/if_osr.ko > > 0xc24b3184 -s .data 0xc24b6900 -s .bss 0xc24b6cc0 > > I'm assuming that this was broken by your MUA, and it's not the way > > you put it in, which must have been: > > (kgdb) add-symbol-file /usr/local/src/nren-6.0current/osr_src/if_osr.ko > > 0xc24b3184 -s .data 0xc24b6900 -s .bss 0xc24b6cc0 > > Where did you get these addresses from? They're all outside the > bounds of the kld as shown below. > > > > > In any case, I'm not sure that you need getsyms any more. It used to > be needed to get round various gdb restrictions. What happens if you > don't do anything? If that doesn't work, how about running getsyms, > as suggested? Please let me know either way what happens. > > Greg ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
