
There’s a Hole in the Bottom of the C: Effectiveness of Allocation Protection [pdf] - ingve
http://web.mit.edu/ha22286/www/papers/SecDev18.pdf
======
Animats
Short version: yet another hokey scheme for fixing buffer overruns in C fails
for

    
    
       typedef struct {
            char buf[124];
            void* fptr;
        } mystruct;
    

because if you overrun "buf", you can overstore "fptr" without going outside
the bounds of "struct". Exploit for Ngnix found.

We've got to get more code out of C and into something with subscript
checking. None of the kludges for fixing C work.

~~~
writepub
or you could move all pointers to the beginning of the struct, and could even
make the pointer a const (read only).

typedef struct {

    
    
            const void* fptr; 
    
            char buf[124];
    
        } mystruct;

~~~
BagOfPistchios
The const keyword really doesn't mean anything. It is not checked at runtime,
so a buffer-overrun could change the const member regardless

~~~
gpderetta
and even if it were, it is in the wrong position (as defined, fptr is a
mutable pointer to const data).

------
WalterBright
Here's my proposal for fixing buffer overflows in C:

[https://www.digitalmars.com/articles/b44.html](https://www.digitalmars.com/articles/b44.html)

It's simple and it works, we've got 15 years experience with this in D.

~~~
pcwalton
I mean, sure, fat pointers are the "right" solution, but the point of "low-
fat" pointers in the original paper [1] is for greater compatibility with
existing C code, including at the ABI level. Adding fat pointers to C (which
is what your proposal is) is incompatible with those goals. Page 2 of the
paper discusses this.

[1]:
[https://www.comp.nus.edu.sg/~gregory/papers/ndss17stack.pdf](https://www.comp.nus.edu.sg/~gregory/papers/ndss17stack.pdf)

~~~
WalterBright
My proposal does not impact existing C code, and does not make existing C
pointers into phat pointers.

It's purely additive, which means you can incrementally adopt it in places
where it matters.

~~~
pcwalton
It makes a subset of what are currently C pointers—arrays in argument
position—into fat pointers.

~~~
WalterBright
The phat pointers only appear when they are specifically declared as phat
pointers. Existing syntax does not change behavior.

~~~
pcwalton
Yes, and that's a laudable goal, but it's not the same problem as the one the
"low-fat" pointers proposal is trying to solve. The "low-fat" pointers
proposal attempts to improve the safety of _existing_ code.

~~~
xenadu02
Is your complaint that because we don't have a perfect automatic solution we
shouldn't bother offering _any_ solutions, not even incremental opt-in ones?

~~~
pcwalton
I never said fat pointers shouldn't be added to C. The point is that they're
irrelevant to _this_ paper, which demonstrates a weakness in a mitigation
designed to improve safety of _existing_ code.

------
xvilka
Just simply slowly substitute C code, piece by piece into Rust. Building
userspace less depending from C ecosystem.

~~~
carlmr
Yes, at least as long as you're working on a target supported by the Rust
compiler.

------
rurban
> In this paper, we have illustrated a new type of attack that can bypass
> bounds checking spatial memory safety techniques that protect allocations.

No they have not. Bounds checking only outer structs doesnt do bounds checks
on inner buffers. They haven't analyzed traditional bounds checks in C: asan,
fortify, c11 Annex K, Intel MPX, only a broken application, which does none of
these, and uses a wrong bounds check.

------
srfilipek
Without protection function pointers themselves, this only covers a small part
of the issue.

I'm more interested in seeing how CPI and CPS pans out in the end:

[https://dslab.epfl.ch/pubs/cpi.pdf](https://dslab.epfl.ch/pubs/cpi.pdf)

------
nneonneo
tl;dr: the authors overflow from one struct field into another struct field,
thus avoiding any allocation protection scheme that protects individual heap
allocations from each other. Most of the paper is just spent implementing
basic ROP-style gadget hopping.

I’m not actually clear on what’s new or novel here. Allocation protection
mechanisms exist to prevent one allocated block from overflowing into another
allocated block. They usually don’t protect allocated blocks from themselves.

------
bnastic
Hard to read a paper that repeats “legacy languages” many times just on the
first page.

------
acomjean
There's a hole in the bucket... dear liza dear liza.

I suspect the circular never ending problem song might not have been what they
were going for (or maybe it was).

[https://en.wikipedia.org/wiki/There%27s_a_Hole_in_My_Bucket](https://en.wikipedia.org/wiki/There%27s_a_Hole_in_My_Bucket)

