Heartbleed in Rust

I misunderstood Heartbleed, exactly as Ted summarizes. I've no excuse other than commenting when I shouldn't. I am happy though to have my idiocy corrected as I'll comment better in the future.

The rest of the original thread does point out that I did examine every security advisory published by Microsoft over a year or two span, and that, from the descriptions, Rust would have prevented basically every serious (code exec) one. (Notable exceptions being failures in the sandboxed code loading, similar to the various Java in browser bugs.)

In general, Rust is fairly aggressive about linting for "small" details like unused variables, unreachable code, names that don't conform to expected conventions, unnecessary `mut` annotations, and so forth. I've found that these lints are surprisingly effective at catching bugs.

In particular, the lints about unused variables and unreachable code regularly catch bugs for me. These are invariably simple oversights ("just plain forgot to write the code I meant to write which would have used that variable"), but they would have caused devious problems that would have been quite a pain to track down.

I've also found that detailed use of types is similarly a great way to ensure that bugs like heartbleed are less common. Basically making sure that your types match as precisely as possible the shape of your data -- with no extra cases or weird hacks -- will help steer your code in the right direction. This is a technique you can apply in any language, but good, lightweight support for algebraic data types really makes it easier to do.

That being said I'm a bit more skeptical of this part: "code no true C programmer would write : heartbleed :: code no true rust programmer would write :: (exercise for the reader)"

If I look at the examples in the acticle, the C version doesn't look that terrible and contrieved to me. I wonder what the author means by "Survey says no true C programmer would ever write a program like that, either." That looks like a lot of C code I've read, there's nothing particularly weird about it.

On the other hand the rust version looks very foreign to me (and I've been writing quite a lot of rust lately). You basically have to go out of your way to create the same issue.

I guess my point is that while it's true that as long as there'll be coders there'll be bugs and security vulnerabilities it doesn't mean we shouldn't try to make things better. And in my opinion Rust makes it much more difficult to shoot yourself in the foot than plain C.

There was an argument, about something specific and technical; It was refuted without singling out a specific person by name; without using humiliation or insults; using code to do so ("show me the code!"); and there was a polite acknowledgement and resolution.

This is an example of an interaction in a community that I think anyone would want to be a part of. Thank you.

It's true that you can do terrible things in any language, but the test of a language is how easy it makes it to do the right thing in the common case (plus how possible it makes it to do the thing you want in the uncommon case, without these goals compromising the other).

Is there a reason that reusing the buffer makes sense in Rust? (Zero allocation?)

Also, is it not true that Rust lends itself well, probably better than C, to abstractions like bounds-checked substrings within a single buffer? BoringSSL has been doing this in C, and this definitely would have stopped Heartbleed:

https://boringssl.googlesource.com/boringssl/+/master/includ...

Rust is _memory safe_. Nothing more, nothing less.

http://openmirage.org/blog/introducing-ocaml-tls

Here a Video about Mirage OS and this TLS Stack from the 31C3.

Trustworthy secure modular operating system engineering - http://media.ccc.de/browse/congress/2014/31c3_-_6443_-_en_-_...

There goal is to reduce the trusted computing base to a minimal.

Rust could deliver some of the same benefits to writing highperformance low level code.

    // Rust
    let len = buffer[0] as usize;
    // C
    size_t len = buffer[0];

    let len = buffer[0] as usize;
    // ERROR ERROR ERROR using unscrubbed user input ERROR ERROR ERROR
    buffer[0 .. len]

The original claim was that rust would prevent the class of errors that caused Heartbleed. No one claimed rust would prevent you from writing a program with a different bug that just happens to exhibit similar behavior.

Buffer overruns are tricker to spot than explicitly reusing a buffer.

[Edit] An example of an actual buffer overrun, with no changes to pingback.

C:

    $:/tmp # cat bleed.c
    #include <fcntl.h>
    #include <unistd.h>
    #include <assert.h>

    void
    pingback(char *path, char *outpath, unsigned char *buffer)
    {
            int fd;
            if ((fd = open(path, O_RDONLY)) == -1)
                    assert(!"open");
            if (read(fd, buffer, 256) < 1)
                    assert(!"read");
            close(fd);
            size_t len = buffer[0];
            if ((fd = creat(outpath, 0644)) == -1)
                    assert(!"creat");
            if (write(fd, buffer, len) != len)
                    assert(!"write");
            close(fd);
    }

    int
    main(int argc, char **argv)
    {
            unsigned char buffer2[10];
            unsigned char buffer1[10];
            pingback("yourping", "yourecho", buffer1);
            pingback("myping", "myecho", buffer2);
    }
    $:/tmp # gcc bleed.c  && ./a.out && cat yourecho myecho
    #i have many secrets. this is one.
    #i know your
     one.
    Æ+x-core:/tmp #

    C:\Users\ajanuary\Desktop>cat hearbleed.rs
    use std::old_io::File;

    fn pingback(path : Path, outpath : Path, buffer : &mut[u8]) {
            let mut fd = File::open(&path);
            match fd.read(buffer) {
                    Err(what) => panic!("say {}", what),
                    Ok(x) => if x < 1 { return; }
            }
            let len = buffer[0] as usize;
            let mut outfd = File::create(&outpath);
            match outfd.write_all(&buffer[0 .. len]) {
                    Err(what) => panic!("say {}", what),
                    Ok(_) => ()
            }
    }
    
    fn main() {
            let buffer2 = &mut[0u8; 10];
            let buffer1 = &mut[0u8; 10];
            pingback(Path::new("yourping"), Path::new("yourecho"), buffer1);
            pingback(Path::new("myping"), Path::new("myecho"), buffer2);
    }
    
    C:\Users\ajanuary\Desktop>hearbleed.exe
    thread '<main>' panicked at 'assertion failed: index.end <= self.len()', C:\bot\slave\nightly-dist-rustc-win-64\build\src\libcore\slice.rs:524

The code reflects exactly what the program is doing, and there's no undefined behaviour anywhere. There's no way to access anything outside the very delimited scope of "buffer" memory area, like stack variables or any other part of the program.

What's the point of using a high-level language for re-defining basic low-level operations on buffers and recreating everything using those low-level constructs without the proper boundary checks?

Of course, you can simply define a huge "unsafe" block and program everything inside it, but what's the point? That you have a language powerful enough to shoot yourself?

Compare that to C or C++: the unsafe block is always on. Any code block can have unsafe properties anywhere. Not only that, but you have ZERO guarantees on memory safety and other general operations. Summarizing, high-level and low-level totally mixed and no way to isolate them.

Sorry, but if you can't see how Rust avoids a "Heartbleed" or any other kind of similar issue, you have no understanding of programming or no experience debugging anything.

And yes: security != safety, but please note you are the one mixing both concepts.

Why can you do this?

    let mut outfd = File::create(&outpath);
    match outfd.write_all(&buffer[0 .. len]) { ... }

The example in the docs does something similar:

    let mut f = File::create(&Path::new("foo.txt"));
    f.write(b"This is a sample file");

[0] http://doc.rust-lang.org/std/old_io/fs/struct.File.html#meth...

To put it simply, his examples are the equivalent of doing this:

    unsigned char data[4096];
    #define X (*(int *)(&data[0]))
    #define Y (*(int *)(&data[4]))
    ...

A bit more serious, I wonder which security problems Rust would have, if it would be as well studied as C.

code no true C programmer would write : heartbleed :: code no true rust programmer would write : (exercise for the reader)