Please source the hardened build flags from dpkg-buildflags for
CPPFLAGS, CXXFLAGS and LDFLAGS for the iceweasel build.

Cheers,
        Moritz

FWIW, dpkg-buildflags is extremely unuseful for that, because it mixes
hardening flags with other flags.

Mike

Is that because you use a different optimization level other than
O2?

I've noticed that issue with a couple of packages, so I'm considering to
submit a patch for dpkg-buildflags, but I'd like to know if you see
different issues?

Cheers,
        Moritz

Yeah basically I like that the old way of doing hardening didn't mess
with other flags. Though I'm not sure I like that there's not much of a
fine grained tuning. For instance, I'm not sure -z relro buys anything
worth, while it may have a significant startup performance impact on big
applications. (and if I'm not mistaken, -z relro actually makes things
not work with selinux, seeing how selinux already breaks the mprotect
that removes the write bit on code sections after text relocations)

Mike

DEB_CFLAGS_MAINT_APPEND can be used to select different optimisation levels,
see 653846.

dpkg-buildflags support fine-grained tuning, e.g. relro can be disabled by
this:

jmm@pisco:~$ DEB_BUILD_MAINT_OPTIONS="hardening=-relro" dpkg-buildflags
CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security
CPPFLAGS=-D_FORTIFY_SOURCE=2
CXXFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security
FFLAGS=-g -O2
LDFLAGS=

jmm@pisco:~$ dpkg-buildflags
CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security
CPPFLAGS=-D_FORTIFY_SOURCE=2
CXXFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security
FFLAGS=-g -O2
LDFLAGS=-Wl,-z,relro

IIRC you work on startup performance at Mozilla, so I won't argue with
you on that :-)

But it would be nice if you could enable the protected stack and fortified
source features for iceweasel and iceape.

I'm not aware of such problems. Many high-profile apps in Debian have used
relro for quite some time and Ubuntu has it enabled it distro-wide for at
least two releases.

(Support for selinux in Debian is marginal at best, anyway.)

Cheers,
        Moritz

Dear Maintainer,

Can you start building packages with the other hardening options, even if RELRO
is left behind for now?

Regards,
        Florent

tags 653191 + patch
thanks

Hi Mike,

Moritz Mühlenhoff wrote (14 Jan 2012 12:34:45 GMT) :

The attached patch enables the protected stack and fortified source
build flags.

Given concerns were raised regarding dpkg-buildflags injecting
non-hardening flags, the attached patch uses the DEB_*_MAINT_STRIP
variables to strip any such non-hardening flags dpkg-buildflags would
normally inject (namely: -g -O2).

The resulting binary (10.0.3esr-3 + my patch) works fine for me on my
Debian sid system.

For the record, I have intentionally left relro, bindnow and PIE for
further discussion and iterations: better have iceweasel built with
minimal hardening flags than none. Note, though, that Ubuntu's Firefox
binary has been built with all these features for a while; any idea
how other major distributions do?

Regards,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc

Hi,

As of today, with current Sid on amd64:

$hardening-check /usr/bin/iceweasel
/usr/bin/iceweasel:
 Position Independent Executable: no, normal executable!
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: no, not found!
 Immediate binding: no, not found!

Is it possible to re-consider enabling the other hardening options?
Namely PIE, RELRO and BINDNOW

Virtually all the other distributions enable all hardening bells and
whistles as they consider web-browsers critical packages. IMHO
 firefox had enough memory corruption bugs documented over the years
 to warrant the performance cost of enabling these options.

Regards,
	Florent

Hi Florent & all,

Florent Daigniere wrote (09 Oct 2013 08:05:39 GMT) :

Thank you for raising this again.

Summing up previous discussion so that we don't have to rehash it:

  * Mike Hommey wrote: "I'm really not a big fan of -Wl,-z,relro
    and -Wl,-z,now. For instance, I'm not sure -z relro buys anything
    worth, while it may have a significant startup performance impact
    on big applications. (and if I'm not mistaken, -z relro actually
    makes things not work with selinux, seeing how selinux already
    breaks the mprotect that removes the write bit on code sections
    after text relocations)."

  * Moritz replied that he had doubts about the relro part, and that
    "Support for selinux in Debian is marginal at best, anyway".

Regarding relro and bindnow, could anyone with the relevant skills
please sum up what kind of attacks this protects against, what are the
limitations in terms of security, and what is the performance cost in
the context of something like Iceweasel? Cc'ing Jake in case he feels
like giving a hand :)

Mike, I don't think you put it clearly why you may dislike -Wl,-z,now
yet — could you please elaborate?

Regarding SELinux, there's now a release goal proposal [1] for Jessie,
but it didn't seem to get any more serious traction than the rest of
SELinux work in Debian these days. I can only wish them good luck, but
I cannot say I'm convinced this goal will be reached.

[1] https://wiki.debian.org/ReleaseGoals/SELinux

Indeed, Ubuntu enables all of PIE, stack protected, Fortify Source
functions, Read-only relocations, and Immediate binding. They're doing
it with hardening-wrapper. I failed to port this to the Iceweasel
packaging (FTBFS, IIRC), but I didn't try that hard. It might be that
they're relying on their gcc hardening patches too (if that still
applies these days, I guess Moritz will know better).

Cheers,

Am I reading correctly - there is no objection to enabling PIE (ASLR)
here?

Is it a done deal? :)
https://crypto.stanford.edu/cs155/papers/formatstring-1.2.pdf section
"6.1.1 GOT Overwrite" sums it up nicely (the document is from 2001,
there's obviously prior art... but the technique hasn't changed)

About the performance cost:
Very likely to be irrelevant compared to enabling PIE. All the linker
hardening options will slow the program start-up down... whereas PIE
will slow runtime down.

About each individual option:
http://tk-blog.blogspot.com/2009/02/relro-not-so-well-known-memory.html

-> The conclusion is that security-wise you want both. From the link
above:
"Interim conclusion: In case of a bss or data overflow bug partial and
full RELRO protect the ELF internal data sections from being overwritten
(as the ELF sections are reordered). Only full RELRO mitigates the well
known technique of modifying a GOT entry to get control over the program
execution flow"


Regards,
	Florent

Hello

As can be seen here, the version of firefox in unstable builds with the
hardening flags
https://buildd.debian.org/status/fetch.php?pkg=iceweasel&arch=i386&ver=24.3.0esr-1&stamp=1391622521

 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2


etc

So, closing this bug
S