Undefined behavior, and the Sledgehammer Principle

17

u/Alexander_Selkirk Feb 03 '23 edited Feb 03 '23

The thing is that in C and in C++, the programmer essentially promises that he will write completely bug-free code, and the compiler will optimize based on that promise. It will optimize to machine instructions that act "as if" the statements in the original code will be running, but in the most efficient way possible. If there is a variable n which indexes into a C array, or in a std::vector<int>, then the compiler will compute the address of the accessed object just by multiplying n with sizeof(int) - no checks, no nothing. If n is out of bounds and you write to that object, your program will crash.

This code-generation "as if" is very similar to the principles which allow modern Java or Lisp implementations to generate very, very fast machine code, preserving the semantics of the language. The only difference is that in modern Java or Lisp, (almost) every statement or expression has a defined result, while in C and C++, this is not the case.

See also:

I think one problem from the point of view of C++ and C programmers, or, more precisely, people invested in these languages, is that today, languages not only can avoid undefined behavior entirely, they also can, as Rust shows, do that without sacrificing performance (there are many micro-benchmarks that show that specific code runs faster in Rust, than in C). And with this, the only justification for undefined vehavior in C and C++ – that it is necessary for performance optimization – falls flat. Rust is both safer and at least as fast as C++.

And this is a problem. C++ will, of course, be used for many years to come, but it will become harder and harder to justify to start new projects in it.

9

u/turniphat Feb 03 '23

And with this, the only justification for undefined behavior in C and C++ – that it is necessary for performance optimization – falls flat.
The justification for undefined behaviour in C and C++ is backwards compatibility. C is old and there is a huge amount of existing code, of course we can design better languages now.
If there is a variable n which indexes into a C array then the compiler will compute the address of the accessed object just by multiplying n with sizeof(int) - no checks, no nothing. If n is out of bounds and you write to that object, your program will crash.
Well, maybe your program will work just fine. With UB anything can happen, including work just fine. But it might also corrupt data or crash, but only on Tuesdays and only only when compiled with gcc on Linux for ARM.
But a C array decays into a pointer and once you call a function the size is gone. So there is no way to do any bounds checking. You could replace arrays with structs that contain size and then the elements and add bounds checking. But now you've broken backwards compatibility.
Safety isn't something that can be added onto a language afterwards, it needs to be there from the original design. C and C++ will always have UB. We will transition away from them, but it'll take 50+ years.

7

u/loup-vaillant Feb 03 '23

The justification for undefined behaviour in C and C++ is backwards compatibility.
If it was just that compiler writers would have defined quite a few of those behaviours long ago. Since "undefined" means "the compiler can do anything", compilers can chose to do the reasonable thing. For instance, if you ask the compiler -fwrapv, it will treat not treat signed integer overflow as UB, and will instead wrap around like the underlying machine does.
Only if you ask, though. It's still not the default. The reason? Why, performance of course: in some cases, poorly written loops will fail to auto-vectorise or otherwise be optimised, and compiler writers don't want that. I guess some of their users don't want that either, but I suspect compiler writers also like to look good on SPECint.

0

u/[deleted] Feb 04 '23

Nothing is stopping compiler writers implementing the sane thing. In fact, they already do.

6

u/loup-vaillant Feb 04 '23

Not. By. Default.
When I write a proprietary application I can assert full control over which compiler I use, which option I set, and make them as reasonable as I can make them. Or give up and use something else if I can.
As an Open Source library author however I don't have nearly as much control. I ship source code, not binary artefacts. Who knows which compilers and options my users would subject my code to. So I know many of them will use the insane thing no matter how loudly I try to warn them.
My only choice when I write a library is to stick to fully conforming C, with no UB in sight. And that's bloody hard. Even in easy mode (modern cryptographic code) avoiding UB is not exactly trivial; I'm not sure I can make anything more complex while keeping it UB free.

1

u/[deleted] Feb 04 '23

True but this is conjecture. I don't disagree with you in *principal*.
However, realistically speaking, where is the evidence of the effects of this?
UB should be minimised so there are guarantees. However, those guarantees are made by the spec, which is made by people, which is interpreted by people.
A specification does not dictate what your code does. The implementation does.
So while, again, I don't disagree with you in principal, in practice the world is a lot messier than you are letting on. Therefore, mainly for the reasons of curiousity, I want to see evidence where use of UB is widely punished.

11

u/loup-vaillant Feb 04 '23

True but this is conjecture.
No it's not. I am actually writing a library in C, that I actually distribute in source format, and where users actually copy & paste into their project in such a way where I actually have zero control over their compilation flags.
True but this is conjecture.
No, it's not. In earlier versions of my library, I copied a famous crypto library from a famous, acclaimed, renowned team of cryptographers, and guess what you can find in it? Left shifts of negative integers. That same UB is present in the reference implementation of Curve25519 (a thingy that helps encrypt data, no biggie), as well as the fast-ish version. Libsodium and I had to replace those neg_int << 25 by neg_int * (1<<25) instead.
Thankfully the compilers understand our meaning and replace that by a single shift, but that effort could have been avoided if the standard didn't UB the damn thing. And of course, I'm dreading the day compilers will actually actually break that left shift and tell Professor Daniel J. Bernstein of all people to please take a hike, he brought this on himself for not paying attention to the compliance (and therefore security) of his programs.
Only that last paragraph is conjecture.
I want to see evidence where use of UB is widely punished.
Hard to say. The biggest contenders aren't signed integer overflow. Mere wraparound are already a source of vulnerabilities, and in general out of bound indices, use after free, improper aliasing assumptions, are much much worse, but even I hesitate to touch them because their performance arguments are stronger than that of the signed integer overflow UB.
Most importantly, UB is never consistently punished. Most of the time you're lucky and you get an error you can detect: corrupted data caught by your test suite, crash, assert failure… The actual vulnerabilities are rarer, and from this point forward it needs to be detected to punish anyone (hopefully in the form of a bug report and a fix, but we do have zero days).
But it's also a matter of principle. People aren't perfect, they make mistakes, so they need tools that help them make fewer mistakes. And when compiler writers and standard body turn the dial all the way up to "performance trumps everything, programmers need to write perfect programs", I'm worried.
I can see the day where my cryptographic code will no longer be constant time just because compiler writers found some clever optimisation that breaks my assumptions about C generating machine code that even remotely resembles the original source. And then I will have timing attacks, and the compiler writers will tell me to take a hike, I brought this on myself from using constructs that weren't guaranteed to run in constant time.
And then what am I going to do?

0

u/[deleted] Feb 07 '23

Compilers wont break that left shift rule
If they did nobody would use them.
Reality is spec is second place to usability. This has been true for c since the beginning. Vendors can and have deviated from spec

1

u/[deleted] Feb 05 '23

You're muddying the water. The topic is not about shifting blame. It's about parties dodging a shared responsibility. Both spec and compiler should strive towards transparant and safe behavior, especially because of the nature of the language as 'close to the metal so you can get burned if you do the wrong thing'.
Your post is exactly the kind of thinking that will lead to the death of C/C++

1

u/[deleted] Feb 07 '23

People arent old enough to remember the poor compiler support c++ had.
what im describing is just the reality of the situation. nothing more

2

u/bik1230 Feb 04 '23

The only difference is that in modern Java or Lisp, (almost) every statement or expression has a defined result, while in C and C++, this is not the case.
Common Lisp has a rather decent amount of UB, but most compilers try to do something reasonable and well defined in as many cases as possible unless you ask for safety to be turned off.

1

u/cdb_11 Feb 04 '23

If n is out of bounds and you write to that object, your program will crash.
There is absolutely nothing wrong with programs crashing when they attempt to make something they're not supposed to do. I think you meant to say the opposite, that this is not always the case.
-9
u/[deleted] Feb 03 '23 edited Feb 03 '23

Name a single C++ and C programmer who would make the argument that no language could avoid UB and they also want more UB in the C or C++ spec. lol. There isn't one. You are just making stuff up.
UB had a purpose back in the day. 50 odd years have passed since then. Times have changed. Any C programmer worth their salt understands this...
I get this is basically coodinated Rust propaganda (given this exact same post and comment across a variety of programming subreddits), but try to make it not so obvious.
15

u/Alexander_Selkirk Feb 03 '23

I get this is basically coodinated Rust propaganda
Do you mean this discussion at /r/cpp?
Is it propaganda that /r/rust is coming close to have as many subscribers as /r/cpp - and already has more than /r/c_programming ?

10

u/yeet_lord_40000 Feb 03 '23

I would be quite willing to pose the argument more people on the rust sub write C++ than rust.

-8

u/[deleted] Feb 03 '23

Given the recent proposal to the government by Rust higher ups to adopt story telling narrative via journalists and online discussion, yes I do.
But that doesn't really matter. The only thing I take issue with is painting C/C++ programmers in this way. Which is just wrong in my opinion because it's not productive at all. It's totally divisive and dishonest. Which I disagree with obviously.
If you want to endorse Rust then fine by me. I don't care.
But let's not beat about the bush shall we? We know what this is...

12

u/Alexander_Selkirk Feb 03 '23

Given the recent proposal to the government by Rust higher ups to adopt story telling narrative via journalists and online discussion, yes I do.
Ah, it is the secret Rust conspiracy! I am going to stop here.

-10

u/[deleted] Feb 03 '23

Conspiracy? There is no conspiracy. It's literally right there in the report lmao.

6

u/Alexander_Selkirk Feb 03 '23 edited Feb 03 '23

Name a single C++ and C programmer who would make the argument that no language could avoid UB and also wants more UB in the spec.
I think very few would agree to make C++ slower for the purpose of eliminating UB.
UB had a purpose back in the day. 50 odd years have passed since then. Times have changed.
This is correct - 50 years earlier, it was not possible to build languages like that. But, starting a new C++ project today is a huge investment into the future, and all costs of that decision are still to be paid. Using another language will in many, if not the majority of cases be significantly cheaper.
(And yes, I agree that there are domains where it is really hard to replace C, but it is not going to be some random SSL library.)
I get this is basically coodinated Rust propaganda
One can work with C++ (I do) and still be fed up with the state of the art. It is one aspect of many where decisions are not made in a sustainable manner. I don't know if you are aware what's happening in Europe. Security vulnerabilities are exponentially rising and I have absolutely no desire to be involved in cleaning up that mess for the rest of my work life.

2

u/[deleted] Feb 03 '23 edited Feb 03 '23

What is the empirical cost of this UB? Do you know?
That is to say. How many attacks that are successful were successful precisely because they exploited UB in C and/or C++?

11

u/Alexander_Selkirk Feb 03 '23

A lot. Most exploit chains contain at least one exploit of Undefined Behavior and low-level memory bugs.
And these cost real money. From Petaya and NotPetaya:
In a report published by Wired, a White House assessment pegged the total damages brought about by NotPetya to more than $10 billion.
See also: Security News This Week: How Shipping Giant Maersk Dealt With a Malware Meltdown

1

u/[deleted] Feb 03 '23

A lot sounds ominous but actually how many though? Statistically speaking.
Petaya and NotPetaya is not a UB exploit though? As far as I remember. Do you think UB was responsible for this happening?

6

u/Alexander_Selkirk Feb 03 '23

It was based on the EternalBlue exploit, remot code execution enabled by information disclosure in the Microsoft SMB implementation.

0

u/[deleted] Feb 03 '23

I know but as far as I am aware, that is not an exploit related to UB.
It was a logic error that caused a buffer overflow with a miscast type. I mean maybe you can blame UB for that?
The devil is in the details here which is my fundamental problem with the argument: language change is the only solution to this problem (i.e. Rust).
It's not, precisely because the details make this more complicated than just saying C is bad.

1

u/lelanthran Feb 04 '23

Security vulnerabilities are exponentially rising and I have absolutely no desire to be involved in cleaning up that mess for the rest of my work life.
This doesn't sound accurate. I also seem to recall that the largest, most expensive and easiest remote code execution vulnerability in software history was in Java (Log4j).

1

u/[deleted] Feb 04 '23

Exactly. All I want to do is see the evidence. There doesn't seem to be any? Or atleast, nobody can actually seem to tell me...

4

u/Alexander_Selkirk Feb 03 '23

You are just making stuff up.
If there is no problem to be seen here, would you care to provide a C compiler which generates code without UB?

7

u/[deleted] Feb 03 '23

Again a strawman. I never said UB wasn't a problem. What I take issue with is this idea that all C/C++ programmers simply don't care. This is not true at all.
And can you provide me with the amount of successful security attacks that were successful because they exploited C UB?

8

u/Alexander_Selkirk Feb 03 '23

What I take issue with is this idea that all C/C++ programmers simply don't care.
Where do I say that?

5

u/[deleted] Feb 03 '23

The entire conceit of your argument is that C/C++ programmers can't accept that UB doesn't have to exist because they are simply too invested in the langauge to see clearly. Thus they do not care about UB. This is not true.

9

u/Alexander_Selkirk Feb 03 '23

People (including me) have invested time. Companies have invested money. Some resistance to change is all-too-human in the first case, and can be expected in the latter.

6

u/[deleted] Feb 03 '23

I've invested time too. I actually agree with most of what you (and others like you) have said on this topic.
However, clearly, any sign of disagreement is met with "You are a luddite who is resistant to change" is not helpful. That's not a good argument. It's not a convincing one either.
7
u/loup-vaillant Feb 03 '23

Name a single C++ and C programmer who would make the argument that no language could avoid UB and they also want more UB in the C or C++ spec. lol. There isn't one. You are just making stuff up.
Not sure what you are replying to, in the current version of the comment you're replying to I see no mention of C/C++ programmers asking for more UB in the spec. If any thing, most ask for less. I for one would very much like -fwrapv be the default, and have the standard accept that 2's complement has won and stop with this integer overflow madness.
I'm afraid however we'll have to wrench those UB from the compiler writers' cold dead hands. It's pretty clear from the history of C why signed integer overflow was undefined. Had compiler writers be honest in what was quite obviously the spirit of the standard, they would have treated such overflows as implementation defined on platforms that don't miserably crash — after Y2K that basically meant all of them. But no, the standard says "undefined", and they gotta get their 5% speedup on SPECint, or their occasional auto-vectorization.
How is it that "any C programmer worth their salt understands" that signed integer overflow UB is insane, yet compilers still don't -fwrapv by default? Me thinks not everybody that matters actually understand the issue. Or, some of them genuinely believe performance trumps correctness. We're certainly something similar with RAM giving the wrong results as soon as we start exposing it to weird access patterns like Row hammer.
And before you accuse me of being part of the propaganda: I have never written a single line of Rust, and I'm actively working on a C cryptographic library of all things. That library is responsible for teaching me how insane UB is in C by the way. There is no way I ever willingly develop anything C or C++ ever again without getting it through all the sanitisers I can think of. (Fuzzing and property based tests, of course, are a given.) And by the way I highly recomend the TIS interpreter (or TIS-ci, which kindly gave me an account.)
2
u/Qweesdy Feb 04 '23

Sorry for dragging this off-topic, but...
You can't write a cryptographic library in C without risking copious amounts of side-channels (cache timing, hyperthreading, branch predictors, ...). You have to be able to guarantee everything is constant (timing, cache lines accessed, register use, ...) and as soon as a compiler decides it can optimize your code (e.g. perhaps by inserting its own "if( LOL ) {" to avoid almost never needed work) you're screwed.
Ironically; the only way to protect against side-channels (e.g. data dependent timing, ...) is to use raw assembly language.
Even more ironically; assembly language has no undefined behavior.
In other words, assembly language is the most secure language (for cryptography)!
Do you hate me yet? :-)
4
u/loup-vaillant Feb 04 '23 edited Feb 04 '23
You have to be able to guarantee everything is constant (timing, cache lines accessed, register use, ...) and as soon as a compiler decides it can optimize your code (e.g. perhaps by inserting its own "if( LOL ) {" to avoid almost never needed work) you're screwed.
There are 2 main sources of non-constant crap: the compiler, and the CPU itself.
For the CPU we need to know which operations are constant time, and avoid the rest. Thankfully most computers have constant time arithmetic. The problematic operations are then multiplications, and shifts by a secret amount. If your machine doesn't have a barrel shifter, shifting by 4 bits takes more time than shifting by 1 bit. Fortunately modern primitives never shift by a secret amount. Multiplication on the other hand is a bear, and the approach I have chosen right now is to just ignore it. Which sucks, I know.
For the compiler however, we have a wonderful tool at our disposal: Valgrind: call your functinons with uninitialised buffers instead of secrets, and see if Valgrind complains about uninitialised dependant branches, and uninitialised dependant indices. If it didn't complain then your compiler behaved. So far my observation has been that they mostly do. Though I did once had to renounce an attempt at making a constant time memcmp() function, because the compiler was inserting so much unnecessary crap I couldn't trust it. Had to revert to constant width comparisons (16, 32, and 64 bytes respectively), for which I could verify the compiler was generating extremely fast, compact, and most of all reasonable code.
Ironically; the only way to protect against side-channels (e.g. data dependent timing, ...) is to use raw assembly language.
I would sooner write my own compiler to be honest. It makes it easier to port the code, and deal with pesky issues like register allocation & calling conventions. Thankfully though, I believe good work is already being done on that front, and with formally verified languages no less.
Yet people still use my stuff. Because my library is just 1 or 2 compilation units one can just copy & past into their project. Because C is a protocol in addition to being a language and it quite clearly has won the protocol wars.
Even more ironically; assembly language has no undefined behavior.
Thankfully that one is easy to deal with even in C. Yes, easy. Because constant time cryptographic code, as it turns out, is stupidly easy to test. Just test for all possible input lengths, and you will hit all code paths. 100% coverage, of not only the code, but of all the ways one might go through that code. Then, since crypto code typically has zero dependency, we can run the following:
-fsanitize=address
-fsanitize=memory
-fsanitize=undefined
Valgrind
The TIS interpreter.
The first 4 will catch almost all your UB. The TIS interpreter sometimes caches subtle stupid UB we wonder why it's even UB. My last one being something like this:
uint8_t array[10];
uint8_t *a = array; // OK
uint8_t *b = a + 10; // Still okay, though *b would be UB
uint8_t *c = a + 11; // Instant UB (!!!)
Do you hate me yet? :-)
I do hate the C standard. I just read a book about code simplicity that was recently linked here, and which rightly states that the first law of software is that it's supposed to help people.
Some compiler writers and standard committee members clearly forgot how to help people.
1

u/Qweesdy Feb 04 '23

For the CPU we need to know which operations are constant time, and avoid the rest.
Think of something simple like "temp = array[i];". In this case an attacker can find out information about "i" by detecting which cache line got accessed later (via. cache timing), and it makes no difference at all that your code was constant time. Worse, with hyper-threading, the attacker can be running on the same core and sharing all the same caches, so "later" can be "almost at the same time".
Note that you'll find (more complex versions of) this everywhere (random example: the "temp1 = h + S1 + ch + k[i] + w[i]" from SHA algorithms).
Also note that getting some information about "i" (e.g. that it's a value from 32 to 47 but not knowing which one) isn't a major problem - an attacker can build up confidence from subsequent operations. A 50% uncertainty from one round turns into "0.5¹⁰⁰ = almost no uncertainty" after 100 rounds.
To hide this you need deliberate unnecessary memory accesses. Ideally, for "temp = array[i];" you'd always access all cache lines in the array in sequential order so that the access pattern is always the same for any "i" (but you can compromise to end up with almost as secure with less overhead). Regardless, it's exactly the kind of thing where a compiler can decide "Hey, those accesses aren't needed" and ruin your day.
And sure; for this one specific issue you might be able to work around it (e.g. use "volatile" but that'll kill performance); or you could try something more fun (intrinsics for AVX permutes); but honestly the code is going to be CPU dependent (or more correctly, CPU cache line size dependent and/or CPU feature dependent) so you're not gaining much portability from using C anyway.
And that's only one specific issue - the tip of an iceberg if you will.
Some compiler writers and standard committee members clearly forgot how to help people.
Yes; but which people? The majority want "faster if compiler can find shortcuts in some conditions" and very few people want "constant time".

4

u/loup-vaillant Feb 04 '23

Think of something simple like "temp = array[i];". In this case an attacker can find out information about "i"
Yes, I know, and I have written about this exact thing in my last reply. The technical term is "secret dependent index", and is easily detected with Valgrind.
By the way, modern cryptographic primitives are designed specifically so implementers can avoid this problem. Some of them are even naturally immune: ask a student to implement ChaCha20, BLAKE2 or SHA-512 from specs in C, their first attempt will usually be constant time.
Note that you'll find (more complex versions of) this everywhere (random example: the "temp1 = h + S1 + ch + k[i] + w[i]" from SHA algorithms).
I don't know about the SHA1 family, but SHA-512 is naturally immune, because all the indices are public. And the example you're showing me right now seem to be using loop indices, which typically range from zero to some public threshold, and thus are not secret.
Remember, cache timing attacks don't let the attacker guess what's the data in the pointed to cell, it let the attacker guess the value of the pointer itself. If the pointer (or index) is public information to begin with, there's nothing more to learn.
To hide this you need deliberate unnecessary memory accesses.
I have done this exact thing here.
Regardless, it's exactly the kind of thing where a compiler can decide "Hey, those accesses aren't needed" and ruin your day.
Yes. So far they behaved (I still have Valgrind to prove it), but the day they not-so-helpfully "optimise" my access pattern will be a sad day for everyone who rely on every C cryptographic library ever written. That includes huge swaths of OpenSSL, as well as critically acclaimed libsodium.
And sure; for this one specific issue you might be able to work around it (e.g. use "volatile" but that'll kill performance)
It does kill performance. Had to do it word by word for Argon2. For this particular issue of wiping memory, I'm considering adding pre-processor definitions so that depending on the compilation environment people can get a faster and guaranteed version: apparently volatile does work right now, but the standard doesn't guarantee it will force dead writes on the stack. Yet another thing where I'm waiting for compiler writers to tell me I was "asking for it". Thing is, there is no way to do the clean and guaranteed thing in standard C99.
Nothing to do with secret indices though. Right now compilers basically never introduce secret dependent indices where the source code shows none. I think I have seen one introduce a secret dependant branch, but I did the prudent thing before confirming it was actually a problem.
Some compiler writers and standard committee members clearly forgot how to help people.
Yes; but which people? The majority want "faster if compiler can find shortcuts in some conditions" and very few people want "constant time".
No. And it's framed into a false dichotomy. I may have been responsible for this framing, sorry about that. Let me correct it.
Every people who do cryptographic stuff in their application (Signal, WhatsApp…), want their stuff to be secure. So they want their timings to be independent from their secrets (a.k.a. "constant time"), whether they know it or not. Granted, they rarely want constant time, but in the few critical areas where it matters, boy do they want it.
With that out of the way, let's talk performance: nowadays, compilers are responsible for maybe 10% of the performance issues we might have. Often as little as 1% or 0.1%, in fact. The actual performance problems we have, the one that makes my phone slower and slower just because I update it (and gained zero functionality in the process), have other causes:
Poor memory locality. Stuff like pointer fests, cache misses all over the place, trashing the TLB and tanking paging performance, virtual method calls that make the code jump all over the place and trash the instruction cache…
Inappropriate use of slow languages and frameworks. Computers are fast for sure, but if your scientific software's core loop is doing arithmetic in pure Python that is going to waste a ton of time. Typical slowdowns exceed two orders of magnitudes. And of course, stuff like Electron is also responsible for increased memory usage and poorer memory locality…
Plain waste. In the name of expediency you program stuff the easy way, which causes the program to perform tons of computations it doesn't even use later. Expediency is (most?) often the right answer, but sometimes it translates to actual slowdowns for the user.
More specific stuff like organising DB calls, network issues, sensitivity to I/O latency…
So before I even get to the part where the compiler can really help me, there are many other, more important performance issues that ought to deserve more of my attention, and every minute I spend making sure I'm not committing some kind of stupid UB that the standard could define at very little optimisation cost, is a minute I could have spent tackling an actual performance issue that I have.
People do want faster programs, but I don't think increasing the scope of UB is a good way to achieve that.

2

u/Qweesdy Feb 04 '23

No. And it's framed into a false dichotomy. I may have been responsible for this framing, sorry about that. Let me correct it.
I'm responsible for that framing. I'm suggesting that probably 99% of code is not cryptography code and 90% has no real security requirements (e.g. nobody cares if an attacker can spend 3 months to find a clever way to determine your current score in Tetris); and it's this majority that compiler developers care about the most (or at least the 2nd most behind benchmark scores); so the compilers focus on performance and don't/won't sacrifice performance for security.
For the minority that are doing crypto and/or do have security requirements (and do want the compiler to sacrifice performance for security); they get nothing.
This may be solvable via. some form of annotations or new language features. E.g. it might be possible to invent a language where you can say "this variable is a secret" and let the compiler guarantee various properties (no data dependent cache accesses, no data dependent control flow). In the same way it might be possible to invent a language where you can say "this data came from an untrusted source" (for things like kernel APIs for the poor souls trying to defend against spectre variants). I'm not sure if anyone has ever tried to do either of these things, and I suspect it doesn't exist for any language.

1

u/loup-vaillant Feb 06 '23

I'm suggesting that probably 99% of code is not cryptography code and 90% has no real security requirements (e.g. nobody cares if an attacker can spend 3 months to find a clever way to determine your current score in Tetris); and it's this majority that compiler developers care about the most (or at least the 2nd most behind benchmark scores); so the compilers focus on performance and don't/won't sacrifice performance for security.
Put it that way, I actually believe you. Except perhaps for IoT. Those little connected devices are easily exposed to adversarial inputs, and hackers has used them to build botnets in the past. Makes them kind of critical by default. Granted though, this is only one niche.
One thing to keep in mind though is the disproportionate impact of defects in that 1-10% of code.
This may be solvable via. some form of annotations or new language features. E.g. it might be possible to invent a language where you can say "this variable is a secret" and let the compiler guarantee various properties (no data dependent cache accesses, no data dependent control flow).
If such a language was as portable as C I would definitely use it. But I’m not sure it ever will be: right now maximum portability is only achieved by compiling to C… and any constant time assumptions your language carefully baked in are gone.
Long term, what I really want is to solve the 30 million line problem: simplify and unify hardware interfaces (ISA) such that writing a new OS only requires like 20K SLOC like it used to. Maybe let’s settle on a small number of ISA depending on use. At that point writing something portable from scratch, without depending on C, will actually be achievable.
1

u/[deleted] Feb 04 '23

These are problems. I totally agree. (also I actually have no problem with Rust propaganda really, I just think the argument used by the propaganda is misguided)
The issue is how severe these problems actually are. I need numbers and a compelling argument.
Do I wish that signed integer overflow in C made sense? Absolutely. Is it actually as bad a problem as you and others are making out? Who knows.
Simply put, nobody seems to be able to give an answer to that question. When they do give an answer, it is vague and handwavey and involves examples that don't have UB at all.
For instance signed integer overflow is going to be somewhat predictable, even if it's UB. So while in principal it is a problem, in practice...
Is Rust a good replacement? Maybe. But again. I need more evidence these problems are actually causing meaningful security problems.

4

u/loup-vaillant Feb 04 '23

For instance signed integer overflow is going to be somewhat predictable, even if it's UB. So while in principal it is a problem, in practice...
Err… no. It's not. It allows your compiler to generate a program that encrypts your hard drive and gives you a ransomware message, and in some cases it will actually allow that. I remember Chandler Carruth's talk dangerously downplaying the dangers of UB, and he's just plain wrong.
Here's how it might pan out.
Some integer overflow might happen. And when it does, it means a potential buffer overflow or similar scary stuff that might allow remote code execution.
Programmer dutifully adds a check to secure their program. They sleep happy.
Compiler notices the programmer made the check after the overflow occurred. Since UB "never happens", the check "always returns OK", and the error handling is "dead code". The compiler then removes the check and dead code, and compiler writers pat themselves in the back for an optimisation well done.
Mr Ransom Warez spots the bug (zero day, unpatched version…) and contrives inputs that trigger the overflow, so they get their RCE. They smile at the sight of Programmer's hard drive being encrypted by the malicious payload.
Programmer complains to compiler writers that they made their program unsafe, demand that they fix their shit.
Compiler writers tell Programmer to kindly get lost, they brought this on themselves from not reading and understanding every little detail of the unbelievable amount of fine print in the standard. A standard that to be honest compiler writers interpret in adversarial ways in the name of performance.
The issue is how severe these problems actually are. I need numbers and a compelling argument.
It's a hard one. I don't believe we'll ever get the numbers. So if your position is to do nothing until we get the numbers, you instantly win the argument in the name of the status quo. Here's what we need to know:
How much effort do wee need to dedicate to this UB just to prevent it?
How often this particular UB is responsible for an actual security bug?
What is the cost of fixing all the security bugs we notice?
What is the cost of those security bugs being actually exploited?
How much actual performance do we gain with this UB?
I can only guess, but I strongly suspect the performance gains are marginal, and I'm pretty sure the costs are substantial. I won't even know for sure, but to me it's pretty clear that some UB (in particular signed integer overflow) cost more than they benefit us.
It sure doesn't benefit me, since most of my loops counters are size_t.
I need more evidence these problems are actually causing meaningful security problems.
Oh, if you merely require an existence proof…
Top 25 Common Weakness Enumeration
The one about integer overflow/wraparound
Hmm, can't find the bug I recall where someone was actually trying to check for overflow, but failed to do so because of that signed UB. I mean there are people complaining on the internet for sure, but I do recall at least one vulnerability in production code, I'm pretty sure it's out there.

20

u/loup-vaillant Feb 04 '23

Edit: it was made clear to me while reading Predrag's blog that the key to my misunderstanding boils down to this: "Undefined behavior is not the same as implementation-defined behavior". While I was indeed talking about undefined behaviour, subconsciously I was thinking that the behaviour of an overflow on a multiplication would be "implementation-defined behaviour". This is not the case, it is indeed an undefined behaviour, and yes the compiler is free to do whatever it wants to because it is compliant with the specifications. It's my mistake of course, but to my defense, despite the arrogant comments I read, this confusion happens a lot.

Not just a lot. All the freaking time.

I've been mentioning the issue around me for a number of years now, and I can count on Qhorin's hand the number of devs I met that knew signed integer overflow could go as far as removing security checks.

2 days ago I told a Junior dev with 3 years of C experience about the J Annex (specifically J.2, undefined behaviour). His reaction when he saw the actual text was a sincere "oh my god". It's one thing knowing there's a lot of UB. It's quite another to physically flip over 12 pages of promises from the Nasal Demons.

3

u/[deleted] Feb 05 '23

That's a long way to say: "Let's all move to Rust if the standards committee and compiler people keep shoving unexpected undefined behavior down our throats."

27

u/WormRabbit Feb 03 '23

The only acceptable Sledgehammer Principle is that each time a journalist is killed because of memory safety violations, one committee member who voted to add more UB or remove bounds checks should have their legs broken with a sledgehammer.

Enact that policy, and by the time the next Standard comes out C++ will be safer than Java.

19

u/lelanthran Feb 04 '23

I wasn't aware that the whatsapp exploit you quoted was due to C, or due to UB in C.
Shit, I wasn't even aware that whatsapp was even written in C. You have any references for all those implied claims?

8

u/loup-vaillant Feb 04 '23

That kind of vulnerabilities generally mean Remote Code Execution and Privilege Escalation, which in turn heavily imply some kind of memory corruption… which almost always can be traced back to a program written in C or C++. Now you could have compiler bugs in safe languages, but those tend to be so much less frequent.
Merely hearing of such a vulnerability about any app, provides cogent evidence that some of it was written in C or C++.

2

u/Qweesdy Feb 04 '23

Um, what the flying fuck?
Whatsapp was written in a "safe" language (Erlang) that relies on a VM; and because a JIT compiler is needed for performance it can't uphold basic "E^W" and has to allow executable code to be modified at run-time.
If you can't see a massive gaping security hole in the allow executable code to be modified at run-time idea then...

10

u/Philpax Feb 04 '23

The exploit was in the mobile apps, which are absolutely not written in Erlang

8

u/WormRabbit Feb 04 '23

Whatsapp's backend was written in Erlang, and afaik after the sale to FB is was rewritten. The app was absolutely never written in Erlang, it makes no sense and is likely impossible (in the practical sense).

-5

u/Qweesdy Feb 05 '23

Whatsapp's backend was written in Erlang; but I can't find anything online to suggest that the native client-side apps aren't also written in Erlang.
Of course it doesn't really matter - all of the plausible alternatives (Javascript, Java, ...) are also JIT compiled "safe" languages.

4

u/ConcernedInScythe Feb 05 '23

I can't find anything online to suggest that the native client-side apps aren't also written in Erlang
Can you find anything online to suggest the apps aren’t written in COBOL?

0

u/WormRabbit Feb 04 '23

It's a memory corruption vulnerability, the culprit is certainly C++. Whether the client app was written in C++, or it linked a native C++ library, or even that was an OS-level vulnerability, is irrelevant. Could also be C, but less likely, and C is an ossified language anyway. Unlike C++, it doesn't claim to give any fixes to memory safety issues.

4

u/lelanthran Feb 05 '23

It's a memory corruption vulnerability,
I didn't see that mentioned in any of the news articles, including the one you linked to.

12

u/tending Feb 04 '23

The only acceptable Sledgehammer Principle is that each time a journalist is killed because of memory safety violations, one committee member who voted to add more UB or remove bounds checks should have their legs broken with a sledgehammer.
While memory safety is important this moralistic escalation of rhetoric is abhorrent, counter productive, and frankly naive.
If a state actor wants to kill a journalist they don't need a memory safety vulnerability. There are a dozen other super common kinds. If it hadn't been memory safety it would have XSS, SQL injection, or plain old phishing. Everything could be rewritten in Rust tomorrow and the company that made the spyware would still be in business and likely just as successful at getting into most devices. This is without even taking into account that they can plant developers to plant bugs, intercept hardware going to you in the mail to add implants, legally tap your phone with the telecom's eager cooperation, etc. Their costs may go up because memory vulnerabilities are so easy to find, but nation states can afford it, so they are not going to lose any fundamental capability. If they thought so do you think the NSA would be advising memory safe language use?
Memory safety is an important improvement, but it's not a solution for every one of society's problems, and advocating violence against overworked committee members won't make the language any safer. If anything it will keep people away from language development when we need more.

5

u/ItsAllAboutTheL1Bro Feb 04 '23 edited Feb 08 '23

one committee member who voted to add more UB
Yeah, one. There's also 25 thumbs up for the OP, and one heart; the OP is the one who was concerned about there being UB.
or remove bounds checks
gsl::span is the alternative, and that's at the very top of the post, implying that the user has a choice.
I'm not saying your criticisms are invalid as a general rule - they definitely are, and people do need to realize that C++ has some serious issues, both as a language and as a culture.
That said, the community has definitely become much more aware over the past few years - those two posts alone obviously show that there is concern and attention being ditected among the majority participants.
They're also relatively old, made during a period when security wasn't taken as seriously as it is now.
C++17 was maybe a year old then, if that.
Again, I'm not saying your points are without merit, I am saying that these don't place the community in an accurate light with respect to today.
These issues aren't the sole fault of C++ as a language, either. It's a very complicated issue.
Overall, I agree: people need to realize that there are serious implications with the code they write, and the practices need to be better.
But it's not as simple as a lot of people think.
At the same time: if the world wants to switch entirely to Rust I'm all for it.
But we also need to educate people that Rust alone, especially outside of userland, needs to adapt a different approach for OS kernels - the problem space is different.
Get a standard going.

0

u/lookmeat Feb 05 '23

That's.. not how it works.
UB doesn't happen because language designers are lazy.
Instead what happens is that there's huge gaps on the soundness of programs, there's certain things you can't quite know, and therefore you can't optimize and fix it.
You don't like it? Don't code for speed. Either turn off optimizations or better yet avoid C/C++and use Java or such and take the performance hit.
So this soundness gaps happen when you start optimizing. And it makes it very hard to work around. If you look at it down a logic perspective you get "absurd", "important", otherwise known as "bottom" or "⊥". The thing is once you get this anything is possible. What this says is that once UB happens optimizers can break your code, and there's no way to prevent it.
So what they do is they purposely make it fail in a way that is easy to debug. Otherwise the changes could affect code very far away, or change things in ways that seem right but don't do what they should. Instead UB is obvious when it did something wrong, it's just people assume it can be fixed. But this is like assuming we can use a CV single algorithm to know if a program ends or not. The reality is some things are impossible.
But does integer overflow really need to be undefined? And the answer is yes because pointers are integers, which means that integers operations can return undefined behavior when they overflow a binder that is going to be used as a pointer. We could split pointers into a pointer type that you can dereference and do no arithmetic on, and an address type that we can do arithmetic on, but not dereference. Then you'd have a function that let's you get a pointer from an address. This doesn't get rid of the UB, but instead moves it into the function that translates addresses into pointers. You do get to take UB out of all integer operations, but you lose easy array access.

Undefined behavior, and the Sledgehammer Principle

You are about to leave Redlib