RE: kld problem
Unloading syscall kernel module can cause a system crash. It occurs when we unload the module while a process is executing our syscall. Example: MOD_QUIESCE (sys/module.h) would be helping you in situations like that. You can use a flag to rule that. greetings, rookie ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Obvious bug in /sys/i386/include/bus.h (was: bus_at386.h)
No, it's a correct method to set/reset the zero flag: (X | X) == X just as (X X) == X Yes but it stores result in ecx(using or, really, is not a problem)... however jecxz just is 2 bytes sized while or + jmp is 4 bytes. It means lesser FDE latency time and the pseudocode is enough similar. greeting, rookie ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Obvious bug in /sys/i386/include/bus.h (was: bus_at386.h)
http://www.freebsd.org/cgi/query-pr.cgi?pr=80980
In FreeBSD 6-current the code for bus_space_write_multi_1() says:
__asm __volatile( \n\
cld \n\
1: lodsb \n\
movb %%al,(%2) \n\
loop 1b:
=S (addr), =c (count) :
r (bsh + offset), 0 (addr), 1 (count) :
%eax, memory, cc);
This is equivalent to:
while(--count)
{
/* I/O */
}
which is obviously wrong, because it doesn't check for count equal to zero.
So
how can I fix this in assembly. I am not an expert with inlined assembly,
so
maybe someone can correct me if I am wrong, but something like this needs
to
be added:
or %ecx, %ecx
jz 2
2:
This is wrong beacause the result is stored in ecx. Better using JECXZ
instruction
before the loop.
Greeting,
rookie
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: X86 machine code enter and FreeBSD kernel
I received no reply on this question at questions mailing list, so I try asking this here. Hope I'm not asking this in completely wrong list. In recent discussion in OpenWatcom lists it was noticed that at least certain addressing modes of assembler ENTER instruction causes a crash when used in Linux. GCC circumnavigates this by not emitting ENTER instructions in machine code. Linus's comment on the above issue can be found on: http://groups.google.co.nz/groups?selm=7i86ni%24b7n%241%40palladium.transmeta.com What's the status of the above feature in FreeBSD, does the kernel support the whole x86 instruction set without similar cut corners? -Reko Mainly, I think gcc sets stack by hands beacause ENTER does a lot of dirty work. If you see x86 pseudocode, it perform a lot of wasting work... however, what you proposed is not a bug, just a way of ruling stack frames. rookie ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A bit confused with the sched_4bsd.c code
Halil Demirezen wrote: Hello, First of all, I am not sure if this is the correct mail list with posting this mail. I apologize for that.. Second, I may seem to have little C knowledge, though I am using C for about 5 years and plus. Let's start with the question. I am digging the FreeBSD-5.3 kernel codes. Watson's Cross Reference is really helpful. In the schedcpu(void) function there is an assignment like ke = td-td_kse; on line 438 (see: http://fxr.watson.org/fxr/source/kern/sched_4bsd.c?v=RELENG53#L438;). When I look at the thread structure at sys/proc.h, I could not see such an entry td_kse in the thread structure. How has this structure been extended or this entry added to the thread structure? Although the kernel codes seem to be simply understandable, there still lies some difficulties to understand for an average C programmer: magic stuff done by professionals. :) Anyway, any help really will be appreciated... Thanks. Look near the top of the file for: #define td_kse td_sched That makes td-td_kse resolve to td-td_sched. Now, there is other magic associated with td_sched in each scheduler source file, but that's different matter =-) If you *really* want to dig inside sources remind that grep is your friend rookie ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: A question about /sys/kern/link_elf.c
There is a #ifdef SPARSE_MAPPING at line 701,and again a #ifdef SPARSE_MAPPING at line 713.I just can't understand the second one.Does it have any special mean ? thanks . It's just conditional compiling construct...however as you can see in the tag For whatever reason, SPARSE_MAPPING is not even a config option, so this is dead code. bye, rookie ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-STABLE kernel build with icc broken
Without intending to start any compiler holy wars, what benefits does ICC provide over GCC for the end user? ICC would provide better low level code (remind: Intel C Compiler. It would mean better performance). rookie ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Low level hardware access in FreeBSD
Hi, I am just wondering how I can access either BIOS calls, or preferably registers under FreeBSD? I am trying to write a simple system capable of displaying graphics on the screen, and I am pretty sure I can mmap the VGA memory to my programs address space. However, to be able to output graphics onto the screen I think I need to change the state of the VGA registers from text mode (I am guessing thats what the console driver uses) to graphical mode (of which i know there exist a couple) - but I think that involves programming registers and I dont know how to do that under FreeBSD. Also, for the FreeBSD console driver to pick the console back up once it finished working, would I be required to reset the VGA registers back to text mode? Thanks, Alex J Burke. FreeBSD runs in protected mode (for x86 processors) so you can't access to BIOS calls directly. You maybe need to see IN/OUT requests for VGA port. rookie ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: syscall list
Hi, I don't remember how to extract the syscall list from the kernel. There was an article some time ago about this, and checking the syscall address to make sure it was not changed in the kernel. Could anyone point me to this article? I've tried to google around but didn't find it. Best Regards In order to mantain ABI compatibility, for every kernel process (sys/proc.h:struct proc *) is provided a struct sysentvec pointer that contains information about syscall table to be handled. Normally (when FreeBSD interface is to be used) it points to sysent array of struct sysent entries. These structures rappresent associations between number of params for every syscall and syscall address (the discussion could be deeper but i guess you need just that), so you can do a little check at them to get what you want. bye, rookie reference: sys/sysent.h ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: syscall: td_retval and zero return value
I have very little assembler/x86 knowledge. Could anyone please help me understand what it means to assign a non-zero value to td_retval in a system call when return value of the call is zero/success? I see in syscall() in src/sys/i386/i386/trap.c (btw is this the right place?) that in such circumstances value from td_retval[] is put into EAX and EDX registers and PSL_C (carry bit) is cleared in status/flags register in a stack frame of a calling process. But I don't understand what it practically means for the calling process. Thank you in advance. The way the handler advice you about syscalls failing is setting (and not clearing as you were saying) the carry bit in eflags register (about ia32). A sort of errno (if you see in a C-coder view) value is set in eax (or, alternatively, edx) to show the reason of failing. There's no way to know where error code is set; you can just verify pratically. You can find all these things on Programmers handbook. cheers, 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 patch
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
@@ -35,6 +35,7 @@
#include sys/mutex.h
#include sys/sx.h
#include sys/module.h
+#include systm.h
/*
* Acts like nosys but can be identified in sysent for dynamic call
@@ -58,6 +59,17 @@
syscall_register(int *offset, struct sysent *new_sysent,
struct sysent *old_sysent)
{
+#ifdef MAX_SYSCALL_ARGS
+ if ((new_sysent-sy_narg ~SYF_MPSAFE) 0 ||
+ (new_sysent-sy_narg ~SYF_MPSAFE) 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;
complete diffs tree to http://www.gufi.org/~rookie/args-diff.tar.gz
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
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]
kernel buff overflow
Maybe you would appreciate more something like that:
===
cat kern_syscalls.diff
--- kern_syscalls.c Sat Sep 18 13:42:21 2004
+++ kern_syscalls2.cSun Sep 19 14:59:27 2004
@@ -58,6 +58,12 @@
syscall_register(int *offset, struct sysent *new_sysent,
struct sysent *old_sysent)
{
+
+#ifdef __i386__
+if (new_sysent-sy_narg 0 || new_sysent-sy_narg i386_SYS_ARGS)
+return E2BIG;
+#endif
+
if (*offset == NO_SYSCALL) {
int i;
___
[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
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]
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]
FreeBSD kernel buffer overflow
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
points, could sound a little bit dark.
A buffer overflow has been found in i386/i386/trap.c syscall() function
of FreeBSD official
source tree.
In order to rule syscalls mechanism, the 'particular' interrupt 128 (0x80)
is provided in the
IDT vector. To serve this interrupt, i386/i386/exception.s int0x80_syscall()
function is
done and, in the end, it calls syscall().
syscall() is responsible for loading arguments from a syscall and copying
them in a kspace
pointer in order to accessing them. The code to do that is the following:
void
syscall(frame)
struct trapframe frame;
{
caddr_t params;
struct sysent *callp;
struct thread *td = curthread;
struct proc *p = td-td_proc;
register_t orig_tf_eflags;
u_int sticks;
int error;
int narg;
int args[8];
u_int code;
...
narg = callp-sy_narg SYF_ARGMASK; (- you can see it's the only one
check)
if (params != NULL narg != 0)
error = copyin(params, (caddr_t)args,
(u_int)(narg * sizeof(int)));
else
error = 0;
...
and:
grep SYF_ARGMASK /usr/src/sys/sys/sysent.h
#define SYF_ARGMASK 0x
It's obvious that the amount of selectable memory is beyond the (8 * sizeof(int))
limit of
args array, so it would overwrite the saved eip by syscall() (it's invoked
through a call) or
making an interesting pointer corruption overwriting struct proc *p .
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).
A good patch could be a dinamyc memory allocation for args, but it's not
a good solution
in order to mantain a well performanced system; another one could be a strongest
check, but it's not a good solution in order to set a good flexibility.
You can get proof of concept code in http://www.gufi.org/~rookie/poc.tar.gz
(all versions).
greetings
rookie
P.S: in order to try the bug before make and link kld, later do 'make test'
and start ./poc exe
___
[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. 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
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
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: KLD and USB driver
I'm working on a usb device driver I've derived from existing drivers in sys/dev/usb (4.10-RELEASE). I can successfully load and unload the module, but the usb subsystem does not appear to see the driver. However if I compile my driver in the kernel, the usb sub system uses the driver correctly. Unfortunately this is making it time consuming to test changes to my driver code as I have to compile the kernel each time. I haven't see this used in the existing usb drivers code, but I tried using the KLD Skeleton from the FreeBSD Architecture Handbook. Although I see the uprintf output at the terminal when load/unloading the module, the usb subsystem does not use my driver. Like the existing usb drivers, I'm using USB_DECLARE_DRIVER and DRIVER_MODULE statements. Is the KLD DECLARE_MODULE code really necessary for this driver (doesn't USB_DECLARE_DRIVER make the driver available already)? How can I determine why the driver works when compiled in the kernel, but not when dynamically loaded? I'm able to load/unload the uhid and ugen drivers and they work as expected. FreeBSD is dived into subsystems and every subsystem contains a certain number of components. To mantain specific order starting subsystems SYSINIT macro is provided by the kernel; very struct sysinit obj has a double-code priority referencing subsystem priority and priority within the subsystem (you can give a look to them in sys/kernel.h, enum sysinit_sub_id and enum sysinit_elem_order enumerations). When you code a generic KLD, DECLARE_MODULE macro is provided to manage linking; between the other things a struct sysinit obj is done (through a call to SYSINIT macro) and initialized within a specified subsystem and with a specified priority inside the subsystem, to let module start properly. DRIVER_MODULE just does that: among the other things, calls DECLARE_MODULE linking the new module in the DRIVERS subsystems. USB_DECLARE_DRIVER, instead, just defines some functions to manage your usb driver. In the end, the real linking is done by DRIVER_MODULE and you should not use DECLARE_MODULE (DRIVER_MODULE alredy does). However for a review of the code the complete source code might be provided. greetings rookie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Problems with tiocget/seta
Some background... For the past three years I have been developing a Forth compiler for Linux. The kernel to my compiler is written in 100% pure assembler using NASM. The object code produced is almost identical to what the Forth compiler itself would produce were it were used to compile its own sources (some day). I accomplish this via liberal use of NASM macros. All I/O etc is accomplished using Linux syscalls, no external libraries are referenced. Linux is my BIOS :) The problem... I consider Isforth to be a worthy project, worthy enough to be ported to other processors and other operating systems. The PPC port is being done by a friend of mine and is almost complete. The FreeBSD port has been nearly complete for about EIGHT months. I am currenty at a complete loss as to how to fix the problem (even though i think i know what it is!) :/ One of the things that my compiler has to do is switch stdin out of canoniacal mode and switch off echo. In Linux the ioctl is working - in fbsd its not. have you get a look to freebsd ioctl request codes? they differ from Linux and FreeBSD. Im almost posative that i am passing correct values to the syscall yet stdin is still buffered after the call and is still echoing. I would truely love to get this up and running in FBSD but am in dire need of help. Im told that if anyone can help me YOU guys can (blame samy for getting you into this :)... If you don't find a solution giving a look to tcsetattr(3) implementation for FreeBSD could be a good idea. rookie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Playing with mbuf in userland
D you mean copying datas between mbuf structure and userspoace pointers or emulating mbuf behaviur in kspace? rookie Hi, i'm developing a little app that manipulates mbuf. Right now i'm still working on it as userland app but i would like to test it with some real mbufs straight from the stack. Do you know how i can get some of these structs in an easy way? I mean, is it possible to copy some of these struct from stack to userland? Or should i fake it in userland? Thank you. -- Paolo Italian FreeBSD User Group: http://www.gufi.org ___ [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: Where is strnlen() ?
I agree but what I was thinking at the time if I'm reciving user input to a program wich uses strlen I might be vonerable to buffer overflow attacks (But that has been cleard up) and ofcourse in most cases you know the length of a string you are using (exept when you are dealing with user input, wich was the case in my porting effort.) And since I'm a pedant I think that interducing new non-standard functions is not an option so I think I will have to turn-my-brain-on as I mentioned in a previous post. Anyways thanks for the replays. I completely agree. Solutions like that (non standard wrappers, run time checking, etc. etc.) ading overhead and could give a false sense of 'security'; security is a state of mind, if you don't care about your code you can't reach really security. my 2 cents rookie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Interrupt 0x80 handling
Hi, giving a look to interrupt 0x80 handling code (i386/i386/exception.s), I've met FAKE_MCOUNT/MEXITCOUNT system. FAKE_MCOUNT in the end calls _mcount (libkern/mcount.c) function which seems to be used for profiling purposes IMHO. It seems (reading comments in sys/gmon.h) that sysctl could be used to manage syscall profiling (kernel profiling?): Somebody can confirm that or I've misunderstood? I would like to know another thing too: why interrupt 0x80 handler is implemented through a trap gate? An interrupt gate could not be more logical? thanks for answers, cheers rookie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
