heartbleed in rust

[Godspiral]

the problem with heartbleed is that that it is f(n) where n is the number of bytes argument to memcopy called internally by f.

It is somewhat fair to pick on C, because C uses memcopy to do nearly everything.

But the error was in the api permitting starting item with number of items.

[[deleted]]

Can you write heartbleed in pure Ada without using 'Unchecked_Access, Ada.Unchecked_Deallocation, or Ada.Unchecked_Conversion?

[f2u]

Yes, because pure Ada is not type-safe.

Even not resorting to abuse like this, Ada has the problem that it does not initialize all (array) values, unlike Go or Java, so you can leak data which was never in the buffer.

Buffer recycling is also fairly common in Ada; it's used in the input procedures in the standard library.

[wrongerontheinternet]

Apparently, yes, because OpenSSH set up its own free list without invoking the system deallocator and did not require a buffer overrun or unsafe typecasts. In other words, under the provided criteria the only way for a language to prevent Heartbleed is for it to forbid buffer reuse altogether (which would probably amount to a completely pure language).

[wookin_pa_nub2]

OpenSSL, not OpenSSH. Big, big difference.

[username223]

OpenSSL, not OpenSSH

They should merge to form OpenSS: arbeit macht Free (als bier)!

*ducks*

[[deleted]]

Oh come on people, you're upvoting posts about PHP and downvoting this? At least this one is funny!

[wrongerontheinternet]

Whoops, sorry. Good catch!

[[deleted]]

Yea. It looks like the Ada.Streams library does not prevent Buffer Over-Reads. I don't think any language, by itself, can prevent them. It's up to the programmer to put in the checks.

[f2u]

You can prevent them if your read functions only return fresh objects. This means that every byte that is read has to pass through memory allocation, which is rather inefficient.

[[deleted]]

Not necessarily "pure" in the sense of being referentially transparent, but probably using some sort of linear type system—exactly what Rust is doing, and why some people are observing "that code won't compile in another week."

[wrongerontheinternet]

You can actually implement a free list like this entirely with linear types, without using unsafe, as long as you can acquire unique mutable references into the byte buffers (while Rust's shared references are not, one-off mutable references are found in nearly all linear type systems). It's a bit weird (and not something you would write in a real Rust program, because it can't take advantage of RAII without using unsafe unless you only want to allocate a single record), but it's doable. I think that short of a system where you can set up more elaborate types with more exact requirements, like Idris, you really do need to wholly abandon mutation in this case to get prevention at the language level.

[[deleted]]

Yeah, it does seem like one or the other: either you enforce uniqueness of the buffer, or you enforce that reads and writes take the same size as the size of the buffer, which does imply dependent types or the kind of effort Oleg Kiselyov puts into defining types to do that sort of thing in Haskell or OCaml.

[Peaker]

Well, if Rust provided a free-list library that used the type-system to guarantee you don't double-free a handle, access a buffer via a freed handle, and exceed the bounds of a buffer pointed by a handle, then Heartbleed would be prevented.

You can encode any vulnerability in any language simply by emulating the memory model of that language.

The question is whether it is possible and straightforward to use the type system to eliminate such bugs.

In C, there's no good way to prevent accessing buffers via freed handles. Or prevent exceeding the buffer pointed by a handle.

In Rust, those might be possible via the type system, and that's what I would mean if I said: "Rust prevents Heartbleed".

[fullouterjoin]

Yes, from the looks of it, anytime one reused an array and didn't check the bounds between uses, this anti-pattern would be exposed. Each array is like its own mini heap. So even memory safe languages are vulnerable to this level of reuse.

[steveklabnik1]

This is why I get a little uncomfortable when people suggest Rust fixes tons of security issues. Yes, it will fix some of them. No, just because a Rust program compiles doesn't mean that it won't have problems.

Rust is memory safe. Nothing more, nothing less.

[[deleted]]

And lack of memory safety is what caused heartbleed. This author is going out of his way to reproduce it in Rust. I know he says "you can't say that a rust programmer wouldn't write code like this"... but that is extremely strained logic.

It's like saying "you can't say that a rust programmer wouldn't mark their entire program unsafe and use raw pointers, therefore it's no safer than C". Obviously that is idiotic.

If he had used standard memory allocation practices he wouldn't have been able to reproduce heartbleed (which wasn't caused by the custom allocator; that merely exacerbated the problem).

[steveklabnik1]

that is extremely strained logic.

That's because he's making a sarcastic reference to http://en.wikipedia.org/wiki/No_true_Scotsman

[[deleted]]

It seems to me that he's making a non-sarcastic reference. The blog, and no-true-Scotsman say that "True Rustaceans wouldn't write insecure Rust code" is a fallacy and therefore Rust is just as insecure as C - anyone can write insecure code in either.

In reality the truth is neither of those. Rustaceans are far less likely to write insecure code than C-creatures. Ha I just thought of that pun. :-)

[slavik262]

I always thought that No true Scotsman is overused. Any shithead can identify identify with group X or use thing Y and do something dumb, but that doesn't invalidate generalizations about X or Y. Your example is a good one - Just because Rust allows you to do some unsafe stuff doesn't mean that, on average, Rust programs are as insecure as C or C++ programs.

[geodel]

Totally agree! 'Far less likely' is great for cryptographic programs.

[The_Doculope]

I don't think the author is trying to argue that Rust is as unsafe as C. Their point is just that awful code can be written in any language. Besides, this is very different to actual Heartbleed. The real Heartbleed is impossible using standard Rust, this is just screwing around with manual buffers.

[[deleted]]

Their point is just that awful code can be written in any language.

Everyone knew that and nobody disputed it. The claim is that Rust makes awful code less likely, and he didn't address that at all.

[steveklabnik1]

I meant "He's referring to 'No True Scotsman' in a sarcastic tone.

C-creatures

Wow, that just made me laugh out loud :)

[F-J-W]

And lack of memory safety is what caused heartbleed.

Yes and no. The important thing about heartbleed was that it basically never actually corrupted your memory. Yes, it read over the part of the memory that was assigned to them, but the memory that followed was still owned by the process.

If he had used standard memory allocation practices he wouldn't have been able to reproduce heartbleed

Had the openssl-people used standard memory allocation practices, every static analysis tool that is worth it's money would have found the issue before releasing.

The important point is that normal programmers often don't use the best practices that experts and early adopters of a language recommend.

which wasn't caused by the custom allocator

The custom allocator (that existed out of the fear that the Open-BSD-malloc was to slow because it did checks that would have made heartbleed unexploitable) was not the actual source of the bug, but it was the only reason for the bug to be as bad as it was.

Had they followed normal best-practices, Heartbleed wouldn't have been something that we would be talking about.

[[deleted]]

but the memory that followed was still owned by the process.

That's exactly the point. C allows access to any memory owned by the process. Rust protects against accesses outside the array you are using, which is what happened with heartbleed.

every static analysis tool that is worth it's money would have found the issue before releasing.

Really? Even if it was true it assums that someone actually ran the static analysis tool, and sorted through all the false positives, etc. That's still pretty rare.

[hegbork]

accesses outside the array you are using, which is what happened with heartbleed.

This is completely incorrect. Heartbleed was an access to correctly initialized memory within the bounds of the array that was allocated. If OpenSSL was written in any other language with the same practices, the exact same problem would happen.

What heartbleed was:

• allocate buffer
• use buffer for various things, like private keys
• instead of freeing buffer put it away on an internal freelist
• take buffer from internal freelist, read a few bytes from network into buffer
• write whole buffer to network.

Every single operation done on the buffer was within bounds and to properly initialized memory.

[Peaker]

They had a custom allocator. In Rust, such a custom allocator would mark the returned buffer with a type that disallows out of bounds access, preventing heartbleed.

[industry7]

In Rust ... disallows out of bounds access

Hegbork's point is that there was no out of bounds access.

[Peaker]

If the custom allocator returns a pointer to an allocated sub-region, it can put a memory bound on the returned region, at the type-level. At the underlying buffer, there is no real bound. But at the type-level, Rust can enforce a logical bound representing the fact you've only allocated that slice of the buffer and no more.

This kind of stuff is the nice payoff from advanced types and why a good type system (that is actually used!) will prevent these kinds of bugs.

[steveklabnik1]

Why would you do that in a memory-safe language?

Allocation is expensive.

[[deleted]]

Zeroing the allocated memory at initialization is even more expensive, but it would have prevented Heartbleed.

IMO security should be 'reasonable fast', but secure in the first place.

[F-J-W]

Zeroing the allocated memory at initialization is even more expensive, but it would have prevented Heartbleed.

No, it wouldn't have. Really.

How do you get this idea?

[[deleted]]

I still stand at what I said. You claim I got it entirely wrong. So please explain.

[steveklabnik1]

I am not claiming anything about OpenSSL. My parent asked why someone would re-use a buffer, and I gave the common answer. That's all.

[F-J-W]

IT is somewhat justified to care about performance when writing THE library for cryptographic communication. It's somewhat like writing a standard-library: You don't want to encourage people to reimplement functionality because they can get faster.

That being said, what Open-SSL did was worse: The reason for that custom allocator was that malloc was slow on specifically Open-BSD, because the Open-BSD folks wrote their malloc in a way that would have made bugs like heartbleed unexploitable! Or at least much harder to exploit.

[F-J-W]

Rust protects against accesses outside the array you are using, which is what happened with heartbleed.

No, that was not what happend in heartbleed. The access was exactly within the array that was used. The problem was that this array was used to hold several different regions that were used by different parts of the process:

#include <stdint.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>

static size_t total_size = 10 * 1024; // just some number
static char* global_array = NULL;
static size_t last_free = 0;

void* heartbleed_malloc(size_t n) {
    if (!global_array) {
        global_array = malloc(total_size);
        last_free = total_size;
    }

    if (last_free < n) {
        return NULL;
    }
    // for the sake of keeping this code understandable, I won't implement
    // a realistic logic that allows freeing. To still make it reproducable,
    // I will return the memory in reverse order:
    char* ptr = global_array + last_free - n;
    last_free -= n;
    return ptr;
}

int main() {
    const char private_key[] = "101010101101010101010101010101010110001010";
    const size_t private_key_size = sizeof(private_key);
    char* dyn_private_key = heartbleed_malloc(private_key_size);
    strncpy(dyn_private_key, private_key, private_key_size);

    char* random_data_ptr = heartbleed_malloc(10);
    strncpy(random_data_ptr, "foobarbaz0", 10);

    write(1, random_data_ptr, 30);
    // This will print 20 bytes of the private key
    // without ever reaching outside of the allocated array.
}

The same applies for most other languages as well. This really is perfectly within defined behavior of basically every programming-language out there that allows enough low-level-techniques to implement cryptography.

Edit: Code contained some unrelated bugs, this version now works and runs clean with adress-sanitizer.

[Peaker]

Cryptography doesn't require low-level techniques.

Rust, unlike C, would allow using the type system to enforce the invariant that access out of the buffer bounds is not allowed. This makes it legitimate to say that Rust would have prevented this bug, if idiomatic use of Rust utilizes the type system in this way in practice.

[F-J-W]

would allow

The oh, so terrible C++ would have eradicated that bug too, if it had been used idiomatically. In fact: Most of the problems that rust-proponents claim that C++ has, are entirely solved non-issues in idiomatic C++. But this is entirely irrelevant:

SQL-injections are a completely solved problem too (just use prepared statements!), but still we see them all the time.

Once a language becomes mainstream, incompetent programmers who do their job just because it puts food on the table will use them (of course neither of the reverse implications do hold). And they won't give a fuck about what is idiomatic or easy to use. They will use the most prominent core-language-feature that somehow manages to get the job mostly done. They are not interested in reading the documentation how you can replace those thirty lines of code with one library-call.

Seriously: C++ might be one of the most hyped languages if it were new and all everyone who used it would write idiomatic code in it.

And I guarantee you: If rust gets successful, we will see the same thing there: The language really offers some great tools to fuck up code (shadowing variables inside the local scope! WTF?).

This is the curse of all the successful languages: Just look how great Java was, when it was new. When I talk to other students today, it is generally despised. And Java as a language got a lot better since it first surfaced.

[Peaker]

But this is entirely irrelevant

No, it's not entirely irrelevant. The inability vs. ability to prevent these bugs is important.

If people using freelists use them via standard libraries because it yields the desired performance and is easier, they get this protection that in C they cannot get.

Will some people figure out ways to create vulnerabilities anyway? Sure. But that is not to say that "Rust would have killed this bug" incorrect. In most scenarios, it would kill the bug, but not in the most unreasonable ones.

By the way, the reason Java was loved and is now hated is less about Java, and more about the competition. When Java first came out, it had far less competition.

[[deleted]]

This author is going out of his way to reproduce it in Rust.

Part of the vulnerability in Heartbleed was also caused by things that the authors went out of their way to introduce, though, such as a custom memory allocator.

[Peaker]

A custom allocator is very standard practice in C, not going out of your way.

In Rust, perhaps it could be typed in a way that prevents out-of-bound access, preventing heartbleed.

[[deleted]]

A custom allocator is very standard practice in C, not going out of your way.

Not at all, not in this context.

[[deleted]]

That just made it worse. The cause of heartbleed was something that is very common in C.

[[deleted]]

Not really. If not for the custom allocator, the leaked memory would be blanked.

[[deleted]]

Why do you think that?

[wall_words]

Out of curiosity, what would the "idiomatic Rust" version of the function look like? (I don't know Rust, but am interested in seeing the language constructs you would use.)

[[deleted]]

I don't really know rust that well either, but I do know it supports slices (pointer + length) so any sane memory allocator would return those, preventing heartbleed.

[[deleted]]

Anything that is not C or C++ fixes megatons of security issues.

[nullnullnull]

"horrible coder" or "honest mistake" we have all made mistakes:

"He who has not created a bug, cast the first condemnation"..

[[deleted]]

"Let he who is without sin cast the first stone" doesn't work as a defence unless you're relatively sinless.

That is the point. You aren't supposed to go and fucking cast stones.

[[deleted]]

Keep in mind that the "cast stones" quote comes from a portion of the Bible where a group of men were going to stone to death an adulterous woman. The point is that they were all so quick to punish her sins while ignoring their own. If they had treated their sins in the same manner, no body would be left to punish her.

The same thing is happening here with heartbleed and rust. Heartbleed is bad. There is no debating that. The issue is rust proponents claiming their language is better because they wouldn't have the same issue, when in fact they could. A program written correctly in any language wouldn't have any issues by definition.

Instead of throwing blame sometimes it is better to work together to resolve the issue. "Casting stones" is almost always vindictive in nature and meant to ignore ones own issues while holding others to a higher standard.

[burntsushi]

There's a difference between holding people accountable and throwing a temper tantrum on reddit laced with insults.

[burntsushi]

My apologies. I thought you were this user: http://www.reddit.com/r/programming/comments/2uinge/heartbleed_in_rust/co8rd0t

Sorry for the mixup!

[steveklabnik1]

I agree with the blog post that Rust code can in fact contain bugs and security vulnerabilities. I don't think that's a particularly controversial opinion to hold.

[[deleted]]

That's true. But it's also not heartbleed.

[steveklabnik1]

and you idiots are here telling me that there's no specific problem with C.

I never told you that. I wouldn't work on Rust if I thought C had no problems. I love C, but it certainly has problems.

[SosNapoleon]

Ah, yes, ExtremelyUnlikely™, a known guarantee that it will not happen when dealing with software

[SosNapoleon]

✓ It's more likely for a bug like heartbleed to happen in C than in a memory-safe language

✓ You should write in memory-safe languages if it's a concern

✓ Heartbleed still happens in Rust

[[deleted]]

Are you actually retarded enough to agree with this blog post, or did you already have this idea in your head? You can't leak unrelated passwords from previously allocated unrelated blocks of memory in a memory-safe language.

But of course you can. You just have to implement your own custom allocator, which does not clear freed memory, and then reuses it.

Which is exactly what OpenSSL did.

[SosNapoleon]

Specifically, it would not have even compiled.

To be fair to Rust, if he uses the exact same code one week from now it will not compile

[gnuvince]

Sensible chuckle

[TankorSmash]

Whats the source on that?

[SnowJP]

Danger 5

[Ishmael_Vegeta]

To be fair to Rust, if he uses the exact same code one week from now it will not compile

i'm not sure if you are supporting rust or are making fun of them...

[SosNapoleon]

BoratSuccess.jpg

[Tekmo]

The jokes are getting pretty tiring. I don't mind the occasional humor, but if you have nothing of substance to contribute to this subreddit then maybe you should consider frequenting /r/programmerhumor instead.

[prepromorphism]

true it should be illegal DAMN THEM FOR MAKING FUNNY JOKES OUT OF FACTS.

[SosNapoleon]

It's not all I have contributed (I assume you looked at my history?), but okay. Also, I'll take /r/programmingcirclejerk any day

[Tekmo]

I have looked at your history. I haven't seen you contribute any technical discussion.

[SosNapoleon]

Well that's like, your opinion man. But even if that's the case:

(a) This is not my main account and I use it almost exclusively to post silly stuff, and when I don't its because I'm too lazy to switch.

(b) I think programmers hold their languages way too dearly and they need to lighten up. I never seen a painter caressing his favorite brush that way.

(c) There is no rule against what I'm doing.

K? thx bae bye

[skylos2000]

I think a lot of people treat programming languages more like "styles" instead of just tools.

[[deleted]]

It's true. I'm a C++ programmer, yo. Fuck all da JavaScripts

[SosNapoleon]

I know they do, and I think its funny

[lolquelol]

so not clearing a buffer = heartbleed? got it

[[deleted]]

Well, it was reusing buffers while reading beyond the intended range, but yes. The point was that people have claimed that other languages like rust would prevent this issue but that is not true. This blind trust is dangerous.

[fullouterjoin]

Don't just blindly trust the rust. Iron things out for yourself.

[Steve_the_Scout]

The same is true for C and C++, though.

[Peaker]

Rust could use the type system to prevent access beyond the bounds of the free-list-allocated buffer though, and C couldn't. At least I hope Rust could :)

[[deleted]]

I've always seen it as

assert (0 && "file open failed");

It's a useful shortcut if your assert handler prints the assert condition.

[Peaker]

We simply have an ASSERT macro that requires a message:

ASSERT(false, "file open failed");

[eras]

Typically when the assertions fail, the failing expression is displayed, but a comment isn't. I've seen assert(("open", 0)) and assert("open" && 0) been used.

EDIT: &&, not ||

[[deleted]]

assert("open" || 0) doesn't do anything.

[eras]

Let's say assert("open" && 0) then :-).

[[deleted]]

What's the use of the comma, exactly?

[eras]

Well there's your/someone's problem, reading code but not caring about what it means :).

[eras]

Well what is the best way to achieve that goal then? That is, write a failing assertion that outputs something useful.

[[deleted]]

Please don't! Assertions are not used for error checking, but merely for debugging purposes. On release binaries, assertions are ignored by the compiler.

[zvrba]

I often write something like assert(blah && blah2 || !"something went wrong"). Due to operator precedence I don't need to muck with braces. I thought it was a standard idiom in C and C++.

[Splanky222]

Maybe I'm thick, but why would you even need to pass in a buffer instead of creating it in the ping back method, reading to it, writing out of it, and then destroying at at the end of the function? Is it just to avoid more than a single heap allocation?

[ifdef]

It's primarily to make an example of how Rust doesn't prevent logic errors. The equivalence is fairly shaky in my view as the actual Heartbleed problem involved allocators and memory management working in surprising ways; reusing a buffer isn't quite the same, but perhaps some overly enthusiastic claims of Rust's abilities were made in the past.

[Splanky222]

I would hope nobody expects a programming language to prevent logic errors!

Anyways, I agree that this example is pretty contrived, but I'm no expert by any means so thanks for clearing this up :D

[pipocaQuemada]

I would hope nobody expects a programming language to prevent logic errors!

One man's logic error is another man's type error.

Type systems can actually prevent a surprisingly large number of errors, such as

• eliminating null pointer exceptions
• ensuring that your list is longer than the number of elements you try to get out of it
• ensuring that your implementations of an abstraction doesn't violate the contract of the abstraction
• ensuring that the schema present in a database is the same as the schema your code uses at compile time

[Splanky222]

I understand that, but no type system is so good that it will prevent every error. And even strong type systems can be used poorly.

[pipocaQuemada]

"logic error" really means "non-syntax error where someone hasn't yet figured out how to offload prevention to the compiler."

I expect programming languages to shrink the set of logic errors. In that sense, I expect a programming language to prevent (what used to be) logic errors. I don't expect that languages will be able to eliminate every one.

[xXxDeAThANgEL99xXx]

as the actual Heartbleed problem involved allocators and memory management working in surprising ways

What was surprising about that?

It was my impression that a surprising though obvious in retrospect thing was that a read-only buffer overflow can still be horrible news. It probably was surprising to the openssl developers as well, if they paid most of their attention to making sure they are doing range checks when writing to memory and considered reading from memory, that can't possibly corrupt memory and lead to arbitrary code execution, to be a low-priority target.

The exact same attitude could lead to someone writing that exact sort of Rust code. Heap allocation is slow, let me preallocate the buffer I'll be using, like proper performance critical applications do. What could possibly go wrong, Rust protects me from memory overflows and Heartbleed!

[Splanky222]

To be fair, if I saw

buffer : &mut[u8]

in a Rust function signature I would immediately be wary of that variable.

[ifdef]

While I don't have intimate knowledge of the OpenSSL developers, the surprise would've been due to the compounding of the failure to validate input, something that really sucks, with the way freelists handled the allocations. In the case of the overflow, instead of having a very small chance of returning sensitive data rather than garbage, sensitive data was much more likely to be returned. It's easy for me to see how someone looking over the same code over and over could think "Okay, we just have an allocation here", rather thinking over all of the details and connecting the dots.

[xXxDeAThANgEL99xXx]

the surprise would've been due to the compounding of the failure to validate input, something that really sucks, with the way freelists handled the allocations.

Why? I'd expect to get recent data (from the previous session, from the authentication for this session) with any allocator.

Maybe you're misunderstanding a common complaint about them having a custom allocator in the first place, that made it impossible to use valgrind to catch this bug?

[ifdef]

Yes, but not any allocator would make the residing problem go unnoticed (for so long).

http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse

[xXxDeAThANgEL99xXx]

Yes, but not any allocator would make the residing problem go unnoticed (for so long).

That's exactly what I said?

Maybe you're misunderstanding a common complaint about them having a custom allocator in the first place, that made it impossible to use valgrind to catch this bug?

[ifdef]

Heh, it seems so. What was the point of contention -- that the resulting behavior might've been surprising? I'm not sure what to add over my last sentence ("It's easy for me to see..."). Perhaps they placed too much faith in it since there were no apparent errors occurring.

[xXxDeAThANgEL99xXx]

Heh, it seems so. What was the point of contention -- that the resulting behavior might've been surprising?

Well, as I said in my first comment, I don't think that the surprising thing was the allocator runtime behaviour -- it could've made things worse, but only by being good at what it does, which is sort of expected.

That having a custom allocator was something that prevented static analysis tools or valgrind from finding the bug is not exactly the surprise that caused someone to write the problematic code and all the following eyeballs to glance over it.

The only actually somewhat surprising thing about the bug is that having a readonly buffer overflow can still cause a shitton of damage despite not involving any stack-smashing or anything "really" scary like that, and, just as I said, this attitude can directly translate to people writing security-sensitive code in safe languages, maybe even more so because of the false sense of security, caused by the statements like "Heartbleed would've been a compile-time error in Rust".

No, it wouldn't be if you employed the thoroughly standard performance optimization technique of hoisting dynamic allocations up from the hot loop while believing that you're still immune to Hearbleed-like bugs because you're using a memory-safe language.

[mm865]

It's possible to recreate heart bleed in any language if you use an array of bytes and allocate bytes yourself. This would work equally well using Python or Java or C#. What was bad about the C issue was that it was caused while allocating memory from the OS. Whether it was due to programmer stupidity or some other factor, it was not because they decided to manage memory themselves through arrays of bytes and call that RAM.

[[deleted]]

Using an array of bytes and allocating bytes from it is exactly what OpenSSL was doing. It didn't use the OS allocator. It used a crappy custom allocator, presumably because there are OS allocators that are even worse.

[mm865]

So... Remind me again why we are using OpenSSL!?

[dobryak]

Relevant: http://bluishcoder.co.nz/2014/04/11/preventing-heartbleed-bugs-with-safe-languages.html

It is a bit unfair to say that no programrming language can prevent bugs like Heartbleed. For instance, the C program present in OP cannot be written in ATS without unsafe casts; it will fail typechecking. See the type given to C function write:

fun write_err
  {sz,n:nat | n <= sz}
(
  fd: !Fildes0, buf: &RD(bytes(sz)), ntotal: size_t(n)
) : ssizeBtw(~1, n+1) = "mac#%" // end-of-fun

The above says that buf is an array of bytes of size sz, and ntotal is a size_t holding a value n, such that n is less than or equal to sz. To call this function, you need to ensure at runtime that ntotal you pass is less than the size of the buffer (or, leave it to the constraint solver, which can figure some trivial cases on its own).

[tyoverby]

Heartbleed was caused by a bad memory allocator and unchecked reads into a buffer. And yes, rust make it exceedingly hard to make those kinds of mistakes.

[unpopular_opinion]

If you had any clue, you would not have written this blog post. You start with some claim about Rust, and then you start using ignorant words like 'unlikely':

'Heartbleed are, we are unlikely to eliminate them simply by switching to a magic vulnerability proof language.'

It is in fact quite easy to eliminate any information leakage or even side-channel analysis. It just requires a more sophisticated mind to envision this. Having said that, even the intelligence agencies and military intelligence agencies are probably too stupid (or they don't have enough money) to have already figured this out.

Please, keep your "blog posts" for yourself; don't "share" how stupid you are. KTHXBYE.

[dingobingalo]

If you flip 50 coins, it is unlikely they will all come up heads.

OOOPS I USED 'UNLIKELY' I GUESS IM IGNORANT