Stack Smashing Protector

All about the OSDev Wiki. Discussions about the organization and general structure of articles and how to use the wiki. Request changes here if you don't know how to use the wiki.
Post Reply
User avatar
sortie
Member
Member
Posts: 931
Joined: Wed Mar 21, 2012 3:01 pm
Libera.chat IRC: sortie

Stack Smashing Protector

Post by sortie »

Hi,

I rewrote our article on the Stack Smashing Protector provided by modern compilers. I added it to my OS yesterday and it was quite easy. I spent some time pondering how best to implement it, whether to use gcc's libssp or whether to denounce it and use my own, how the randomness should be delivered, how it should be initialized, how best to handle such issues (realizing the handler environment could be very hostile), and so on.

I figured I'd perhaps start making forum topics when I made useful changes to the wiki that the general community could be interested in. Is that something you'd be interested in?

I took the liberty of linking it from Meaty Skeleton (a new-ish tutorial that continues Bare Bones with a full project template). I didn't add it to Bare Bones as it might just be a little too irrelevant for absolute novices, but meaty skeleton does already assume global constructors and a minimal C library is in place.

I notice we have a Security page and Security category. It could be interesting to add some stuff there and reorder it and link it better to the rest of the wiki. I think security and robustness is one of the areas where osdev can seriously compete in. For instance, I build and run my entire OS (even kernel and libc) with -fsanitize=undefined (ubsan) to catch undefined behavior, and now -fstack-protector-all to catch buffer overflows. I might actually be the first reasonably-sized operating system to use both ubsan and stack protector in the entire system. Hardening is pretty fun and straightforward to add when the base operating system is clean code, as opposed to the third party code that breaks big-time when features like this are used.

Anyways,

Share and Enjoy!
User avatar
Brynet-Inc
Member
Member
Posts: 2426
Joined: Tue Oct 17, 2006 9:29 pm
Libera.chat IRC: brynet
Location: Canada
Contact:

Re: Stack Smashing Protector

Post by Brynet-Inc »

Thanks for making the Wiki suck less sortie. :D
Image
Twitter: @canadianbryan. Award by smcerm, I stole it. Original was larger.
User avatar
xenos
Member
Member
Posts: 1121
Joined: Thu Aug 11, 2005 11:00 pm
Libera.chat IRC: xenos1984
Location: Tartu, Estonia
Contact:

Re: Stack Smashing Protector

Post by xenos »

sortie wrote:I figured I'd perhaps start making forum topics when I made useful changes to the wiki that the general community could be interested in. Is that something you'd be interested in?
Yes, definitely.

I stumbled a bit over this sentence:
The detection is perfect is a impossible to fake the correct value
I guess it should be "The detection is perfect if it is impossible to fake the correct value"?

Also, those security topics are really interesting and helpful. Many things are rather new to me and it's really nice to have this kind of introductory articles. Good work!
Programmers' Hardware Database // GitHub user: xenos1984; OS project: NOS
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Re: Stack Smashing Protector

Post by Combuster »

Interesting to state that the canary should contain a null byte, and then not doing it in the example :wink:

Before I ignorantly go put back some different magic values, where did you get these from?
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
User avatar
sortie
Member
Member
Posts: 931
Joined: Wed Mar 21, 2012 3:01 pm
Libera.chat IRC: sortie

Re: Stack Smashing Protector

Post by sortie »

I didn't say it should have a nul byte. It makes some cases safe, but offers no protection in many others. Existing operating systems randomize every bit to get more entropy. Perhaps it is worth making one byte zero on 64 bit, but I doubt it.

Those constants doesn't matter except being unlikely to collide with bugs. They are cryptographic random nunbers from /dev/random. Either use them or your own constants, it is equally bad. You must generate a random number at kernel load time.
Post Reply