On Thu, 16 Sep 2004 gerarra (at) tin (dot) it [email concealed] wrote:
> narg = callp->sy_narg & SYF_ARGMASK; (<- you can see it's the only one
> check)
At this point, callp points to the sysent entry for a particular
system call that is to be called. These entries are not under
the control of the attacker (unless, as you point out, you
are root and you add a new system call to the system).
If there's an entry in the system call table with a sy_narg
field greater than 8, then yes, there will be a buffer overflow.
However, the programmers who wrote the kernel don't provide
you with any such system calls.
> 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).
On Thu, 16 Sep 2004 gerarra (at) tin (dot) it [email concealed] wrote:
> narg = callp->sy_narg & SYF_ARGMASK; (<- you can see it's the only one
> check)
At this point, callp points to the sysent entry for a particular
system call that is to be called. These entries are not under
the control of the attacker (unless, as you point out, you
are root and you add a new system call to the system).
If there's an entry in the system call table with a sy_narg
field greater than 8, then yes, there will be a buffer overflow.
However, the programmers who wrote the kernel don't provide
you with any such system calls.
> 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).
> rookie
Tim N.
[ reply ]