Currently, the UCLIBC_HAS_SSP option is described as: | Note that NOEXECSTACK on a kernel with address space randomization │ │ is generally sufficient to prevent most buffer overflow exploits │ │ without increasing code size. This option essentially adds debugging │ │ code to catch them. That's not exactly correct, since SSP will also remediate "Return Oriented Programming" vulnerabilities. The technique is used to build ROP gadgets, where code is essentially pieced together from existing functions by changing return address values. ROP Gadgets don't require no-exec stacks (even though the attacker often wants to execute his/her supplied code). The concern is that folks won't take SSP because they feel a no-exec stack is all that's needed. In general, you want ASLR, DEP, and SSP.