linux-kernel - Re: [PATCH] Introduce compat_u64 and compat

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 15 Jun 2007 23:22:06 +0200
From:	Andi Kleen <ak@...e.de>
To:	Robin Getz <rgetz@...ckfin.uclinux.org>
Cc:	"Alan Cox" <alan@...rguk.ukuu.org.uk>,
	"David Howells" <dhowells@...hat.com>,
	"Arnd Bergmann" <arnd@...db.de>,
	"Benjamin Herrenschmidt" <benh@...nel.crashing.org>,
	"David Woodhouse" <dwmw2@...radead.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Dave Airlie" <airlied@...ux.ie>, linux-arch@...r.kernel.org,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	Bernd Schmidt <bernds_cb1@...nline.de>
Subject: Re: [PATCH] Introduce compat_u64 and compat_s64 types

> For the architecture we use (Blackfin), it does not support unaligned
> accesses, and we purposely never put in the trap/fixup code - we trap, and
> printk("fix your source");

For the kernel you should fix up too in addition to the printk. Otherwise
you risk a ping of death in the field with some more obscure protocol.
Also the printk should be load limited.

> > > people have done
> > > that work so using the types without unaligned.
> >
> > Very brave; we're talking about around half a million lines
> > of non trivial source code here.
>
> Is there something specific that you can think of that we should be
> testing?

A lot of protocols have variable length headers.  Normally everything
is aligned, but an attacker could purposefully misalign some headers
using variable length padding, causing fields in later headers to be 
misaligned.

e.g. the original reason this was forbidden was because the TCP
option parser could be tricked into reading time stamps unaligned.
That code is now using get_unaligned(), but there are probably
other culprits too (there is a lot of code in the network stack) 

Unfortunately it is hard to test all combinations, so the only safe 
alternative would be to audit source code. Another possibility would be to
use a tainted data scheme similar sparse's __user/__iomem annotations with
a static code checker (or extending sparse), but that would also require a lot 
of work to do properly and add the necessarily annotations.

Also watch out for netfilter modules -- they make all this much more 
complex. And drivers possibly too.

> We have done alot of testing, and people have shipped alot of systems
> connected to a varity of networks, and have run all kinds of protocols on
> them.

Well behaved peers normally don't generate unaligned headers. But
that doesn't mean it couldn't be exploited by someone malicious.

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