This shouldn't have happened: A vulnerability postmortem

Post by muricula » Wed, Dec 01, 2021, 11:10 PM UTC

senderista wrote: post #140

openasocket wrote: post #92

Earlier quoted context omitted.

There's different classes of memory un-safety: buffer overflow, use after free, and double free being the main ones. We haven't seen a mainstream language capable of preventing use and free and double free without GC overhead until Rust. And that's because figuring out when an object is genuinely not in use anymore, at compile time, is a really hard problem. But a buffer overflow like from the article? That's just a…

> We haven't seen a mainstream language capable of preventing use and free and double free without GC overhead until Rust. Sorry, that just isn’t the case. It is simple to design an allocator that can detect any double-free (by maintaining allocation metadata and checking it on free), and prevent any use-after-free (by just zeroing out the freed memory). (Doing so efficiently is another matter.) It’s not a language o…

    struct AttackerChosenColor {
        size_t foreground_color;
        size_t background_color;
    };
    struct Array {
        size_t length;
        size_t *items;
    };

    int main() {
    // A program creates an array, uses it, frees it, but accidentally forgets that it's been freed and keeps using it anyway. Mistakes happen. This sort of thing happens all of the time in large programs.
    struct Array *array = new Array();
    ...
    free(array); // Imagine the allocation is zeroed here like you said. The array length is 0 and the pointer to the first item is 0.
    ...
    struct AttackerChosenColor *attacker = new AttackerChosenColor();
    // The allocator can reuse the memory previously used for array and return it to the attacker. Getting this to happen reliably is sometimes tricky, but it can be done.

    // The attacker chooses the foreground color. They choose a color value which is also the value of SIZE_T_MAX.
    // The foreground_color *overlaps\* with the array's length, so when we change the foreground color we also change the array's size.

    // Now say the attacker is able to reuse the dangling/stale pointer.
    // Say that they can write a value which they want to wherever they want in the array. This is 
    // Like you suggested it was zeroed when it was freed, but now it's been recycled as a color pair and filled in with values of the attacker's choosing.
    // Now the attacker can write whatever value they want wherever they want in memory. They can change return addresses, stack values, secret cookies, whatever they need to change to take control of the program. They win.
    if (attacker_chosen_index length) {
         array->items[attacker_chosen_index] = attacker_chosen_value;
    }
    }

Post by eyelidlessness » Wed, Dec 01, 2021, 11:15 PM UTC

fleventynine wrote: post #85

slownews45 wrote: post #13

Wow. We continue to be reminded that it's hard to write fully memory secure code in a language that is not memory secure? And by hard, I mean, very hard even for folks with lots of money and time and care (which is rare). My impression is that Apple's imessage and other stacks also have memory unsafe languages in the api/attack surface, and this has led to remote one click / no click type exploits. Is there a point a…

My language selection checklist: 1. Does the program need to be fast or complicated? If so, don't use a scripting language like Python, Bash, or Javascript. 2. Does the program handle untrusted input data? If so, don't use a memory-unsafe language like C or C++. 3. Does the program need to accomplish a task in a deterministic amount of time or with tight memory requirements? If so, don't use anything with a garbage c…

Post by fleventynine » Wed, Dec 01, 2021, 11:21 PM UTC

eyelidlessness wrote: post #184

fleventynine wrote: post #85

Earlier quoted context omitted.

My language selection checklist: 1. Does the program need to be fast or complicated? If so, don't use a scripting language like Python, Bash, or Javascript. 2. Does the program handle untrusted input data? If so, don't use a memory-unsafe language like C or C++. 3. Does the program need to accomplish a task in a deterministic amount of time or with tight memory requirements? If so, don't use anything with a garbage c…

Answering a question with a sincere question: if the answer to 3 is yes to deterministic time, but no to tight memory constraints, does Swift become viable in question 4? I suspect it does, but I don’t know nearly enough about the space to say so with much certainty.

Post by pcwalton » Wed, Dec 01, 2021, 11:25 PM UTC

senderista wrote: post #140

openasocket wrote: post #92

Earlier quoted context omitted.

There's different classes of memory un-safety: buffer overflow, use after free, and double free being the main ones. We haven't seen a mainstream language capable of preventing use and free and double free without GC overhead until Rust. And that's because figuring out when an object is genuinely not in use anymore, at compile time, is a really hard problem. But a buffer overflow like from the article? That's just a…

> We haven't seen a mainstream language capable of preventing use and free and double free without GC overhead until Rust. Sorry, that just isn’t the case. It is simple to design an allocator that can detect any double-free (by maintaining allocation metadata and checking it on free), and prevent any use-after-free (by just zeroing out the freed memory). (Doing so efficiently is another matter.) It’s not a language o…

Post by jmull » Wed, Dec 01, 2021, 11:28 PM UTC

Gigachad wrote: post #168

jmull wrote: post #159

Earlier quoted context omitted.

Well, there's no time machine. Also, as far as I know, a full replacement for C doesn't exists yet.

Are you suggesting that this crypto library would not be possible or practical to be built with rust? What features of C enable this library which Rust does not? There is no time machine to bring rust back to when this was created, but as far as I know, there is no reason it shouldn't be Rust if it was made today.