pkg kde talk - Jan 2008 - Add security hardening for 4.0.1? (was: Introducing security hardening features for Lenny)

Hi!

I guess you have all seen the mail on -announce.
What do you think about trying to add some of these features for 4.0.1?
We recompile everything anyway and can immediately see if something
fails.
IMO at least the following flags make sense:

On Tue, 29 Jan 08 22:16, Moritz Muehlenhoff wrote:
> Stack protector
> ==============> To enable, make sure that "-fstack-protector"
ends up in the compiler flags.
> Format warnings
> ==============> This feature adds a higher level of warning reporting
for functions using
> format strings.  To enable, add "-Wformat" and
"-Wformat-security" flags,
> and pay attention to compile-time warnings.
> relro
> ====> This is enabled via "-Wl,zrelro".
No idea about this:
> Position Independent Executables
> ===============================> 
> Currently, modern kernels randomize the location of mmap and stack
> allocation, but the text segment (and subsequent brk memory) is always
> in the same place.  In kernels that support text ASLR, programs compiled
> for PIE will gain full position randomization.  This has some known
> problems on our more exotic archs, specifically hppa and m68k. These
> tool chains should be patched, so that enabling PIE is a NOP instead of
> forcing every maintainer to jump through hoops.
> 
> The flag -fPIE is very similar to -fPIC, but it applies to objects linked
to
> form the final executable binary.  PIE is enabled by passing
"-fPIE" to all
> object builds, and passing "-pie" to the final link.
Greetings,
Armin

I guess there will be a long discussion on -devel, here are some short 
hints from MaxCoder (taken from #debian-qt-kde):

.:23:23:37:.     MadCoder| SSP, FORTIFY_SOURCES, and PIE are critical
performance wise
.:23:23:52:.   mukidohime| PIE is brutal to performance, though, right?
.:23:23:55:.     MadCoder| SSP is particularily expensive for an application
that performs a lot of ''calls''
.:23:24:04:.      trigger| hm, bad
.:23:24:20:.     MadCoder| and PIE is very expensive on registers starved archs
like ? the not very used x86
.:23:24:31:.     MadCoder| so don''t get _too_ excited either
.:23:24:41:.     MadCoder| -D_FORTIFY_SOURCES=1 is a good idea though
.:23:24:55:.     MadCoder| it generates no runtime checks, and detectes a
handful of important mistakes
.:23:25:33:.      trigger| so -D_FORTIFY_SOURCES=1 and nothing else? or should
one consider SSP?
.:23:26:41:.     MadCoder| well, -pie is a very bad idea IMNSHO
.:23:26:46:.     MadCoder| the rest depends on the application
.:23:27:04:.     MadCoder| I just say, don''t get _too_ excited, most of
the proposed flags/features/... have an inherent cost
.:23:27:06:.   mukidohime| I guess it would require some kind of serious
profiling.
.:23:27:37:.     MadCoder| SSP is a technique that puts a canary (a random
value) on the stack before (or after I never remember, I suppose it''s
arch dependent anyways) on
                           the stack
.:23:27:50:.     MadCoder| and just before you RET from the call, it checks if
the canary is still there
.:23:28:21:.     MadCoder| it detects stack smashing based on the fact that if
the attacker cannot guess the canary, he''ll probably overwrite it
.:23:28:29:.     MadCoder| it''s quite effective for a broad range of
attacks
.:23:28:37:.      trigger| i see
.:23:28:45:.     MadCoder| though, each _RET_ (and there is usually one per
call) costs an additionnal check
.:23:29:19:.     MadCoder| so it''s a performance killer for anything
that does CPU-bound operations, and is coded using lots of functions
.:23:29:39:.     MadCoder| _FORTIFY_SOURCES=2 is on the same vein
.:23:29:59:.     MadCoder| it replaces some "dangerous" string
operations with functions that try to check boundaries some way or the other
.:23:30:05:.     MadCoder| I don''t really know how, I just know it
costs
.:23:30:20:.     MadCoder| and well, when it''s strcpy or strcat, I
don''t care, people using those should be shot
.:23:30:25:.     MadCoder| but it checks memcpy and memmove too
.:23:30:31:.     MadCoder| and _THAT_ sucks
.:23:30:45:.      trigger| who needs memcpy? ;)
.:23:30:57:.     MadCoder| -fPIE and -pie have the same issue as shared
libraries do
.:23:31:05:.   mukidohime| So, it''s trading stack smashing for
performance smashing?
.:23:31:11:.     MadCoder| all is rellocatable, hence every jump will be done
based on an offset
.:23:31:32:.     MadCoder| and x86 hasn''t all the relative opcodes,
hence it blocks one register to store the offset in it
.:23:31:59:.     MadCoder| other archs are less impacted afaict (like amd64 that
has all the necessary opcodes _and_ has more registers)
.:23:32:19:.     MadCoder| so it''s not really obvious to me that we
should make those 3 options default everywhere
.:23:32:36:.     MadCoder| so don''t jump on horses _yet_ :)
.:23:32:50:.   mukidohime| PIE is definitely only for a few specific uses.
.:23:33:06:.      trigger| so -D_FORTIFY_SOURCES=1 and waiting FTW :)
.:23:33:30:.   mukidohime| SSP... that would require some profiling to check the
performance hit.
.:23:34:17:.     MadCoder| well, SSP is probably not a problem for many desktop
applications
.:23:34:35:.     MadCoder| though, multimedia guys won''t like it,
whereas it''s the kind of applications that are the most vulnerable
.:23:34:54:.   mukidohime| Yeah, I think they''d much rather live fast
and loose though.
.:23:34:56:.     MadCoder| so well, all that talk was just to say,
don''t hurry, wait for the discussion that will probably come

> What do you think about trying to add some of these features for 4.0.1?
No, forget it for 4.0.1 ;)

to quote myself:
1. "you go too fast, there''s already madcoder who replied about
suggested
flags"

2. "plz, try localy first and drop your change on -talk before ;)"

I completely agree with Pierre:
"don''t hurry, wait for the discussion that will probably
come"