Progress on hardened1-linux-amd64 (was: Re: Proposing amd64-hardened architecture for Debian)

[Bálint Réczey]

Hi All,

2014-04-15 18:15 GMT+02:00 Thomas Goirand :
> On 04/15/2014 06:00 PM, Balint Reczey wrote:
>> Hi,
>>
...
>> My proposal for serving those security-focused users is introducing a
>> new architecture targeting amd64 hardware, but with more security
>> related C/C++ features turned on for every package (currently hardening
>> has to be enabled by the maintainers in some way) through compiler flags
>> as a start.
>>
>> Introducing the new architecture would also let package maintainers
>> enabling additional dependencies and build rules selectively for the new
>> architecture improving the security further. On the users' side the
>> advantage of having a separate security enhanced architecture instead of
>> a Debian derivative is the potential of installing a set of security
>> enhanced packages using multiarch [6]. You could have a fast amd64
>> installation as a base and run Apache or any other sensitive server from
>> the amd64-hardened packages!
>>
>> -
>>
>> What do you think? Would adding a new arch be feasible and a good solution?
>>
>> Cheers,
>> Balint
>
> My take on this: start it if you wish, and see how it takes you. If it
> is successful enough, it will go to http://www.debian-ports.org/. If it
> has even more success, then probably it will go through the standard
> repository and be official part of Debian. Whatever happens, it will be
> interesting to see what kind of performance hit you get, and what kind
> of security enhancement there is.
I made some progress on this wanna-be port in the last months [8]
starting from Helmut's and others' work on rebootsrap [9]. First, the
name is still not final, but has been changed to hardened1-linux-amd64
which fits current port naming better. There are ongoing discussions
regarding the name and I'm working on fulfilling all requirements for
new ports.

The port's objective changed slightly with targeting QA first since I
find too many bugs which prevent using the packages on a stable system
yet. :-)

Right now packages can only be cross-built, thus help on
cross-buildability of packages is highly appreciated especially for
the few missing ones needed for creating a pbuilder/sbuild chroot. You
can try plenty of build-essential packages following the post's [8]
instructions already.

I plan continuing work on this port as my time permits and if there is
significant interest from users. If you are interested and don't want
to share that in public feel free to drop me a mail.

Cheers,
Balint

[8] 
http://balintreczey.hu/blog/progress-report-on-hardened1-linux-amd64-a-potential-debian-port-with-pie-asan-ubsan-and-more/
[9] https://wiki.debian.org/HelmutGrohne/rebootstrap

Re: Bug#605090: Proposing amd64-hardened architecture for Debian

[Ben Hutchings]

On Tue, 2014-04-22 at 22:41 +0200, Yves-Alexis Perez wrote:
[...]
 NOTE: I don't want to dismiss Mempo attempts, especially the
 reproducible build part, and I also think it's valuable to provide our
 users a grsec kernel as part of the distribution, just that I prefered
 to go the featureset way.

I do want to see the Mempo reproducible build work go upstream and/or
into src:linux, as appropriate.  Unfortunately it's currently siloed
just like grsec itself.

 I had the impression that adding a new copy of the linux sources was not
 really something appreciated by the project, and re-using linux-source
 (binary) package means the patch porting needs to be done anyway.

That was what I thought, too.  Specifically, the security team is
generally opposed to such duplication.

 But if I'm wrong or if things have changed since them, and there's
 indeed a consensus for the vanilla + grsecurity + make deb-pkg as an
 easy way to provide grsec kernels in the Debian archive, then I'm all
 for it.

Well 'make deb-pkg' doesn't work with a source package so you can't use
it as a basis for official Debian packages.

The options I see are:
- Provide a source package based on src:linux that includes only the
grsec featureset on top of an appropriate base version
- Provide a source package that builds only a 'source' binary package
(like linux-source-3.13)

In any case, it needs long-term upstream support, which for jessie would
presumably mean using 3.13 as a base, whereas src:linux will be a later
version.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein


signature.asc
Description: This is a digitally signed message part

Re: Bug#605090: Proposing amd64-hardened architecture for Debian

[Yves-Alexis Perez]

On Wed, Apr 23, 2014 at 12:45:10PM +0100, Ben Hutchings wrote:
 On Tue, 2014-04-22 at 22:41 +0200, Yves-Alexis Perez wrote:
 [...]
  NOTE: I don't want to dismiss Mempo attempts, especially the
  reproducible build part, and I also think it's valuable to provide our
  users a grsec kernel as part of the distribution, just that I prefered
  to go the featureset way.
 
 I do want to see the Mempo reproducible build work go upstream and/or
 into src:linux, as appropriate.  Unfortunately it's currently siloed
 just like grsec itself.

Well, I guess the non-grsec related stuff can go upstream/src:linux, but
as I'm not involved in the project, I can't really say.
 
  I had the impression that adding a new copy of the linux sources was not
  really something appreciated by the project, and re-using linux-source
  (binary) package means the patch porting needs to be done anyway.
 
 That was what I thought, too.  Specifically, the security team is
 generally opposed to such duplication.

Well, speaking with my security team hat, I can't say I really like it,
but that's not really like having multiple copies of a library either.

Sharing an orig.tar.xz between multiple source packages would be nice
here (although it wouldn't help in case we have different versions).

In any case, that's something I'd accept, but I don't think I can have
the final word on this :)

  But if I'm wrong or if things have changed since them, and there's
  indeed a consensus for the vanilla + grsecurity + make deb-pkg as an
  easy way to provide grsec kernels in the Debian archive, then I'm all
  for it.
 
 Well 'make deb-pkg' doesn't work with a source package so you can't use
 it as a basis for official Debian packages.

Yeah, sorry my words were a bit confusing. I really mean “using a
vanilla linux.tar.xz, adding the grsecurity patch and the Debian .config
and building a Debian package with that”.
 
 The options I see are:
 - Provide a source package based on src:linux that includes only the
 grsec featureset 

Which is more or less what I do with my current patchset (except that I
keep the src:linux name, but that could be changed pretty easily I
think).

 on top of an appropriate base version

I'm not sure I understand what you mean here. You mean staying at
3.2/3.13 for example?

 - Provide a source package that builds only a 'source' binary package
 (like linux-source-3.13)

I'm not sure what's the point here? Is it about having a source package
providing a binary package containing the unpatched vanilla linux sources,
which a src:linux-grsec package could build-depend on, then I guess we
can just have vanilla linux as orig.tar.xz instead of having to
build-dep on a linux-source-vanilla-3.13.
 
 In any case, it needs long-term upstream support, which for jessie would
 presumably mean using 3.13 as a base, whereas src:linux will be a later
 version.

I guess so.

Regards,
-- 
Yves-Alexis Perez


signature.asc
Description: Digital signature

Re: Bug#605090: Proposing amd64-hardened architecture for Debian

[Ben Hutchings]

On Wed, 2014-04-23 at 17:34 +0200, Yves-Alexis Perez wrote:
 On Wed, Apr 23, 2014 at 12:45:10PM +0100, Ben Hutchings wrote:
  On Tue, 2014-04-22 at 22:41 +0200, Yves-Alexis Perez wrote:
[...]
  The options I see are:
  - Provide a source package based on src:linux that includes only the
  grsec featureset 
 
 Which is more or less what I do with my current patchset (except that I
 keep the src:linux name, but that could be changed pretty easily I
 think).
 
  on top of an appropriate base version
 
 I'm not sure I understand what you mean here. You mean staying at
 3.2/3.13 for example?

Yes.

  - Provide a source package that builds only a 'source' binary package
  (like linux-source-3.13)
 
 I'm not sure what's the point here? Is it about having a source package
 providing a binary package containing the unpatched vanilla linux sources,
 which a src:linux-grsec package could build-depend on, then I guess we
 can just have vanilla linux as orig.tar.xz instead of having to
 build-dep on a linux-source-vanilla-3.13.
[...]

No, I meant that you might build a single binary package that would
contain the grsec-patched source.  That would encourage building custom
kernels with build-time randomisation.  I understand that's not the way
you want to go.

Presumably your current package builds a linux-source-3.13 which
includes an upstream source tarball plus a grsec patch?

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein



signature.asc
Description: This is a digitally signed message part

Re: Bug#605090: Proposing amd64-hardened architecture for Debian

[Yves-Alexis Perez]

On Wed, Apr 23, 2014 at 05:02:03PM +0100, Ben Hutchings wrote:
 No, I meant that you might build a single binary package that would
 contain the grsec-patched source.  That would encourage building custom
 kernels with build-time randomisation.  I understand that's not the way
 you want to go.

Indeed. There's already a (quite outdated) linux-patch-grsecurity2
package which contains the patch for people wanting to patch the kernel
themselves. But that's not really useful imho.
 
 Presumably your current package builds a linux-source-3.13 which
 includes an upstream source tarball plus a grsec patch?

In my case, it's actually the src:linux orig.tar.xz with the (adapted)
grsec patch added to debian/patches (like other featuresets).

Regards,
-- 
Yves-Alexis Perez


signature.asc
Description: Digital signature

Re: Proposing amd64-hardened architecture for Debian

[Ben Hutchings]

On Mon, 2014-04-21 at 05:28 +0200, Carlos Alberto Lopez Perez wrote:
 On 17/04/14 00:23, Aaron Zauner wrote:
  Now shipping grsec is a really good idea. I'd like to see that as well.
 
 There has been an attempt to provide an official grsec-flavour of the
 Debian kernel, but it didn't worked:
 
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090
 
 For those interested, Corsac provides packages:
 
 https://wiki.debian.org/grsecurity

There was a recent discussion on -private where I think there was some
consensus that a grsecurity kernel package could be included in Debian
as a separate source package.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein


signature.asc
Description: This is a digitally signed message part

Re: Bug#605090: Proposing amd64-hardened architecture for Debian

[Yves-Alexis Perez]

On Tue, Apr 22, 2014 at 08:30:01PM +0100, Ben Hutchings wrote:
 On Mon, 2014-04-21 at 05:28 +0200, Carlos Alberto Lopez Perez wrote:
  On 17/04/14 00:23, Aaron Zauner wrote:
   Now shipping grsec is a really good idea. I'd like to see that as well.
  
  There has been an attempt to provide an official grsec-flavour of the
  Debian kernel, but it didn't worked:
  
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090
  
  For those interested, Corsac provides packages:
  
  https://wiki.debian.org/grsecurity
 
 There was a recent discussion on -private where I think there was some
 consensus that a grsecurity kernel package could be included in Debian
 as a separate source package.

I'm a bit unsure about that consensus. Right now there are two attempts
to provide a grsecurity package for Debian:

- mine, which is about adding a grsec featureset to the src:linux
  package (so basically adding grsec patch on top of the Debian patches,
  and re-using everything else). This attempt was already NACK-ed by the
  kernel team;
- the Mempo/SameKernel attempt, which is about using a vanilla kernel
  and adding grsecurity on top of it (and, I guess, a .config which
  looks like the src:linux one)

The latter is much easier in term of management since all the
integration is done by spender (he's actually working on providing
.deb builds of grsec packages), so I didn't really consider it worthy to
investigate time on it since basically everyone can do it with a simple
script.

NOTE: I don't want to dismiss Mempo attempts, especially the
reproducible build part, and I also think it's valuable to provide our
users a grsec kernel as part of the distribution, just that I prefered
to go the featureset way.

I had the impression that adding a new copy of the linux sources was not
really something appreciated by the project, and re-using linux-source
(binary) package means the patch porting needs to be done anyway.

But if I'm wrong or if things have changed since them, and there's
indeed a consensus for the vanilla + grsecurity + make deb-pkg as an
easy way to provide grsec kernels in the Debian archive, then I'm all
for it.

Regards,
-- 
Yves-Alexis Perez


signature.asc
Description: Digital signature

Re: Proposing amd64-hardened architecture for Debian

[Kevin Chadwick]

previously on this list Carlos Alberto Lopez Perez contributed:

  Now shipping grsec is a really good idea. I'd like to see that as well.  
 
 There has been an attempt to provide an official grsec-flavour of the
 Debian kernel, but it didn't worked:
 
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090

Interesting and the opposition to it (aside from the driver backporting
and security patching amalgamation, the intricacies of which I am
unsure of, but a resolution looked offered) seems rather unreasonable
and born of mainly mis-understandings.

KMS - You can run X11 without priv I/O which is a major hole that can be
used to bypass things like selinux though you may need to change your
kernel boot line to enable KMS early. You can also run X11 with
priviledge seperation and why linux hasn't merged OpenBSDs patches yet
beats me.

XEN - I understand the practicalities of testing many architectures but
it is arguable that user testing on bare hardware is more accurate and
I fail to see why that should be a significant blocker. Virtualisation
as a security tool has also been proven to be a false premise in that it
adds complexity and new attack vectors like Timing attacks and so I see
many Grsec advocates avoiding it anyway. A message could be added to
the kernel description about it to stop users bugging devs of course.

SELINUX - RBAC is a more robust offering than SELINUX which has had
exploits due to LKM and whilst policies are more readily portable from
say Fedora, RBAC is actually far easier to use for a user, especially
the policy file and auto generation mode. Doesn't the kernel already
have multiple RBAC systems in the security config section so I see no
reason to argue it is undesired or should be patched out.

JIT/mprotect - You do need paxctl marking in the default everything
enabled configuration, for binaries like browsers (if I remember right
-m for firefox, -r for chrome ironically due to it's sandbox). -m is
needed for a few things like xfce4-mixer, various video playing but not
gnome-alsamixer and parole for some video types. I believe the mprotect
(-m) equivelent that blocks JIT (execution of compiled at runtime code)
is the part that OpenBSD has disabled globally by default and enabled
via malloc.conf. If it was widely known it would also generally be easy
to make code work with mprotect enabled and I don't believe the
performance hit would matter outside the context of this browsers js is
fastest but can only be shown by measurement and not users experience
especially when most care about rendering speed. Getting main stream
distros to ship grsec would be a first step to understanding the issue
of JIT as mentioned by Ted Unangst in his heartbleed page and making
the next step in security for all. If that happened Linux/Unix would
leapfrog Windows in all aspects of security and not just userland,
ironically primarily due to userland coding choices and this
education would greatly help OpenBSD and Gentoo Hardened too.

Brad Spenders comments were taken out of context, he did not say it
would be better if he just offered a .deb. He said you are more likely
to get that than him splitting out his RBAC and other parts. He feels
very strongly about RBAC and other features working in tandem to
prevent exploits. I am sure he had no intention of providing a .deb
and so this was him being polite whilst probably swearing in his head.

I don't know the full story but I believe he gave up on upstream
merging many years ago as he was spending more time arguing/educating
than working on security improvements. I think kernel.org is
probably much more receptive now the Windows kernel has some of these
features and their benefits have been proven but I expect he sees that
bridge as something he personally doesn't want to get sucked into.

The Windows kernel has some of these features that are largely unused
by userland but as they are now there more will and do use them (Windows
has progressed since DEP in XP which was completely unused and rather
rubbish). Linux and all Unix-like systems would really benefit if Linux
atleast got into a position akin to Windows where that could naturally
progress and I believe Unix userland devs may be more receptive to
these security problems once understood. whereas pressure building and
explosion is likely to cause fallout of multiple kinds ;-). A position
where responses surmount to, yeah but no-one runs grsec or
Gentoo hardened  or OpenBSD anyway is unhealthy as a counter-response
yeah but many run Windows would simply blow up the thread.

p.s. Even if things break many will be happier still, OpenBSD
pro-actively breaks things because then bugs can be fixed properly
including firefox which mainly works just fine on OpenBSD. Debian and
all of Unix-like has benefitted from this bug-fixing so why not benefit
more.

-- 
___

'Write programs that do one thing and do it well. Write programs to work

Re: Proposing amd64-hardened architecture for Debian

[Riku Voipio]

On Sat, Apr 19, 2014 at 02:06:45PM +0200, Bálint Réczey wrote:
 Hi Riku,
 
 2014-04-19 13:26 GMT+02:00 Riku Voipio riku.voi...@iki.fi:
  On Tue, Apr 15, 2014 at 12:00:33PM +0200, Balint Reczey wrote:
  Facing last week's Heartbleed [1] bug the need for improving the
  security of our systems became more apparent than usually. In Debian
  there are widely used methods for Hardening [2] packages at build time
  and guidelines [3] for improving the default installations' security.
 
  Riding the Heartbleed publicity wave seems unwise, unless you can
  propose a hardening flag that would have protected users from
  Heartbleed. Else, Heartbleed merely serves on a example
  how wallpapering problems over with hardened binaries often
  doesn't help you at all..
 
  Considering that most issues protected by compiler hardening are
  also detectable by static/dynamic code analysis, a more effective security
  measure would be to spend time with clang static analyzer, valgrind, trinity
  and other tools... or actualy reviewing patches that security critical
  projects recieve.
 Thank you for bringing this up now.
 I have just managed to compile openssl, without the fix for the
 Heartbleed test but with -fsanitize=address, and as I expected it
 avoids leaking anything, I see only this in the Apache2's error.log:
 ...
 [Sat Apr 19 13:44:58.818704 2014] [core:notice] [pid 18456:tid
 3068020544] AH00094: Command line: '/us
 r/sbin/apache2'
 =
 ==18459==ERROR: AddressSanitizer: heap-buffer-overflow on address
 0xb4960411 at pc 0xb547a785 bp 0xb14f7c88 sp 0xb14f7c7c
 READ of size 1 at 0xb4960411 thread T2
 ASAN:SIGSEGV
 ==18459==AddressSanitizer: while reporting a bug found another one.Ignoring.
 =
 ==18461==ERROR: AddressSanitizer: heap-buffer-overflow on address
 0xb4960411 at pc 0xb547a785 bp 0xaf86bc88 sp 0xaf86bc7c
 READ of size 1 at 0xb4960411 thread T5
 ASAN:SIGSEGV
 ==18461==AddressSanitizer: while reporting a bug found another one.Ignoring.
 ...
 
 Since this is exactly the flag I looked at for amd64-hardened, if we
 had this arch existing a few weeks ago it would have prevented
 successful attacks on this platform.

Well this is certainly impressive - I was not aware of AddressSanitizer,
seems like very powerful and easy to us instrumentation tool. 

AddressSanitizer does not look like a flag intended for hardening. The
performance slowdown is quite steep. The instrumentation code itself might
be buggy, causing exploitation potential in itself.

Essentially this sounds about as wise as running server code under
valgrind.

 I used Heartleech for triggering the bug and the attached debdiff on openssl.
 
 The PoC is fragile because you need to set LD_PRELOAD=libasan1 and
 compile the package with the following command:
 CC=gcc-4.9 DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -rfakeroot -us -uc
 
 I have also disabled OpenSSL's feelist implementation because any
 custom memory handling would be disabled on amd64-hardened to let ASAN
  work effectively.
 
 During creating the PoC I have hit several bugs which I had to work
 around in the patch:
 
 Changes:
  openssl (1.0.1f-1~dontuseheartbleedtest) UNRELEASED; urgency=low
  .
* Enable -fsanitize=address
* Disable freelist using -DOPENSSL_NO_BUF_FREELISTS
* Add patch to fix freelist reuse from here:
  http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
* CVE-2014-0160 a.k.a Heartbleed is not fixed in this version!
* Add patch 'Check i before r[i]' to fix buffer overflow by reading
* Export ssl3_write_bytes() for compiling Heartleech
* Use -DOPENSSL_NO_ASM to prevent crash in OPENSSL_cpuid_setup on i386

This doesn't really look like a magical if it was just compiled with
hardening flags, this wouldn't have happened case. The PoC required
elobarate knowledge where the bug was and how it was hidden by
openssl's memory allocations. With -DOPENSSL_NO_BUF_FREELISTS the bug
would have been found with static analysis anyways...

Riku


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140420054723.ga26...@afflict.kos.to

Re: Proposing amd64-hardened architecture for Debian

[Bálint Réczey]

2014.04.20. 7:47, Riku Voipio riku.voi...@iki.fi ezt írta:

 On Sat, Apr 19, 2014 at 02

 On Sat, Apr 19, 2014 at 02:06:45PM +0200, Bálint Réczey wrote:
  Hi Riku,
 
  2014-04-19 13:26 GMT+02:00 Riku Voipio riku.voi...@iki.fi:
   On Tue, Apr 15, 2014 at 12:00:33PM +0200, Balint Reczey wrote:
   Facing last week's Heartbleed [1] bug the need for improving the
   security of our systems became more apparent than usually. In Debian
   there are widely used methods for Hardening [2] packages at build time
   and guidelines [3] for improving the default installations' security.
  
   Riding the Heartbleed publicity wave seems unwise, unless you can
   propose a hardening flag that would have protected users from
   Heartbleed. Else, Heartbleed merely serves on a example
   how wallpapering problems over with hardened binaries often
   doesn't help you at all..
  
   Considering that most issues protected by compiler hardening are
   also detectable by static/dynamic code analysis, a more effective
 security
   measure would be to spend time with clang static analyzer, valgrind,
 trinity
   and other tools... or actualy reviewing patches that security critical
   projects recieve.
  Thank you for bringing this up now.
  I have just managed to compile openssl, without the fix for the
  Heartbleed test but with -fsanitize=address, and as I expected it
  avoids leaking anything, I see only this in the Apache2's error.log:
  ...
  [Sat Apr 19 13:44:58.818704 2014] [core:notice] [pid 18456:tid
  3068020544] AH00094: Command line: '/us
  r/sbin/apache2'
  =
  ==18459==ERROR: AddressSanitizer: heap-buffer-overflow on address
  0xb4960411 at pc 0xb547a785 bp 0xb14f7c88 sp 0xb14f7c7c
  READ of size 1 at 0xb4960411 thread T2
  ASAN:SIGSEGV
  ==18459==AddressSanitizer: while reporting a bug found another
 one.Ignoring.
  =
  ==18461==ERROR: AddressSanitizer: heap-buffer-overflow on address
  0xb4960411 at pc 0xb547a785 bp 0xaf86bc88 sp 0xaf86bc7c
  READ of size 1 at 0xb4960411 thread T5
  ASAN:SIGSEGV
  ==18461==AddressSanitizer: while reporting a bug found another
 one.Ignoring.
  ...
 
  Since this is exactly the flag I looked at for amd64-hardened, if we
  had this arch existing a few weeks ago it would have prevented
  successful attacks on this platform.

 Well this is certainly impressive - I was not aware of AddressSanitizer,
 seems like very powerful and easy to us instrumentation tool.

 AddressSanitizer does not look like a flag intended for hardening. The
 performance slowdown is quite steep. The instrumentation code itself might
 be buggy, causing exploitation potential in itself.

 Essentially this sounds about as wise as running server code under
 valgrind.

  I used Heartleech for triggering the bug and the attached debdiff on
 openssl.
 
  The PoC is fragile because you need to set LD_PRELOAD=libasan1 and
  compile the package with the following command:
  CC=gcc-4.9 DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -rfakeroot -us -uc
 
  I have also disabled OpenSSL's feelist implementation because any
  custom memory handling would be disabled on amd64-hardened to let ASAN
   work effectively.
 
  During creating the PoC I have hit several bugs which I had to work
  around in the patch:
 
  Changes:
   openssl (1.0.1f-1~dontuseheartbleedtest) UNRELEASED; urgency=low
   .
 * Enable -fsanitize=address
 * Disable freelist using -DOPENSSL_NO_BUF_FREELISTS
 * Add patch to fix freelist reuse from here:
 
 http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
 * CVE-2014-0160 a.k.a Heartbleed is not fixed in this version!
 * Add patch 'Check i before r[i]' to fix buffer overflow by reading
 * Export ssl3_write_bytes() for compiling Heartleech
 * Use -DOPENSSL_NO_ASM to prevent crash in OPENSSL_cpuid_setup on i386

 This doesn't really look like a magical if it was just compiled with
 hardening flags, this wouldn't have happened case. The PoC required
 elobarate knowledge where the bug was and how it was hidden by
 openssl's memory allocations. With -DOPENSSL_NO_BUF_FREELISTS the bug
 would have been found with static analysis anyways...

 Riku

Re: Proposing amd64-hardened architecture for Debian

[Carlos Alberto Lopez Perez]

On 17/04/14 00:23, Aaron Zauner wrote:
 Now shipping grsec is a really good idea. I'd like to see that as well.

There has been an attempt to provide an official grsec-flavour of the
Debian kernel, but it didn't worked:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090

For those interested, Corsac provides packages:

https://wiki.debian.org/grsecurity



signature.asc
Description: OpenPGP digital signature

Re: Proposing amd64-hardened architecture for Debian

[Riku Voipio]

On Tue, Apr 15, 2014 at 12:00:33PM +0200, Balint Reczey wrote:
 Facing last week's Heartbleed [1] bug the need for improving the
 security of our systems became more apparent than usually. In Debian
 there are widely used methods for Hardening [2] packages at build time
 and guidelines [3] for improving the default installations' security.

Riding the Heartbleed publicity wave seems unwise, unless you can
propose a hardening flag that would have protected users from
Heartbleed. Else, Heartbleed merely serves on a example
how wallpapering problems over with hardened binaries often
doesn't help you at all..

Considering that most issues protected by compiler hardening are
also detectable by static/dynamic code analysis, a more effective security
measure would be to spend time with clang static analyzer, valgrind, trinity
and other tools... or actualy reviewing patches that security critical
projects recieve.

Riku


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140419112659.ga22...@afflict.kos.to

Re: Proposing amd64-hardened architecture for Debian

[Bálint Réczey]

Hi Riku,

2014-04-19 13:26 GMT+02:00 Riku Voipio riku.voi...@iki.fi:
 On Tue, Apr 15, 2014 at 12:00:33PM +0200, Balint Reczey wrote:
 Facing last week's Heartbleed [1] bug the need for improving the
 security of our systems became more apparent than usually. In Debian
 there are widely used methods for Hardening [2] packages at build time
 and guidelines [3] for improving the default installations' security.

 Riding the Heartbleed publicity wave seems unwise, unless you can
 propose a hardening flag that would have protected users from
 Heartbleed. Else, Heartbleed merely serves on a example
 how wallpapering problems over with hardened binaries often
 doesn't help you at all..

 Considering that most issues protected by compiler hardening are
 also detectable by static/dynamic code analysis, a more effective security
 measure would be to spend time with clang static analyzer, valgrind, trinity
 and other tools... or actualy reviewing patches that security critical
 projects recieve.
Thank you for bringing this up now.
I have just managed to compile openssl, without the fix for the
Heartbleed test but with -fsanitize=address, and as I expected it
avoids leaking anything, I see only this in the Apache2's error.log:
...
[Sat Apr 19 13:44:58.818704 2014] [core:notice] [pid 18456:tid
3068020544] AH00094: Command line: '/us
r/sbin/apache2'
=
==18459==ERROR: AddressSanitizer: heap-buffer-overflow on address
0xb4960411 at pc 0xb547a785 bp 0xb14f7c88 sp 0xb14f7c7c
READ of size 1 at 0xb4960411 thread T2
ASAN:SIGSEGV
==18459==AddressSanitizer: while reporting a bug found another one.Ignoring.
=
==18461==ERROR: AddressSanitizer: heap-buffer-overflow on address
0xb4960411 at pc 0xb547a785 bp 0xaf86bc88 sp 0xaf86bc7c
READ of size 1 at 0xb4960411 thread T5
ASAN:SIGSEGV
==18461==AddressSanitizer: while reporting a bug found another one.Ignoring.
...

Since this is exactly the flag I looked at for amd64-hardened, if we
had this arch existing a few weeks ago it would have prevented
successful attacks on this platform.

I used Heartleech for triggering the bug and the attached debdiff on openssl.

The PoC is fragile because you need to set LD_PRELOAD=libasan1 and
compile the package with the following command:
CC=gcc-4.9 DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -rfakeroot -us -uc

I have also disabled OpenSSL's feelist implementation because any
custom memory handling would be disabled on amd64-hardened to let ASAN
 work effectively.

During creating the PoC I have hit several bugs which I had to work
around in the patch:

Changes:
 openssl (1.0.1f-1~dontuseheartbleedtest) UNRELEASED; urgency=low
 .
   * Enable -fsanitize=address
   * Disable freelist using -DOPENSSL_NO_BUF_FREELISTS
   * Add patch to fix freelist reuse from here:
 http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
   * CVE-2014-0160 a.k.a Heartbleed is not fixed in this version!
   * Add patch 'Check i before r[i]' to fix buffer overflow by reading
   * Export ssl3_write_bytes() for compiling Heartleech
   * Use -DOPENSSL_NO_ASM to prevent crash in OPENSSL_cpuid_setup on i386


Cheers,
Balint
diff -Nru openssl-1.0.1f/debian/changelog openssl-1.0.1f/debian/changelog
--- openssl-1.0.1f/debian/changelog	2014-01-06 19:02:23.0 +0100
+++ openssl-1.0.1f/debian/changelog	2014-04-18 14:18:09.0 +0200
@@ -1,3 +1,16 @@
+openssl (1.0.1f-1~dontuseheartbleedtest) UNRELEASED; urgency=low
+
+  * Enable -fsanitize=address
+  * Disable freelist using -DOPENSSL_NO_BUF_FREELISTS
+  * Add patch to fix freelist reuse from here:
+http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
+  * CVE-2014-0160 a.k.a Heartbleed is not fixed in this version!
+  * Add patch 'Check i before r[i]' to fix buffer overflow by reading
+  * Export ssl3_write_bytes() for compiling Heartleech
+  * Use -DOPENSSL_NO_ASM to prevent crash in OPENSSL_cpuid_setup on i386
+
+ -- Balint Reczey rbal...@minipanda.sz13.dyndns.org  Thu, 17 Apr 2014 20:12:10 +0200
+
 openssl (1.0.1f-1) unstable; urgency=high
 
   * New upstream version
diff -Nru openssl-1.0.1f/debian/patches/0001-Check-i-before-r-i.patch openssl-1.0.1f/debian/patches/0001-Check-i-before-r-i.patch
--- openssl-1.0.1f/debian/patches/0001-Check-i-before-r-i.patch	1970-01-01 01:00:00.0 +0100
+++ openssl-1.0.1f/debian/patches/0001-Check-i-before-r-i.patch	2014-04-17 20:17:12.0 +0200
@@ -0,0 +1,33 @@
+From 73c92dfa0c15d7932d86130a525d1a1bc43c312a Mon Sep 17 00:00:00 2001
+From: Dr. Stephen Henson st...@openssl.org
+Date: Tue, 28 Jan 2014 15:10:27 +
+Subject: [PATCH] Check i before r[i].
+
+PR#3244
+(cherry picked from commit 9614d2c676ffe74ce0c919d9e5c0d622a011cbed)
+---
+ ssl/s3_srvr.c |4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+Index: openssl-1.0.1f/ssl/s3_srvr.c

Re: Proposing amd64-hardened architecture for Debian

[Michael Tautschnig]

On Sat, Apr 19, 2014 at 14:26:59 +0300, Riku Voipio wrote:
[...]
 Riding the Heartbleed publicity wave seems unwise, unless you can
 propose a hardening flag that would have protected users from
 Heartbleed. Else, Heartbleed merely serves on a example
 how wallpapering problems over with hardened binaries often
 doesn't help you at all..
 

+100 on this one. Hardening may be nice, but wouldn't have helped at all w.r.t.
Heartbleed (or any of the other recent SSL/TLS issues).

 Considering that most issues protected by compiler hardening are
 also detectable by static/dynamic code analysis, a more effective security
 measure would be to spend time with clang static analyzer, valgrind, trinity
 and other tools... or actualy reviewing patches that security critical
 projects recieve.
 

Or maybe even just enable -Wall when compiling and take compiler warnings
seriously (plus explicitly silence the ones you are entirely sure they are
spurious). I wish people did that, it would so much help even starting static
analysis efforts as it helps rule out all the code that static analysis cannot
formally reason about due to its inconsistencies in typing. See [1] for some of
those - if only I had more time, I'd be reporting lots more that are still on my
stack for review. And I haven't even started reporting missing include files
(and thus missing declarations). I will propose an MBF for that as soon as time
permits.

Best,
Michael

[1] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=m...@debian.orgtag=goto-cc



pgpfve1WAfSgn.pgp
Description: PGP signature

Re: Proposing amd64-hardened architecture for Debian

[Kevin Chadwick]

previously on this list Michael Tautschnig contributed:

  Riding the Heartbleed publicity wave seems unwise, unless you can
  propose a hardening flag that would have protected users from
  Heartbleed. Else, Heartbleed merely serves on a example
  how wallpapering problems over with hardened binaries often
  doesn't help you at all..

 
 +100 on this one. Hardening may be nice, but wouldn't have helped at all 
 w.r.t.
 Heartbleed (or any of the other recent SSL/TLS issues).

I am afraid you have this completely backwards. You can't use idiotic
programming to justify anything.

http://marc.info/?l=openbsd-miscm=139715715931884w=2

I am glad they are cleaning OpenSSL up 

http://undeadly.org/cgi?action=articlesid=20140418063443

Especially when what they have found is very surprising

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___

I have no idea why RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.

(Kevin Chadwick)

___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/547070.34899...@smtp119.mail.ir2.yahoo.com

Re: Proposing amd64-hardened architecture for Debian

[Aaron Zauner]

Hi Kevin,

Kevin Chadwick wrote:
 
 However I do believe Debian and Linux should be doing a lot more
 outside of grsec/pax/gentoo hardened. I could be wrong but I'm under the
 impression that Ubuntu is ahead (maybe just as more bleeding edge and
 PAE by default etc. though I am surprised they don't ship two
 kernels on their install or two cds for those few idiotic years intel
 laptops dropped PAE for).
I totally agree.

 Your links are very old and miss out combining security features.
This is true, they were intended for reference to the origin of those
attacks, current papers on those exploit techniques (or even combined
exploit techniques) can be easily obtained from a Google query :)

 OpenBSD employs randomisation all over and recently starting with the
 boot loader. you would have a real hard time making it run out of
 entropy too. I'm told it's Not AS good but is a good start, has debian
 considered running haveged by default?
As I am somewhat involved with the bettercrypto.org project, haveged has
come up quite a lot. The idea behind it is sound, the only problem I see
is missing (to the best of my knowledge) security audits and review by
cryptographers outside of the project itself. The original paper is now
very dated and I have not found and solid audit paper (or even a paper
that tries to attack haveged) on the web. I'm not sure if that's a good
or a bad sign.

Usually the Linux kernel itself provides more than enough entropy. This
can (and probably should) be enhanced but should  not be done in a
specific distribution.

 An abstract on this very subject
 ___
 
 (1) introduce/execute arbitrary code
 (2) execute existing code out of original program order
 (3) execute existing code in original program order with arbitrary data
 
 For example the well known shellcode injection technique belongs to (1) 
 while the so-called return-to-libc style technique belongs to (2).
 
 Before going into the analysis of the above techniques, let's note an
 often overlooked or misunderstood property of combining defense
 mechanisms. Some like to look at the individual pieces of a system and
 arrive at a conclusion regarding the effectivenes of the whole based on
 that (or worse, dismiss one mechanism because it is not efficient
 without employing another, and vice versa). In our case this approach
 can lead to misleading results. Consider that one has a defense
 mechanism against (1) and (2) such as NOEXEC and the future userland
 changes in PaX. If only NOEXEC is employed, one could argue that it is
 pointless since (2) can still be used (in practice this reason has
 often been used to dismiss non-executable stack approaches, which is
 not to be confused with NOEXEC however). If one protects against (2)
 only then one could equally well argue that why bother at all if the
 attacker can go directly for (1) and then the final conclusion comes
 saying that none of these defense mechanisms is effective. As hinted at
 above, this turns out to be the wrong conclusion here, deploying both
 kinds of defense mechanisms will protect against both (1) and (2) at
 the same time - where one defense line would fail, the other prevents
 that (i.e., NOEXEC can be broken by a return-to-libc style attack only
 and vice versa).
 ___
Yeah. I wasn't trying to argue that PaX/W^X is a bad idea, to the
contrary. I was refering to stack canaries. I do question if building
all packages with -fstack-protector is a good idea, of course plattforms
are very fast now, but it bloats binaries with minimal added security.

 Building exploit mitigations isn’t easy. It’s difficult because the
 attackers are relentlessly clever. And it’s aggravating because there’s
 so much shitty software that doesn’t run properly even when it’s not
 under attack, meaning that many mitigations cannot be fully enabled.
 But it’s absolutely infuriating when developers of security sensitive
 software are actively thwarting those efforts by using the world’s most
 exploitable allocation policy and then not even testing that one can
 disable it.
Nothing to add here, very well said!

Aaron



signature.asc
Description: OpenPGP digital signature

Re: Proposing amd64-hardened architecture for Debian

[Vincent Danjean]

  Hi,

On 18/04/2014 00:15, Kevin Chadwick wrote:
 OpenBSD employs randomisation all over and recently starting with the
 boot loader.

  I do not object to use such techniques (randomisation for example) by
default. However, it must be easy to disable them.
  Indeed: not all computers are are used as servers where security must be
really strong. Some computers are used to do development. And, in this case,
randomization is sometime really annoying: each time you re-run your program,
all variables have a new address under gdb. So, if you want to use the 'watch'
command, you need first to find again and again the address of the field of
the structure you are interested on.

  So please, take such usages into account when pushing for a better
security: document an easy way to revert to the less secure but
deterministic/non hidden/... runtime mode. It can be as simple as
documenting kernel.randomize_va_space=0 sysctl parameter for example.

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5351400b@free.fr

Re: Proposing amd64-hardened architecture for Debian

[Kevin Chadwick]

On Fri, 18 Apr 2014 14:57:41 +0200
Aaron Zauner wrote:

  Usually the Linux kernel itself provides more than enough entropy. This
  can (and probably should) be enhanced but should  not be done in a
  specific distribution.

I know there has been a little work on the kernel in this area, mainly
when you have a modern cpu you will be fine but are the days of waiting
on gpg and being asked to move the mouse on the latest Linux Kernel and
whichever kernel lands in debian 8 over? You should be able to write
gigabytes of random data to disk without any worry.

  Building exploit mitigations isn’t easy. It’s difficult because the
  attackers are relentlessly clever. And it’s aggravating because there’s
  so much shitty software that doesn’t run properly even when it’s not
  under attack, meaning that many mitigations cannot be fully enabled.
  But it’s absolutely infuriating when developers of security sensitive
  software are actively thwarting those efforts by using the world’s most
  exploitable allocation policy and then not even testing that one can
  disable it.  

 Nothing to add here, very well said!

I realised just after sending that I had removed one too many seperating
lines (before the link).

So I wasn't as clear as I meant to be in that the bit above was taken
from an OpenBSD devs (Teds) page about Heartbleed.

http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/505473.83266...@smtp146.mail.ir2.yahoo.com

Re: Proposing amd64-hardened architecture for Debian

[Kevin Chadwick]

previously on this list Aaron Zauner contributed:

I agree with MACs being questionable in that they are an extra
*FINAL* layer only really effective on simple systems where they
arguably aren't needed, can be circumvented by kernel exploits and
often MACs are used on systems despite the wide ranging capabilities of
DACs being ignored which are more reliable and less complex

(RedHat/Fedora failing to realise the power of existing tech like groups
is a classic example, Debian is better here).

However I do believe Debian and Linux should be doing a lot more
outside of grsec/pax/gentoo hardened. I could be wrong but I'm under the
impression that Ubuntu is ahead (maybe just as more bleeding edge and
PAE by default etc. though I am surprised they don't ship two
kernels on their install or two cds for those few idiotic years intel
laptops dropped PAE for).

 I'm aware of this. Some of them also implement PaX (or W^X in OpenBSDs
 case). That said, it will probably improve security a bit, in particular
 against skiddies just running scripts of the web. But any serious
 attacker may circumvent stack canaries anyway. Thats not deep magic
 anymore. There are now automated tools to make ROP/return-to-lib-c
 attacks particularly easy to pull off (finding ROP gadgets
 automatically, even writing weaponized exploit code and so forth).

Your links are very old and miss out combining security features.
OpenBSD employs randomisation all over and recently starting with the
boot loader. you would have a real hard time making it run out of
entropy too. I'm told it's Not AS good but is a good start, has debian
considered running haveged by default?

The average linux system is lagging behind.

http://www.openbsd.org/papers/ru13-deraadt/

The linux code may be less integrated as it is just the kernel but is
all there as shown below and mentioned in Theo's Talk above.

http://pax.grsecurity.net/docs/pax.txt
http://pax.grsecurity.net/docs/PaXTeam-LATINOWARE12-PaX-linux-security.pdf

An abstract on this very subject
___

(1) introduce/execute arbitrary code
(2) execute existing code out of original program order
(3) execute existing code in original program order with arbitrary data

For example the well known shellcode injection technique belongs to (1) 
while the so-called return-to-libc style technique belongs to (2).

Before going into the analysis of the above techniques, let's note an
often overlooked or misunderstood property of combining defense
mechanisms. Some like to look at the individual pieces of a system and
arrive at a conclusion regarding the effectivenes of the whole based on
that (or worse, dismiss one mechanism because it is not efficient
without employing another, and vice versa). In our case this approach
can lead to misleading results. Consider that one has a defense
mechanism against (1) and (2) such as NOEXEC and the future userland
changes in PaX. If only NOEXEC is employed, one could argue that it is
pointless since (2) can still be used (in practice this reason has
often been used to dismiss non-executable stack approaches, which is
not to be confused with NOEXEC however). If one protects against (2)
only then one could equally well argue that why bother at all if the
attacker can go directly for (1) and then the final conclusion comes
saying that none of these defense mechanisms is effective. As hinted at
above, this turns out to be the wrong conclusion here, deploying both
kinds of defense mechanisms will protect against both (1) and (2) at
the same time - where one defense line would fail, the other prevents
that (i.e., NOEXEC can be broken by a return-to-libc style attack only
and vice versa).
___

Personally I look forward to the day that code is written with these
security features in mind and it is realised that browser rendering
speed is important but JIT needs to go.

WRT heartbleed it is quite shocking that this memory handling was
applied to all builds.

http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse

Building exploit mitigations isn’t easy. It’s difficult because the
attackers are relentlessly clever. And it’s aggravating because there’s
so much shitty software that doesn’t run properly even when it’s not
under attack, meaning that many mitigations cannot be fully enabled.
But it’s absolutely infuriating when developers of security sensitive
software are actively thwarting those efforts by using the world’s most
exploitable allocation policy and then not even testing that one can
disable it.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd

Re: Proposing amd64-hardened architecture for Debian

[Aaron Zauner]

Hi Balint,

Balint Reczey wrote:
 Hi,
 
 I have posted the following idea on my blog [7] to get comments from
 people not on this list, but obviously this is the mailing list where
 the proposal should be discussed. :-)
I generally agree with your concerns. But I have to concur that
hardening the default should be the way to go. Besides, this does not
only concern compiler flags, you'll need kernel hardening and active
auditing (package source code, userland utitities and so forth). The
thing is the OpenSSL vulnerability probably wouldn't have been resolved
using those flags. Another example: stack canaries are a nice idea but
have since been circumvented as new exploit techniques are constantly
emerging. Another example: the new Kernel ASLR feature has recently been
curvumvented by spender of GRSEC. Simply running valgrind on your system
might flag a lot of false-positives and figuring out what the right
approach for a given package is will be - again - active auditing and
thus extremely time consuming. The best way to do this is upstream not
in a specific distribution from my experience.

A hardened distribution is a lot of effort, I've seen the Gentoo guys
try it but it seems to be largely unmaintained nowadays. Hence -
currently - the burden falls on security and systems engineers that
deploy systems on a given Linux distribution.

Aaron



signature.asc
Description: OpenPGP digital signature

Re: Proposing amd64-hardened architecture for Debian

[Martin Wuertele]

* Balint Reczey bal...@balintreczey.hu [2014-04-15 12:01]:

(...)

 My proposal for serving those security-focused users is introducing a
 new architecture targeting amd64 hardware, but with more security
 related C/C++ features turned on for every package (currently hardening
 has to be enabled by the maintainers in some way) through compiler flags
 as a start.
 
 Introducing the new architecture would also let package maintainers
 enabling additional dependencies and build rules selectively for the new
 architecture improving the security further. On the users' side the
 advantage of having a separate security enhanced architecture instead of
 a Debian derivative is the potential of installing a set of security
 enhanced packages using multiarch [6]. You could have a fast amd64
 installation as a base and run Apache or any other sensitive server from
 the amd64-hardened packages!
 
 -
 
 What do you think? Would adding a new arch be feasible and a good solution?

Why is it not feasable to provide additional -hardened packages? With
that it would be possible to provide hardened versions of packages on
other archs as well.

Kind regards,
Martin


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140416125330.gb12...@anguilla.debian.or.at

Re: Proposing amd64-hardened architecture for Debian

[Bálint Réczey]

Hi Martin,

2014-04-16 14:53 GMT+02:00 Martin Wuertele mar...@wuertele.net:
 * Balint Reczey bal...@balintreczey.hu [2014-04-15 12:01]:

 (...)

 My proposal for serving those security-focused users is introducing a
 new architecture targeting amd64 hardware, but with more security
 related C/C++ features turned on for every package (currently hardening
 has to be enabled by the maintainers in some way) through compiler flags
 as a start.

 Introducing the new architecture would also let package maintainers
 enabling additional dependencies and build rules selectively for the new
 architecture improving the security further. On the users' side the
 advantage of having a separate security enhanced architecture instead of
 a Debian derivative is the potential of installing a set of security
 enhanced packages using multiarch [6]. You could have a fast amd64
 installation as a base and run Apache or any other sensitive server from
 the amd64-hardened packages!

 -

 What do you think? Would adding a new arch be feasible and a good solution?

 Why is it not feasable to provide additional -hardened packages? With
 that it would be possible to provide hardened versions of packages on
 other archs as well.
Providing -hardened packages on a per -package basis is certainly
doable, but it would not scale IMO to useful level. With the proposed
multiarch based method one would be pick a binary and all of the
library dependencies from the hardened arch from top to bottom.

In case of providing -hardened binary packages for amd64 to achieve
the same results we would have to wait for all library packagers to
provide -hardened versions and even a single developer not having time
could block the goal.
Managing the dependencies between -hardened and normal libraries seem
to be a complex problem which I would like to avoid.

Cheers,
Balint


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpytg9u4dkacrebbstk3_a3jjtzvvkmhkwsznnzemjq...@mail.gmail.com

Re: Proposing amd64-hardened architecture for Debian

[Bálint Réczey]

Hi Aaron,

2014-04-16 13:49 GMT+02:00 Aaron Zauner a...@azet.org:
 Hi Balint,

 Balint Reczey wrote:
 Hi,

 I have posted the following idea on my blog [7] to get comments from
 people not on this list, but obviously this is the mailing list where
 the proposal should be discussed. :-)
 I generally agree with your concerns. But I have to concur that
 hardening the default should be the way to go. Besides, this does not
 only concern compiler flags, you'll need kernel hardening and active
 auditing (package source code, userland utitities and so forth). The
 thing is the OpenSSL vulnerability probably wouldn't have been resolved
 using those flags. Another example: stack canaries are a nice idea but
 have since been circumvented as new exploit techniques are constantly
 emerging. Another example: the new Kernel ASLR feature has recently been
 curvumvented by spender of GRSEC. Simply running valgrind on your system
 might flag a lot of false-positives and figuring out what the right
 approach for a given package is will be - again - active auditing and
 thus extremely time consuming. The best way to do this is upstream not
 in a specific distribution from my experience.
I agree that it would be unrealistic to solve all security related
problems with a new architecture, but I think it would be a good way
of improving what we can.

The upstream project I'm most involved in is Wireshark where we try to
employ most of the state of the art techniques for improving code
quality but I think the Wireshark project is in much better position
than most other projects. Thanks to dedicated team and community we
can build on 3 different static analyzers, CI buildbots on 6 different
platforms and tests fuzzing with Valgrind all day long.

For the projects lacking this infrastructure Debian can provide build
tests for many platforms and could also be the project where
additional hardening flags could catch security problems. Expecting
all upstreams to be able to keep up with latest security best
practices is not realistic to me. A trivial example is the case of
dead upstreams.

It is true that stack canaries can't catch everything, but it detects
a fair share of attacks. Note that -fstack-protector is used by
default for all packages in Ubuntu, Fedora, ArchLinux, OpenBSD and
others:
http://en.wikipedia.org/wiki/Buffer_overflow_protection


 A hardened distribution is a lot of effort, I've seen the Gentoo guys
 try it but it seems to be largely unmaintained nowadays. Hence -
 currently - the burden falls on security and systems engineers that
 deploy systems on a given Linux distribution.
The new architecture would target hardening the toolchain as the first
goal and I consider this is doable with reasonable effort. Other parts
like SELinux and Grsecurity-enabled kernel
can be done (and are already being developed) for all architectures
independently from the porting effort.

https://wiki.gentoo.org/wiki/Project:Hardened

Cheers,
Balint


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpyndqwfd_wu_raqxldgpqebjeg0yeqkc2lrsxp-jbq...@mail.gmail.com

Re: Proposing amd64-hardened architecture for Debian

[Bálint Réczey]

Hi Steve,

2014-04-15 20:07 GMT+02:00 Steve Langasek vor...@debian.org:
 On Wed, Apr 16, 2014 at 12:15:22AM +0800, Thomas Goirand wrote:
  My proposal for serving those security-focused users is introducing a
  new architecture targeting amd64 hardware, but with more security
  related C/C++ features turned on for every package (currently hardening
  has to be enabled by the maintainers in some way) through compiler flags
  as a start.

 My take on this: start it if you wish, and see how it takes you. If it
 is successful enough, it will go to http://www.debian-ports.org/. If it
 has even more success, then probably it will go through the standard
 repository and be official part of Debian. Whatever happens, it will be
 interesting to see what kind of performance hit you get, and what kind
 of security enhancement there is.

 I would not presume that debian-ports.org would be willing to accept this
 port without detailed discussion with Debian about what it means to provide
 a different port with the same ABI.
Thank you for raising this concern. I hope I could get input from
people deciding on accepting/rejecting the proposed port on this list.
If not I'll reach them directly.


 The other recent notable port of this kind (changing the compiler defaults
 without changing the ABI) is Raspbian, which we have not found a way to
 effectively integrate into the Debian archive.  It lives in its own domain,
 not under debian-ports, because it conflicts with and is unidirectionally
 incompatible with the existing armhf port.

 It would be great to see someone tackle the question of subarchs for dpkg,
 which might be a fit here.  But I don't imagine that you're going to get
 signoff on a dpkg amd64-secure architecture, so doing this in debian or on
 debian-ports isn't very practical.
I'm not sure what technical matters prevent having the same ABI in two
different architectures if the multiarch names differ as well, but if
there is any I think they can be handled so I hope to get the signoff.
I would like to avoid going the Raspbian way.

Cheers,
Balint


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK0OdpzVq_8etn2-KG+HLQ_3=eiqydeu2q0ysgt0h8nvxgq...@mail.gmail.com

Re: Proposing amd64-hardened architecture for Debian

[Aaron Zauner]

Hi Balint,

Bálint Réczey wrote:
 The upstream project I'm most involved in is Wireshark where we try to
 employ most of the state of the art techniques for improving code
 quality but I think the Wireshark project is in much better position
 than most other projects. Thanks to dedicated team and community we
 can build on 3 different static analyzers, CI buildbots on 6 different
 platforms and tests fuzzing with Valgrind all day long.
 For the projects lacking this infrastructure Debian can provide build
 tests for many platforms and could also be the project where
 additional hardening flags could catch security problems. Expecting
 all upstreams to be able to keep up with latest security best
 practices is not realistic to me. A trivial example is the case of
 dead upstreams.

That's certainly the way on how to approach proper security testing
within an upstream project, but it does already take some effort only
for one project, imagine how much effort it takes doing this for e.g.
all debian packages. As I said it's not simply running audit tools on
code and binaries, the actual work is figuring out what is to be done if
there are warnings and how this translates to (upstream) code.

I'm the last person to speak against security improvements within a
linux distribution. But it just does not seem to be a feasible or a
realistic task.

 It is true that stack canaries can't catch everything, but it detects
 a fair share of attacks. Note that -fstack-protector is used by
 default for all packages in Ubuntu, Fedora, ArchLinux, OpenBSD and
 others:
 http://en.wikipedia.org/wiki/Buffer_overflow_protection
I'm aware of this. Some of them also implement PaX (or W^X in OpenBSDs
case). That said, it will probably improve security a bit, in particular
against skiddies just running scripts of the web. But any serious
attacker may circumvent stack canaries anyway. Thats not deep magic
anymore. There are now automated tools to make ROP/return-to-lib-c
attacks particularly easy to pull off (finding ROP gadgets
automatically, even writing weaponized exploit code and so forth).

See:
http://cseweb.ucsd.edu/~hovav/dist/rop.pdf
https://en.wikipedia.org/wiki/Return-to-libc_attack
http://phrack.org/issues/59/9.html

 The new architecture would target hardening the toolchain as the first
 goal and I consider this is doable with reasonable effort. Other parts
 like SELinux and Grsecurity-enabled kernel
 can be done (and are already being developed) for all architectures
 independently from the porting effort.
Now shipping grsec is a really good idea. I'd like to see that as well.
SELinux is just a PITA with no added security functionality except
security by obscurity. I know there are people seriously making a living
of implementing SELinux policies for customers - I still do not get why.
Everytime somebody mentions SELinux I point them to this nice pic that
pretty much hits the nail on the head:
https://grsecurity.net/~spender/pics/mac_security_sesamestreet.jpg :)

Nowadays almost every guide to set up some kind of software for e.g.
RHEL/CentOS/.. mentions to `setenforce 0` first. And that's what systems
engineers do in production.

A couple of years back I've played extensively with TrustedSolaris and
TrustedBSD (same idea as SELinux) and SELinux. It's a nightmare. For a
multiuser system running a couple of servies you will spend not weeks
but months to define a policy that keeps the system in a usable state.
This is just unacceptable to most - it's not however - to the people
that design, implement and use such paranoid policy systems: NSA and the
intelligence community in general. I like to think people get rich of
writing policies for those people with no added benefit for security, it
amuses me. Beautiful codebase though.

Aaron




signature.asc
Description: OpenPGP digital signature

Proposing amd64-hardened architecture for Debian

[Balint Reczey]

Hi,

I have posted the following idea on my blog [7] to get comments from
people not on this list, but obviously this is the mailing list where
the proposal should be discussed. :-)

-

Facing last week's Heartbleed [1] bug the need for improving the
security of our systems became more apparent than usually. In Debian
there are widely used methods for Hardening [2] packages at build time
and guidelines [3] for improving the default installations' security.

Employing such methods usually come at an expense, for example slower
code execution of binaries due to additional checks or additional
configuration steps when setting up a system. Balancing between
usability and security Debian chose an approach which would satisfy the
most users by using C/C++ features [4] which only slightly decrease
execution speed of built binaries and by using reasonable defaults in
package installations.

All the architectures supported by  Debian aims using the same methods
for enhancing security but it does not have to stay the same way. Amd64
is the most widely used architecture of Debian according to popcon [5]
and amd64 hardware comes with powerful CPU-s. I think there would be a
significant amount of people (being one of them :-)) who would happily
use a version of Debian with more security features enabled by default
sacrificing some CPU power and installing and setting up additional
packages.

My proposal for serving those security-focused users is introducing a
new architecture targeting amd64 hardware, but with more security
related C/C++ features turned on for every package (currently hardening
has to be enabled by the maintainers in some way) through compiler flags
as a start.

Introducing the new architecture would also let package maintainers
enabling additional dependencies and build rules selectively for the new
architecture improving the security further. On the users' side the
advantage of having a separate security enhanced architecture instead of
a Debian derivative is the potential of installing a set of security
enhanced packages using multiarch [6]. You could have a fast amd64
installation as a base and run Apache or any other sensitive server from
the amd64-hardened packages!

-

What do you think? Would adding a new arch be feasible and a good solution?

Cheers,
Balint

PS: There was a long security related thread on -private which I can't
refer to and in which Paul Wise proposed a secondary high-security (but
slower) archive, and while I think it is a very good idea it would not
allow mixing fast and secure packages using multiarch.

[1] http://heartbleed.com/
[2] https://wiki.debian.org/Hardening
[3]
https://www.debian.org/doc/manuals/securing-debian-howto/ch-automatic-harden.en.html
[4]
https://wiki.debian.org/Hardening#Notes_on_Memory_Corruption_Mitigation_Methods
[5] http://popcon.debian.org/index.html
[6] https://wiki.debian.org/Multiarch
[7]
http://balintreczey.hu/blog/proposing-amd64-hardened-architecture-for-debian




signature.asc
Description: OpenPGP digital signature

Re: Proposing amd64-hardened architecture for Debian

[Christian Hofstaedtler]

* Balint Reczey bal...@balintreczey.hu [140415 12:01]:
[..]
 My proposal for serving those security-focused users is introducing a
 new architecture targeting amd64 hardware, but with more security
 related C/C++ features turned on for every package (currently hardening
 has to be enabled by the maintainers in some way) through compiler flags
 as a start.
 
[..]
 What do you think? Would adding a new arch be feasible and a good solution?

I think that as of today it would help more to fix various upstream
build tools to actually honor the build flags we (using
dpkg-buildflags) set. This would benefit both the regular
architectures and any hypothetical hardened archs.

Regarding a special hardened arch, I think on amd64 there's almost
no benefit of making a seperate arch: just turn on all the hardening
stuff in amd64, the hardware is fast enough to tolerate some
slowdown as a tradeoff for better security.
No ideas for/about the other archs.

-- 
 ,''`.  Christian Hofstaedtler z...@debian.org
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-



pgpnjPfVC7EW9.pgp
Description: PGP signature

Re: Proposing amd64-hardened architecture for Debian

[Paul Wise]

On Tue, Apr 15, 2014 at 8:15 PM, Christian Hofstaedtler wrote:

 I think that as of today it would help more to fix various upstream
 build tools to actually honor the build flags we (using
 dpkg-buildflags) set. This would benefit both the regular
 architectures and any hypothetical hardened archs.

Also necessary is for them to support being built with other compilers.

 Regarding a special hardened arch, I think on amd64 there's almost
 no benefit of making a seperate arch: just turn on all the hardening
 stuff in amd64, the hardware is fast enough to tolerate some
 slowdown as a tradeoff for better security.
 No ideas for/about the other archs.

You need a separate architecture if your security enhancements are
going to give a 50% speed hit.

https://events.ccc.de/congress/2013/Fahrplan/events/5412.html
https://media.ccc.de/browse/congress/2013/30C3_-_5412_-_en_-_saal_1_-_201312271830_-_bug_class_genocide_-_andreas_bogk.html

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6FWcEaeEwT1pKe527Jm+n6CtYjhme=lov01c+sqahs...@mail.gmail.com

Re: Proposing amd64-hardened architecture for Debian

[Bálint Réczey]

2014-04-15 14:23 GMT+02:00 Paul Wise p...@debian.org:
 On Tue, Apr 15, 2014 at 8:15 PM, Christian Hofstaedtler wrote:

 I think that as of today it would help more to fix various upstream
 build tools to actually honor the build flags we (using
 dpkg-buildflags) set. This would benefit both the regular
 architectures and any hypothetical hardened archs.

 Also necessary is for them to support being built with other compilers.
As a package maintainer I make sure that an other compiler and
additional flags are honored whenever it is possible/reasonable by
either patching the build system or upstreaming the patches.
It is worth the effort and is definitely needed, but changing GCC
defaults would speed up making the binaries protected.


 Regarding a special hardened arch, I think on amd64 there's almost
 no benefit of making a seperate arch: just turn on all the hardening
 stuff in amd64, the hardware is fast enough to tolerate some
 slowdown as a tradeoff for better security.
 No ideas for/about the other archs.

 You need a separate architecture if your security enhancements are
 going to give a 50% speed hit.

 https://events.ccc.de/congress/2013/Fahrplan/events/5412.html
 https://media.ccc.de/browse/congress/2013/30C3_-_5412_-_en_-_saal_1_-_201312271830_-_bug_class_genocide_-_andreas_bogk.html
Yes, I fully agree with Paul on this. I was thinking of enabling
address sanitizer in Wireshark (wearing my upstream hat), but the
performance impact (2x slowdown) would be too much for some heavy
users.
http://clang.llvm.org/docs/AddressSanitizer.html

I think it could be enabled in a separate arch.

Cheers,
Balint


 --
 bye,
 pabs

 http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK0OdpwprpTgAFub=9ogjC=p9ghgjrbaqmny-pbj5mno-ky...@mail.gmail.com

Re: Proposing amd64-hardened architecture for Debian

[Thomas Goirand]

On 04/15/2014 06:00 PM, Balint Reczey wrote:
 Hi,
 
 I have posted the following idea on my blog [7] to get comments from
 people not on this list, but obviously this is the mailing list where
 the proposal should be discussed. :-)
 
 -
 
 Facing last week's Heartbleed [1] bug the need for improving the
 security of our systems became more apparent than usually. In Debian
 there are widely used methods for Hardening [2] packages at build time
 and guidelines [3] for improving the default installations' security.
 
 Employing such methods usually come at an expense, for example slower
 code execution of binaries due to additional checks or additional
 configuration steps when setting up a system. Balancing between
 usability and security Debian chose an approach which would satisfy the
 most users by using C/C++ features [4] which only slightly decrease
 execution speed of built binaries and by using reasonable defaults in
 package installations.
 
 All the architectures supported by  Debian aims using the same methods
 for enhancing security but it does not have to stay the same way. Amd64
 is the most widely used architecture of Debian according to popcon [5]
 and amd64 hardware comes with powerful CPU-s. I think there would be a
 significant amount of people (being one of them :-)) who would happily
 use a version of Debian with more security features enabled by default
 sacrificing some CPU power and installing and setting up additional
 packages.
 
 My proposal for serving those security-focused users is introducing a
 new architecture targeting amd64 hardware, but with more security
 related C/C++ features turned on for every package (currently hardening
 has to be enabled by the maintainers in some way) through compiler flags
 as a start.
 
 Introducing the new architecture would also let package maintainers
 enabling additional dependencies and build rules selectively for the new
 architecture improving the security further. On the users' side the
 advantage of having a separate security enhanced architecture instead of
 a Debian derivative is the potential of installing a set of security
 enhanced packages using multiarch [6]. You could have a fast amd64
 installation as a base and run Apache or any other sensitive server from
 the amd64-hardened packages!
 
 -
 
 What do you think? Would adding a new arch be feasible and a good solution?
 
 Cheers,
 Balint

My take on this: start it if you wish, and see how it takes you. If it
is successful enough, it will go to http://www.debian-ports.org/. If it
has even more success, then probably it will go through the standard
repository and be official part of Debian. Whatever happens, it will be
interesting to see what kind of performance hit you get, and what kind
of security enhancement there is.

Just my 2 cents,

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/534d5b1a.3070...@debian.org

Re: Proposing amd64-hardened architecture for Debian

[Mathieu Malaterre]

On Tue, Apr 15, 2014 at 6:15 PM, Thomas Goirand z...@debian.org wrote:
 On 04/15/2014 06:00 PM, Balint Reczey wrote:
 Hi,

 I have posted the following idea on my blog [7] to get comments from
 people not on this list, but obviously this is the mailing list where
 the proposal should be discussed. :-)

 -

 Facing last week's Heartbleed [1] bug the need for improving the
 security of our systems became more apparent than usually. In Debian
 there are widely used methods for Hardening [2] packages at build time
 and guidelines [3] for improving the default installations' security.

 Employing such methods usually come at an expense, for example slower
 code execution of binaries due to additional checks or additional
 configuration steps when setting up a system. Balancing between
 usability and security Debian chose an approach which would satisfy the
 most users by using C/C++ features [4] which only slightly decrease
 execution speed of built binaries and by using reasonable defaults in
 package installations.

 All the architectures supported by  Debian aims using the same methods
 for enhancing security but it does not have to stay the same way. Amd64
 is the most widely used architecture of Debian according to popcon [5]
 and amd64 hardware comes with powerful CPU-s. I think there would be a
 significant amount of people (being one of them :-)) who would happily
 use a version of Debian with more security features enabled by default
 sacrificing some CPU power and installing and setting up additional
 packages.

 My proposal for serving those security-focused users is introducing a
 new architecture targeting amd64 hardware, but with more security
 related C/C++ features turned on for every package (currently hardening
 has to be enabled by the maintainers in some way) through compiler flags
 as a start.

 Introducing the new architecture would also let package maintainers
 enabling additional dependencies and build rules selectively for the new
 architecture improving the security further. On the users' side the
 advantage of having a separate security enhanced architecture instead of
 a Debian derivative is the potential of installing a set of security
 enhanced packages using multiarch [6]. You could have a fast amd64
 installation as a base and run Apache or any other sensitive server from
 the amd64-hardened packages!

 -

 What do you think? Would adding a new arch be feasible and a good solution?

 Cheers,
 Balint

 My take on this: start it if you wish, and see how it takes you. If it
 is successful enough, it will go to http://www.debian-ports.org/. If it
 has even more success, then probably it will go through the standard
 repository and be official part of Debian. Whatever happens, it will be
 interesting to see what kind of performance hit you get, and what kind
 of security enhancement there is.

Same comment as Thomas.
On your way you'll pretty much be required to implement
source-only/binary-drop uploads, which is a feature I want to see ;)

BTW, thanks to your post, I discovered that ld.so is capable of
searching in `hardware-specific` directory first.

Good luck,
-M


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+7wUswxGPYno0NO=y4sbA4WkLM=-5n7-we2a_dc1ar-bf_...@mail.gmail.com

Re: Proposing amd64-hardened architecture for Debian

[Steve Langasek]

On Wed, Apr 16, 2014 at 12:15:22AM +0800, Thomas Goirand wrote:
  My proposal for serving those security-focused users is introducing a
  new architecture targeting amd64 hardware, but with more security
  related C/C++ features turned on for every package (currently hardening
  has to be enabled by the maintainers in some way) through compiler flags
  as a start.

 My take on this: start it if you wish, and see how it takes you. If it
 is successful enough, it will go to http://www.debian-ports.org/. If it
 has even more success, then probably it will go through the standard
 repository and be official part of Debian. Whatever happens, it will be
 interesting to see what kind of performance hit you get, and what kind
 of security enhancement there is.

I would not presume that debian-ports.org would be willing to accept this
port without detailed discussion with Debian about what it means to provide
a different port with the same ABI.

The other recent notable port of this kind (changing the compiler defaults
without changing the ABI) is Raspbian, which we have not found a way to
effectively integrate into the Debian archive.  It lives in its own domain,
not under debian-ports, because it conflicts with and is unidirectionally
incompatible with the existing armhf port.

It would be great to see someone tackle the question of subarchs for dpkg,
which might be a fit here.  But I don't imagine that you're going to get
signoff on a dpkg amd64-secure architecture, so doing this in debian or on
debian-ports isn't very practical.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Proposing amd64-hardened architecture for Debian

[Jakub Wilk]

* Steve Langasek vor...@debian.org, 2014-04-15, 11:07:
But I don't imagine that you're going to get signoff on a dpkg 
amd64-secure architecture,


amd64-secure? Why not amd64-asbestos-free?

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140415184320.ga3...@jwilk.net