But if we switch to a more constructive discussion and take a bigger perspective then maybe we should talk about the size of the i variable in your example as compared to the size of eax and the consequences of this difference for integer overflows? We can move on by discussing whether one’s or two’s complement representation is used in both cases, and again the consequences for integer overflow conditions. Just to begin with.

variable db ?    

Besides, even in languages with automatic memory management there’re cases when the safeguards are just not enough.

Logical errors should be fixed by changing the source code, not by inserting even more code.

Be so kind and reread all my above posts please - you will find exactly the same statement except not a single example taken out of context. Honestly speaking I fail to see how:

Code:

int i;
i++;    

differs from

Code:

inc eax    

in terms of integer overflow case for example. Could you please explain it?

In the first case the author admits that he had used uninitialized boolean variable thus resulting in this strange behavior. In asm it translates to something like this:

Code:

variable db ?    

and assuming/counting on that assembler will always use zero to fill up space. When it will use other value your code may as well fail (depending how you test for 1 and 0).

Using uninitialized variables is clearly wrong and it is considered a software defect that can lead to software vulnerabilities. So while we have UB here it was error in the source code in the first place that resulted in wrong code generation. You can make exactly the same wrong assumption in asm as well as exactly the same mistake.

Every source code defect should be handled by proper change at source code level. But we are not living in ideal world. People do introduce defects

Going your path we should disable all WAFs since they are just protecting vulnerable code from attacks. That is not how security works.

DimonSoft wrote:

But if we switch to a more constructive discussion and take a bigger perspective then maybe we should talk about the size of the i variable in your example as compared to the size of eax and the consequences of this difference for integer overflows? We can move on by discussing whether one’s or two’s complement representation is used in both cases, and again the consequences for integer overflow conditions. Just to begin with.

Please do because I apparently do not follow your way of thinking here.

Using uninitialized variables is clearly wrong and it is considered a software defect that can lead to software vulnerabilities. So while we have UB here it was error in the source code in the first place that resulted in wrong code generation. You can make exactly the same wrong assumption in asm as well as exactly the same mistake.

Second examples are similar, like in the for loop with off-by-one error at the source code level. You can write exactly the same code using asm introducing the same error - again the cause is human error. Obviously C due to its nature and number of compilers and optimization have a large pool of UB.

And your demand for secure C/C++ code with unwanted software defect is either a trick to later say “Ha-ha! It’s not a valid/secure C/C++ code since it has undefined behaviour!” or…

As for assemblers inserting some code during assembly process please check out A86 assembler. It had some interesting optimizations (like using mov offset instead of lea) and executable code watermarking.

If safeguards would make software secure we wouldn't be talking about software security in this thread - would we? The multi layer security model isn't anything new and it should not be surprising that compilers are following same path. The multiple layers model comes from the true belief that every safeguard can fail so adding another layer may decrease the risk of successful attack. Yet you need a good balance, adding too any layers or adding another layer doing the same does not work obviously. But I am sure you already know it.

When stack protection techniques were designed buffer overflows were the most popular and most exploited type of software defects. That is why C compilers do deal with them.

I think you are missing crucial point in what safeguard purpose is in the first place, hence the whole discussion. Going your path we should disable all WAFs since they are just protecting vulnerable code from attacks. That is not how security works.

who actually deal with secure coding on assembly level and so I am hoping to learn something new.

ACP wrote:

Using uninitialized variables is clearly wrong and it is considered a software defect that can lead to software vulnerabilities. So while we have UB here it was error in the source code in the first place that resulted in wrong code generation. You can make exactly the same wrong assumption in asm as well as exactly the same mistake.

You can't make the same "wrong assumption" in asm since there's no undefined behavior there. However you can probably make a lot of other wrong assumptions so half of your point is valid.

db ?    

Well, to play fair I should insert a note here that in assembly you actually can have UB. Kind of. For example, most flags are explicitly said to have undefined values after an integer division. There’re lots of cases.

1. I find it really odd that someone who doesn't know what WAF (Web Application Firewall) is talking about secure coding.

2. I find it even more strange when I hear that C compiler safeguards results in bloated code. At least in case of GCC and Visual Studio compilers you can disable all mentioned safeguards including those introduced by the linker to exploit operating system security properties. Maybe there is another C/C++ compiler that does not allow it, if so I would like to learn it's name and version. As for those 2 compilers repeating "bloated code" mantra just means that the programmer can't handle correctly tools he is using or he is criticizing.

3. Security is about thinking about out-of-the-box. You guys select simple cases that fits your way of thinking. As for using

Code:

db ?    

you are wrong again at least for a very simple case, since you assume that executable file format handles uninitialized variables sections and the OS loader does the same.

You also assumes that OS loader works the same on the same (like it never gets updated for example) and different platforms and that the code will also always run in the same, non-hostile environment which is clearly wrong assumption. There two great presentation on that topic for PE format:
https://media.blackhat.com/bh-us-11/Vuksan/BH_US_11_VuksanPericin_PECOFF_Slides.pdf
and
https://docplayer.net/34839119-Pe-specification-vs-loader.html

I will quickly recap since my main point is lost in all those rants. Assembly language is not more secure than other language.

Take look at first example with boolean variable: the only thing that stops you from writing code similar to the one generated by C compiler is knowledge, not the language itself. End of story. If you don't understand this fact you should not be talking about secure programming at all because you are becoming part of FUD movement.

1. I find it really odd that someone who doesn't know what WAF (Web Application Firewall) is talking about secure coding.

2. I find it even more strange when I hear that C compiler safeguards results in bloated code. At least in case of GCC and Visual Studio compilers you can disable all mentioned safeguards including those introduced by the linker to exploit operating system security properties. Maybe there is another C/C++ compiler that does not allow it, if so I would like to learn it's name and version. As for those 2 compilers repeating "bloated code" mantra just means that the programmer can't handle correctly tools he is using or he is criticizing.

3. Security is about thinking about out-of-the-box. You guys select simple cases that fits your way of thinking. As for using

Code:

db ?    

you are wrong again at least for a very simple case, since you assume that executable file format handles uninitialized variables sections and the OS loader does the same.

How about good old COM format from MS-DOS? FYI you can use data directives in flat binaries as well for shellcode for example. You also assumes that OS loader works the same on the same (like it never gets updated for example) and different platforms and that the code will also always run in the same, non-hostile environment which is clearly wrong assumption.

DimonSoft wrote:

Well, to play fair I should insert a note here that in assembly you actually can have UB. Kind of. For example, most flags are explicitly said to have undefined values after an integer division. There’re lots of cases.

It is also possible to get an undefined value of general-purpose register, like when BSF is used with 0 as input. Another example of the importance of input range checks.

ACP wrote:

In assembly language nothing will stop you from passing to small buffer or missing format string for sprintf line function.

I would even say that assembly can be at least as insecure as all other languages combined, because for any unsafe code you could create in another language, you can also do the same in assembly.

DimonSoft wrote:

Well, to play fair I should insert a note here that in assembly you actually can have UB. Kind of. For example, most flags are explicitly said to have undefined values after an integer division. There’re lots of cases.

It is also possible to get an undefined value of general-purpose register, like when BSF is used with 0 as input. Another example of the importance of input range checks.

void f(char* p)
{
  char tmp = *p;
 if(!p)/*do something*/
}
    

For the x86 CPU there are instructions that have some undefined results, as already stated by others here. But this isn't necessarily true for all the other CPUs. Indeed I would suspect that the x86 CPUs are the exception here, most other CPUs precisely define the outcome of every instruction for all input values.

LD r26, X+
LD r27, X+
LD r26, -X
LD r27, -X    

You cannot create undefined behavior
That is you can always predict what code will do no matter.

revolution wrote:

For the x86 CPU there are instructions that have some undefined results, as already stated by others here. But this isn't necessarily true for all the other CPUs. Indeed I would suspect that the x86 CPUs are the exception here, most other CPUs precisely define the outcome of every instruction for all input values.

From what I have seen, ARM manuals contain many mentions of "UNPREDICTABLE" behavior in various context. I'd say they even pay more attention than Intel manuals to mark such areas with with unified term.

Tomasz Grysztar wrote:

revolution wrote:

For the x86 CPU there are instructions that have some undefined results, as already stated by others here. But this isn't necessarily true for all the other CPUs. Indeed I would suspect that the x86 CPUs are the exception here, most other CPUs precisely define the outcome of every instruction for all input values.

From what I have seen, ARM manuals contain many mentions of "UNPREDICTABLE" behavior in various context. I'd say they even pay more attention than Intel manuals to mark such areas with with unified term.

You are correct. fasmarm catches all those invalid encodings so that the programmer can't shoot themselves in the foot accidentally. But of course the programmer is also free to use db, du, dw, etc. to create any encoding they wish to. But for valid encodings I think that ARM does define all possible outputs.

How can I completely avoid undefined behavior? Is this even possible?

wean_irdeh wrote:

How can I completely avoid undefined behavior? Is this even possible?

In what system are you referring to? Most of the links in this topic to C compilers talk about how it is nearly impossible to know for sure that you don't have undefined behaviour. But that is only considering the language used for the source. Since there are other ways to get undefined behaviour (e.g. from the CPU and its memory system) then perhaps such a goal is impossible.

mov rdi,0x007ce0fffffffe    ;a pointer to some string variable
add edi,2                   ;oops!