Re: [9fans] Undefined Behaviour in C

[Charles Forsyth <charles.forsyth@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2569 bytes --]

The link to the lwn.net article explains that using mmap the naughty
application mapped a page to virtual 0, which was then available in kernel
mode in that process, and all they'd need to do is put their own "socket"
structure at 0 + offsetof(struct tun_struct, sk).

On 25 November 2015 at 10:43, Brantley Coile <brantleycoile@me.com> wrote:

> Just curious, will Linux not panic when the kernel deterrences a nil
> pointer?
>
> Sent from my iPad
>
> On Nov 25, 2015, at 5:27 AM, Alexandru Gheorghe <alghe.global@gmail.com>
> wrote:
>
> On 11/23/2015 01:20 PM, Vasudev Kamath wrote:
>
> Ramakrishnan Muthukrishnan <ram@rkrishnan.org> <ram@rkrishnan.org> writes:
>
>
> Had been reading the SOSP paper:<https://pdos.csail.mit.edu/papers/stack:sosp13.pdf> <https://pdos.csail.mit.edu/papers/stack:sosp13.pdf>
>
> and this blog post that proposes a simpler C:<http://blog.regehr.org/archives/1180> <http://blog.regehr.org/archives/1180>
>
> I started reading the paper and its interesting. I didn't knew till date
> how optimizations really worked and why they were considered harmful.
>
>
> They can be quite harmful, the dereference example of *tun->sk* is a
> popular example that dates from 2009 regarding the Linux Kernel being
> exploited by Spender (Brad Spengler): https://lwn.net/Articles/342330/
>
> "a NULL pointer was dereferenced before being checked, the check was
> optimized out by the compiler, and the code used the NULL pointer in a way
> which allowed the attacker to take over the system"
>
>
> Funny because Spengler did try many times to introduce better security in
> the Linux Kernel (see his set of patches in collaboration with the PaX
> Team: GRSEC) but was refused many times by the community and Linus in
> particular due to performance penalties (among other "opinions"). Which
> again opens the question where exactly is the undefined behavior problem?
> Resides on the programmer or on the compiler (and its programmers)? And how
> do you deal with the performance side? Because clearly, if you introduce
> more security then you will start having penalties on it; I guess the
> question is how much are you willing to let go in preference of more
> security and stable systems?
>
> It's a very interesting paper, I only read 7 pages but will soon finish it
> and go ahead with the references (probably it links the example I wrote in
> the beginning of this e-mail).
>
> Thanks for sharing.
>
> --
> ; Alexandru Gheorghe
> ;
> ;       aGlobal
> ; <alghe.global gmail com>
>
>

[-- Attachment #2: Type: text/html, Size: 3624 bytes --]