flat assembler
Message board for the users of flat assembler.

flat assembler > Main > Is handwritten asm more dangerous than compiled C code?

Author
Thread Post new topic Reply to topic
wean_irdeh



Joined: 12 Sep 2018
Posts: 9
Hi guys, I was having discussion with Reddit users on vulnerability which might arise when writing asm, and their answer was the C code vulnerability also applies to asm, but worse since there are no compiler warning and mitigation

Link to the discussion:
https://www.reddit.com/r/AskNetsec/comments/9f5exx/what_vulnerability_might_arise_when_writing/
https://www.reddit.com/r/hacking/comments/9f5d5x/what_vulnerability_might_be_arise_when_writing/

Only one thing I know asm does better than C is there are no undefined behavior.

If so what are you guys gonna do to secure your handwritten code, I'm also curious on how MenuetOS handles things,
thanks in advance
Post 12 Sep 2018, 20:40
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 362
Location: Belarus
Avoiding vulnerabilities in your software is a matter of proper quality assurance, so it definitely has nothing to do with programming language you use. In fact, using a higher- or lower-level language does not immediately mean you’re protected better. HLLs have historically been created to avoid common mistakes in generic pieces of code and move some complexity from human to compiler. But as HLLs start to rely on “virtual machines” and “runtime environments” that introduces a new layer of software which essentially becomes part of the program you’ve written in such languages, and these parts are far more complex than your software could be and thus have higher probability of having vulnerabilities in them. Also LLLs, requiring more concentration from a programmer, make him more cautious about possible mistakes thus preventing them. And we all know which programming language is responsible for thousands of vulnerabilities due to its standard library full of unsafe functions.
Post 12 Sep 2018, 22:10
View user's profile Send private message Visit poster's website Reply with quote
wean_irdeh



Joined: 12 Sep 2018
Posts: 9
DimonSoft wrote:
...


Thank you! Any tips for writing secure asm code?
Post 13 Sep 2018, 00:29
View user's profile Send private message Reply with quote
Melissa



Joined: 12 Apr 2012
Posts: 56
Secure code means checks. Check for values, that's it.

edit:
yes, assembly is more secure then C. Instructions are clearly defined
and what they do. There is no undefined behavior in assembly.
Post 13 Sep 2018, 02:33
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15974
Location: Qo'noS
I don't think the language used is related to secure or insecure code. It is equally possible to write secure code in C and assembly. And it is just as equally possible to write insecure code in C and assembly.

The more complex the system become the harder it is to make secure. So I think the real answer is simply a measure of complexity, not a measure of the underlying language(s) used.

It can happen that each and every individual part can be secure on its own, but when those parts are combined into a larger system the interaction between them creates vulnerabilities.
Post 13 Sep 2018, 02:56
View user's profile Send private message Visit poster's website Reply with quote
wean_irdeh



Joined: 12 Sep 2018
Posts: 9
revolution wrote:
...

Melissa wrote:
....

Thank you! How can I avoid something like buffer overflow and integer overflow?
Post 13 Sep 2018, 04:44
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15974
Location: Qo'noS
wean_irdeh wrote:
Thank you! How can I avoid something like buffer overflow and integer overflow?
Buffer overflows: Make sure all your buffers have a known length and check all operations to make sure things fit correctly.

Integer overflows: The CPU has the O and C flags, check those to see of something went wayward.

Those are very simple types of security problems. Always be vigilant to other sorts of potential vulnerabilities. But most of all, where possible, keep your code simple. Complexity is the enemy of security.
Post 13 Sep 2018, 06:02
View user's profile Send private message Visit poster's website Reply with quote
wean_irdeh



Joined: 12 Sep 2018
Posts: 9
revolution wrote:
...


Thank you! I appreciate your answer
Post 13 Sep 2018, 06:12
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6927
Location: Kraków, Poland
The basic rule could be: whenever you copy something from one place to another, or convert from one type of data to another, ensure that the destination is correctly prepared to fit what you try to put in there. If it does not, not only abort the operation, but have a clear error route - do not let the error be ignored by the higher layers of your program unless you are absolutely sure that it does not matter to them.

Be careful around boundaries. For example, a buffer that is exactly the right size to fit your string is going to be too small if you need to add a terminating zero. When you add or increment sizes, always check for overflow (for example use JC/JO after ADD, JZ/JO after INC). Again, have a clear route for any kind of "out of range" error that may occur.
Post 13 Sep 2018, 06:19
View user's profile Send private message Visit poster's website Reply with quote
wean_irdeh



Joined: 12 Sep 2018
Posts: 9
Tomasz Grysztar wrote:
...


Thank you! That is clear enough!
Post 13 Sep 2018, 10:43
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1225
wean_irdeh wrote:
Hi guys, I was having discussion with Reddit users on vulnerability which might arise when writing asm, and their answer was the C code vulnerability also applies to asm, but worse since there are no compiler warning and mitigation

Link to the discussion:
https://www.reddit.com/r/AskNetsec/comments/9f5exx/what_vulnerability_might_arise_when_writing/
https://www.reddit.com/r/hacking/comments/9f5d5x/what_vulnerability_might_be_arise_when_writing/

Only one thing I know asm does better than C is there are no undefined behavior.

If so what are you guys gonna do to secure your handwritten code, I'm also curious on how MenuetOS handles things,
thanks in advance
Everytime someone brings up how a language is bad at security because it's "easy" to do something bad, ask him to stop looking for a scapegoat for his real problems. The problem is between the chair and the keyboard.

Of course the language can be at fault, if it's designed such that you cannot write secure code no matter what. But that is not the case here.
Post 13 Sep 2018, 12:05
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 362
Location: Belarus
Furs wrote:
Everytime someone brings up how a language is bad at security because it's "easy" to do something bad, ask him to stop looking for a scapegoat for his real problems. The problem is between the chair and the keyboard.

Of course the language can be at fault, if it's designed such that you cannot write secure code no matter what. But that is not the case here.

I’d say it’s not about black and white (can or cannot write secure code). Programming is 50 shades of gray: there are absolutely terrible languages which make it impossible to avoid vulnerabilities (and they mostly die unknown and unused), there are ideal languages (and they do not exist), and there’re lots of levels between them. Some languages just make shooting one’s leg an easy task, while others prevent that as much as they can but introduce certain difficulties in case what you want is to REALLY shoot your leg.
Post 13 Sep 2018, 13:25
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2018, Tomasz Grysztar.

Powered by rwasa.