Mailing List Archive: Gentoo: Security

Stack smash protected daemons

Index | Next | Previous | View Threaded

nigelenki at comcast

Sep 22, 2004, 8:54 AM

Post #1 of 19 (1189 views)
Permalink

Stack smash protected daemons

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It may be prudent to use extra protection on certain ebuilds in standard
Gentoo profiles where the changes would be significant in the case of a
security fault in the program. Such programs as daemons and chmod()+s
programs would be major targets for this sort of thing.

The most immediately apparent route to take would be to have ebuilds
such as openssh, apache, and su stack smash protected. This would
prevent common buffer overflow attacks from being used to compromise
security; such attacks would only cause the program attacked to abort,
which could still be used as a Denial of Service attack, but would not
allow successful intrusion.

Gentoo ships gcc with stack smash protection built in. This is
activated by -fstack-protector or -fstack-protector-all. It would be
feasible to add one of these flags to an ebuild based on a FEATURES or
USE setting.

I believe it would be a good idea to have such a FEATURES or USE flag on
by default in all profiles where SSP is supported. In this manner, the
major targets of security attacks would automatically be protected;
while still allowing the user to disable the protection if the user
desires. Users wanting more protection can simply add -fstack-protector
to CFLAGS, or use Hardened Gentoo.

Any comments? Would this be more suitable as a USE or a FEATURES setting?

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBUaBOhDd4aOud5P8RAv/sAKCGx+cy5D3U35jDvGEFV5fcInF2fwCfbvGM
QvF8iaV8fuNFVQcintwy+2o=
=4Gdc
-----END PGP SIGNATURE-----

--
gentoo-security [at] gentoo mailing list

klausman at schwarzvogel

Sep 22, 2004, 11:46 AM

Post #2 of 19 (1167 views)
Permalink

Re: Stack smash protected daemons [In reply to]

Hi!

On Wed, 22 Sep 2004, John Richard Moser wrote:
> The most immediately apparent route to take would be to have ebuilds
> such as openssh, apache, and su stack smash protected. This would
> prevent common buffer overflow attacks from being used to compromise
> security; such attacks would only cause the program attacked to abort,
> which could still be used as a Denial of Service attack, but would not
> allow successful intrusion.

One might make a case for "this provides a (false) sense of
security". But I wouldn't think of this kind of view as feasible.
Using that argument, one could drop just about every security
measure that isn't perfect (and which is?).

> Gentoo ships gcc with stack smash protection built in. This is
> activated by -fstack-protector or -fstack-protector-all. It would be
> feasible to add one of these flags to an ebuild based on a FEATURES or
> USE setting.

Nice idea, I agree.

> I believe it would be a good idea to have such a FEATURES or USE flag on
> by default in all profiles where SSP is supported. In this manner, the
> major targets of security attacks would automatically be protected;
> while still allowing the user to disable the protection if the user
> desires. Users wanting more protection can simply add -fstack-protector
> to CFLAGS, or use Hardened Gentoo.
>
> Any comments? Would this be more suitable as a USE or a FEATURES setting?

I *think* it'd be better used as a USE flag for the "daemon-only"
approach. As for the "whole system" approach, I'd lean towards
FEATURE. But then I'm not well-versed in the policies regarding
those two settings/variables.

One problem (albeit small) I see is upstream maintainers refusing
to support users who use these settings with their software. A
similar example is the Mplayer team's stance towards
optimization. Usually, this could be solved the same way as in
the mplayer case (if the afflicted^Waffected maintainers aren't
too many).

Just my two eurocents,
Tobias
--
export DISPLAY=vt100

solar at gentoo

Sep 22, 2004, 4:49 PM

Post #3 of 19 (1169 views)
Permalink

Re: [gentoo-dev] Stack smash protected daemons [In reply to]

On Wed, 2004-09-22 at 11:54, John Richard Moser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> It may be prudent to use extra protection on certain ebuilds in standard
> Gentoo profiles where the changes would be significant in the case of a
> security fault in the program. Such programs as daemons and chmod()+s
> programs would be major targets for this sort of thing.
>
> The most immediately apparent route to take would be to have ebuilds
> such as openssh, apache, and su stack smash protected. This would
> prevent common buffer overflow attacks from being used to compromise
> security; such attacks would only cause the program attacked to abort,
> which could still be used as a Denial of Service attack, but would not
> allow successful intrusion.
>
> Gentoo ships gcc with stack smash protection built in. This is
> activated by -fstack-protector or -fstack-protector-all. It would be
> feasible to add one of these flags to an ebuild based on a FEATURES or
> USE setting.
>
> I believe it would be a good idea to have such a FEATURES or USE flag on
> by default in all profiles where SSP is supported. In this manner, the
> major targets of security attacks would automatically be protected;
> while still allowing the user to disable the protection if the user
> desires. Users wanting more protection can simply add -fstack-protector
> to CFLAGS, or use Hardened Gentoo.
>
> Any comments? Would this be more suitable as a USE or a FEATURES setting?

This would indeed significantly reduce impact of many existing security
problems that could potentially introduce and execute arbitrary code.

Yes this makes complete and total sense in the terms of what your saying
here. Vs using hardened which is not ideal for everybody or all
occasions(due to the other things it enables by default) to limit the
use of -fstack-protector to/for setuid/setgid and services only.

I fully support this idea for atleast all base system packages that fall
under the conditions you have defined, and assuming to many trolls don't
come out of the woodwork I would be willing start on it if you can make
a detailed list.

As far as a disable feature how about FEATURES="noautossp" ?

>
> - --
> All content of all messages exchanged herein are left in the
> Public Domain, unless otherwise explicitly stated.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFBUaBOhDd4aOud5P8RAv/sAKCGx+cy5D3U35jDvGEFV5fcInF2fwCfbvGM
> QvF8iaV8fuNFVQcintwy+2o=
> =4Gdc
> -----END PGP SIGNATURE-----
>
> --
> gentoo-dev [at] gentoo mailing list
--
Ned Ludd <solar [at] gentoo>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer

Attachments:

signature.asc (0.18 KB)

miguel.filipe at gmail

Sep 22, 2004, 8:00 PM

Post #4 of 19 (1169 views)
Permalink

Re: Re: [gentoo-dev] Stack smash protected daemons [In reply to]

I second this!!
I would love to see gentoo be more "proactive by default"...
sanboxing services whenever possible (like its done with dhcpd and bind)
priv-separation wherever doable, inclusively porting software from
openbsd, like their new dhcp server and clients and ntp server :)

I say this but don't "show code" simply because i'm not that
experienced to implement "safer" code,
nor to chroot a lot of software, nor am I capable of evaluate if such
service is chrootable :)

for instance, would there be any advantage in chrooting mysql? what
about tomcat?
is java code free from the dreadfull buffer overflow + shellcode?

So.. I support very dearly this idea..

greetings to all,
and thanks to all gentoo developers for gentoo :D

On Wed, 22 Sep 2004 19:49:42 -0400, Ned Ludd <solar [at] gentoo> wrote:
> On Wed, 2004-09-22 at 11:54, John Richard Moser wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > It may be prudent to use extra protection on certain ebuilds in standard
> > Gentoo profiles where the changes would be significant in the case of a
> > security fault in the program. Such programs as daemons and chmod()+s
> > programs would be major targets for this sort of thing.
> >
> > The most immediately apparent route to take would be to have ebuilds
> > such as openssh, apache, and su stack smash protected. This would
> > prevent common buffer overflow attacks from being used to compromise
> > security; such attacks would only cause the program attacked to abort,
> > which could still be used as a Denial of Service attack, but would not
> > allow successful intrusion.
> >
> > Gentoo ships gcc with stack smash protection built in. This is
> > activated by -fstack-protector or -fstack-protector-all. It would be
> > feasible to add one of these flags to an ebuild based on a FEATURES or
> > USE setting.
> >
> > I believe it would be a good idea to have such a FEATURES or USE flag on
> > by default in all profiles where SSP is supported. In this manner, the
> > major targets of security attacks would automatically be protected;
> > while still allowing the user to disable the protection if the user
> > desires. Users wanting more protection can simply add -fstack-protector
> > to CFLAGS, or use Hardened Gentoo.
> >
> > Any comments? Would this be more suitable as a USE or a FEATURES setting?
>
>
> This would indeed significantly reduce impact of many existing security
> problems that could potentially introduce and execute arbitrary code.
>
> Yes this makes complete and total sense in the terms of what your saying
> here. Vs using hardened which is not ideal for everybody or all
> occasions(due to the other things it enables by default) to limit the
> use of -fstack-protector to/for setuid/setgid and services only.
>
> I fully support this idea for atleast all base system packages that fall
> under the conditions you have defined, and assuming to many trolls don't
> come out of the woodwork I would be willing start on it if you can make
> a detailed list.
>
> As far as a disable feature how about FEATURES="noautossp" ?
>
> >
> > - --
> > All content of all messages exchanged herein are left in the
> > Public Domain, unless otherwise explicitly stated.
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.6 (GNU/Linux)
> > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> >
> > iD8DBQFBUaBOhDd4aOud5P8RAv/sAKCGx+cy5D3U35jDvGEFV5fcInF2fwCfbvGM
> > QvF8iaV8fuNFVQcintwy+2o=
> > =4Gdc
> > -----END PGP SIGNATURE-----
> >
> > --
> > gentoo-dev [at] gentoo mailing list
> --
> Ned Ludd <solar [at] gentoo>
> Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer
>
>
>
>

--
Miguel Sousa Filipe

--
gentoo-security [at] gentoo mailing list

nigelenki at comcast

Sep 22, 2004, 9:01 PM

Post #5 of 19 (1168 views)
Permalink

Re: [gentoo-dev] Stack smash protected daemons [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OK, there's too much arguing and not enough useful discussion going on
here. I suggest if you go through with this that you start with the
following in mind and build from there.

1. Protect daemons and chmod +s programs

For our purposes, let's define a daemon as any program which interacts
with (processes data from) non-root processes, including processes from
other machines. This would cover apache and ssh as well as anything
that happened to provide services to the local box through SysV IPC or
other mechanisms.

2. Use a FEATURES flag to implement

The FEATURES flag I've seen most suggested by persons other than me is
'autossp'. This flag should cause a portage command (such as
apply-autossp) to append -fstack-protector to CFLAGS. Optionally,
'autosspall' should apply -fstack-protector-all.

It's no secret that -fstack-protector-all breaks some programs that
- -fstack-protector doesn't (i.e. Firefox, Thunderbird, Mozilla). In case
of an 'autosspall' FEATURES flag and broken daemons, the 'apply-autossp
no-all' command could tell apply-autossp to use -fstack-protector and
NOT -fstack-protector-all.

3. Is this on by default?

It's believed by some of us, me included, to be sane to implement
'autossp' by default. Personally, I'm against -fstack-protector-all
('autosspall') by default; others may disagree. I do not have a strong
understanding of the difference between -fstack-protector and -all; I
know what they technically do, but not what the extra instrumentation
code generated with -all will actually gain you. Others know more than I.

Remember that if this is on by defaut, any user can add "-autossp" to
FEATURES in make.conf. If it's genuinely harmless (I believe it is),
there's really no point in making the user explicitely enable it.

- --
gentoo-dev [at] gentoo mailing list

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBUkqFhDd4aOud5P8RAgpqAJ9cUJczw09u8Fc2WxQwCn+1AVsy6QCfbhBK
lBcaH1OZfs+5OcZR6f2V9hE=
=1K/B
-----END PGP SIGNATURE-----

--
gentoo-security [at] gentoo mailing list

nigelenki at comcast

Sep 22, 2004, 9:06 PM

Post #6 of 19 (1169 views)
Permalink

Re: [gentoo-dev] Stack smash protected daemons [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Richard Moser wrote:
|

| 1. Protect daemons and chmod +s programs
|
| For our purposes, let's define a daemon as any program which interacts
| with (processes data from) non-root processes, including processes from
| other machines.

1. Strike "non-root processes"
2. Replace with "processes not owned by the same user upon request"

Sorry, how asinine of me to make such an elementary error in wording.
Many processes interact with another process owned by the user, mainly X.

The original wording also implied clients like web browsers. The "upon
request" clause makes it clear that we're dealing with daemons/servers.

|

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBUkvbhDd4aOud5P8RAqRJAJsHNp7f0nfGDUgx6zP6trXA0G+18ACfTL2P
qeFDDFTftWl6OgGjUDa9rg0=
=hoEH
-----END PGP SIGNATURE-----

--
gentoo-security [at] gentoo mailing list

trs-gml at simulakrum

Sep 22, 2004, 9:20 PM

Post #7 of 19 (1169 views)
Permalink

Re: OT: Re: [gentoo-dev] Stack smash protected daemons [In reply to]

John Richard Moser said:
[snip]
> It's no secret that -fstack-protector-all breaks some programs that
> - -fstack-protector doesn't (i.e. Firefox, Thunderbird, Mozilla). In case
> of an 'autosspall' FEATURES flag and broken daemons, the 'apply-autossp
> no-all' command could tell apply-autossp to use -fstack-protector and
> NOT -fstack-protector-all.
>

Just out of curiousity, does anyone know if using libsafe
(http://www.research.avayalabs.com/project/libsafe/) would tend to break
programs? I was just musing on the idea that if you were using libsafe,
you might be safe from some of the image exploits that are going around
now. Not that I am suggesting to use libsafe instead of upgrading
packages of course. Just in the unlikely event that there were an active
exploit against linux going around, it would be nice to know I had some
sort of extra protection.

I am already browsing from a junk user account just in case, as I would
hate to lose my documents and oggs and stuff, but I doubt that would help
much as I am sure any active exploit would likely trigger a local exploit
to get root permission anyway.

--
gentoo-security [at] gentoo mailing list

nigelenki at comcast

Sep 22, 2004, 9:22 PM

Post #8 of 19 (1171 views)
Permalink

Re: OT: Re: [gentoo-dev] Stack smash protected daemons [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

JHolder wrote:
| John Richard Moser said:
| [snip]
|
|>It's no secret that -fstack-protector-all breaks some programs that
|>- -fstack-protector doesn't (i.e. Firefox, Thunderbird, Mozilla). In case
|>of an 'autosspall' FEATURES flag and broken daemons, the 'apply-autossp
|>no-all' command could tell apply-autossp to use -fstack-protector and
|>NOT -fstack-protector-all.
|>
|
|
| Just out of curiousity, does anyone know if using libsafe
| (http://www.research.avayalabs.com/project/libsafe/) would tend to break
| programs?

According to http://www.trl.ibm.com/projects/security/ssp/node5.html ,
libsafe has greater overhead.

According to http://www.trl.ibm.com/projects/security/ssp/node4.html ,
libsafe does not protect local variable attacks (i.e. overflows that
succeed and damage local variables between the buffer and everything
else) and can't cover all string operations. Effectively, not as secure.

libsafe may be a nice fallback if you have programs that break with ssp;
although, in those cases, ssp normally tells you where they break, and
you go fix them.

| --
| gentoo-security [at] gentoo mailing list
|
|

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBUk95hDd4aOud5P8RAi9TAJ0QKwGE/03ovECAKW/XXglbPCTGgACfTO+/
OpiF9z0Ew+Envov7+sOY+Hk=
=qBXI
-----END PGP SIGNATURE-----

--
gentoo-security [at] gentoo mailing list

trs-gml at simulakrum

Sep 22, 2004, 9:47 PM

Post #9 of 19 (1167 views)
Permalink

Re: OT: Re: [gentoo-dev] Stack smash protected daemons [In reply to]

John Richard Moser said:
[snip]
> JHolder wrote:
> | John Richard Moser said:
> | [snip]
> |
> |>It's no secret that -fstack-protector-all breaks some programs that
> |>- -fstack-protector doesn't (i.e. Firefox, Thunderbird, Mozilla). In
[snip]
> |
> | Just out of curiousity, does anyone know if using libsafe
> | (http://www.research.avayalabs.com/project/libsafe/) would tend to break
> | programs?
>
> According to http://www.trl.ibm.com/projects/security/ssp/node5.html ,
> libsafe has greater overhead.
>

Good answer. Embarrassingly enough, your answer sounds like you spent 30
seconds with google. Something, which by all rights I should have done
myself. But as I am supposed to be working right now ;-) I appreciate
your time for doing the research on my odd musings.

John

--
gentoo-security [at] gentoo mailing list

solar at gentoo

Sep 22, 2004, 10:26 PM

Post #10 of 19 (1168 views)
Permalink

Re: [gentoo-dev] Stack smash protected daemons [In reply to]

On Thu, 2004-09-23 at 00:01, John Richard Moser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> OK, there's too much arguing and not enough useful discussion going on
> here. I suggest if you go through with this that you start with the
> following in mind and build from there.
>
> 1. Protect daemons and chmod +s programs
The wording on this could be a bit confusing for some. To make it clear
no additional apps are getting a +s bit. This proposal is apps that have
a setuid mode_t -4000 (going for setgid mote_t -2000 as well?) bit have
fstack-protector placed on them as a proactive security measure.

>
> For our purposes, let's define a daemon as any program which interacts
> with (processes data from) non-root processes, including processes from
> other machines. This would cover apache and ssh as well as anything
> that happened to provide services to the local box through SysV IPC or
> other mechanisms.
>
> 2. Use a FEATURES flag to implement
>
> The FEATURES flag I've seen most suggested by persons other than me is
> 'autossp'. This flag should cause a portage command (such as
> apply-autossp) to append -fstack-protector to CFLAGS. Optionally,
> 'autosspall' should apply -fstack-protector-all.
>
> It's no secret that -fstack-protector-all breaks some programs that
> - -fstack-protector doesn't (i.e. Firefox, Thunderbird, Mozilla). In case
> of an 'autosspall' FEATURES flag and broken daemons, the 'apply-autossp
> no-all' command could tell apply-autossp to use -fstack-protector and
> NOT -fstack-protector-all.
>
> 3. Is this on by default?
> It's believed by some of us, me included, to be sane to implement
> 'autossp' by default. Personally, I'm against -fstack-protector-all
> ('autosspall') by default; others may disagree. I do not have a strong
> understanding of the difference between -fstack-protector and -all; I
> know what they technically do, but not what the extra instrumentation
> code generated with -all will actually gain you. Others know more than I.
>
> Remember that if this is on by defaut, any user can add "-autossp" to
> FEATURES in make.conf. If it's genuinely harmless (I believe it is),
> there's really no point in making the user explicitely enable it.

I'll vote YES on -fstack-protector an NO on the -fstack-protector-all by
default for the conditions you have outlined.

ebuilds such as xfree which have problems right now due to improper
handling of ELF will restrict it's use with RESTRICT="autossp" or just
not make use it.

No profile will need to contain FEATURES=autossp (it's assumed by
default)

The ebuild logic should/will work as follows.

inherit flag-o-matic

src_unpack() {
unpack ${A}
...
hasq autossp ${RESTRICT} || append-flags -fstack-protector
...
}

SpanKY this sound about right?

>
> - --
> gentoo-dev [at] gentoo mailing list
>
>
>
> - --
> All content of all messages exchanged herein are left in the
> Public Domain, unless otherwise explicitly stated.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFBUkqFhDd4aOud5P8RAgpqAJ9cUJczw09u8Fc2WxQwCn+1AVsy6QCfbhBK
> lBcaH1OZfs+5OcZR6f2V9hE=
> =1K/B
> -----END PGP SIGNATURE-----
>
> --
> gentoo-dev [at] gentoo mailing list
--
Ned Ludd <solar [at] gentoo>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer

Attachments:

signature.asc (0.18 KB)

nigelenki at comcast

Sep 22, 2004, 10:31 PM

Post #11 of 19 (1173 views)
Permalink

Re: OT: Re: [gentoo-dev] Stack smash protected daemons [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

JHolder wrote:
| John Richard Moser said:
| [snip]
|
|>JHolder wrote:
|>| John Richard Moser said:
|>| [snip]
|>|
|>|>It's no secret that -fstack-protector-all breaks some programs that
|>|>- -fstack-protector doesn't (i.e. Firefox, Thunderbird, Mozilla). In
|
| [snip]
|
|>|
|>| Just out of curiousity, does anyone know if using libsafe
|>| (http://www.research.avayalabs.com/project/libsafe/) would tend to break
|>| programs?
|>
|>According to http://www.trl.ibm.com/projects/security/ssp/node5.html ,
|>libsafe has greater overhead.
|>
|
|
| Good answer. Embarrassingly enough, your answer sounds like you spent 30
| seconds with google. Something, which by all rights I should have done
| myself. But as I am supposed to be working right now ;-) I appreciate
| your time for doing the research on my odd musings.
|

I came accross this stuff a while back, I had 'em on hand.

Found 'em with google after 4 or 5 searches trying to determine how the
heck old SSP was.

| John
|
| --
| gentoo-security [at] gentoo mailing list
|
|

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBUl+rhDd4aOud5P8RAqWwAJ9boVfdlXPLvOBwnJdeVBsuN97ysQCeIA8G
3SMVo/yU8JAvc66V3x9EhUs=
=3z4S
-----END PGP SIGNATURE-----

--
gentoo-security [at] gentoo mailing list

koon at gentoo

Sep 23, 2004, 1:31 AM

Post #12 of 19 (1173 views)
Permalink

Re: Stack smash protected daemons [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Small data analysis based on August/September GLSAs :

55 GLSAs
21 of which are buffer overflows (38%)
5 are buffer overflows affecting daemons (9%)
14 are buffer overflows affecting client software (25%)
2 can potentially affect both servers and clients (4%)

So almost one third of our current vulnerabilities are buffer overflows
affecting client software. These require the attacker to make you
load/read/open a malicious document/image/playlist. It's not because we
haven't seen much viruses for Linux that we shouldn't worry about this
attack vector. Restricting ssp to daemons and +s programs is not very
useful. A client-based vulnerability can be used together with a recent
root escalation kernel vuln to compromise a machine completely. Weakest
link.

- --
Koon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBUonOvcL1obalX08RArGJAKCShMubWvGlGqHLW/CFMZfHCz6q8ACgifMc
LCX6C/NkPGumUILK4idOG6E=
=yJgM
-----END PGP SIGNATURE-----

--
gentoo-security [at] gentoo mailing list

koon at gentoo

Sep 23, 2004, 7:05 AM

Post #13 of 19 (1168 views)
Permalink

Re: Stack smash protected daemons [In reply to]

Thierry Carrez wrote:

> Restricting ssp to daemons and +s programs is not very
> useful.

Clarifying this :

SSP is very useful, and it should be used on all executables on a given
machine. I don't think we should only use it to protect daemons and SUID
programs, since a lot of buffer overflows are discovered in client
software and they are also a way of remotely compromising a machine. If
you protect only exposed services, attackers will turn to passive
attacks, like virus images, to always exploit the weakest link.

-K

--
gentoo-security [at] gentoo mailing list

BarrySchwartz124 at comcast

Sep 23, 2004, 8:37 AM

Post #14 of 19 (1167 views)
Permalink

Re: OT: Re: [gentoo-dev] Stack smash protected daemons [In reply to]

JHolder <trs-gml [at] simulakrum> wrote:
> Just out of curiousity, does anyone know if using libsafe
> (http://www.research.avayalabs.com/project/libsafe/) would tend to break
> programs?

There's a better reason, however, not to use libsafe than just any
technical inferiority: libsafe currently is tied to an architecture.
It works fine on x86, but not on amd64 or probably anything else.

--
gentoo-security [at] gentoo mailing list

nigelenki at comcast

Sep 23, 2004, 10:27 AM

Post #15 of 19 (1168 views)
Permalink

Re: Re: Stack smash protected daemons [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thierry Carrez wrote:
| Small data analysis based on August/September GLSAs :
|
| 55 GLSAs
| 21 of which are buffer overflows (38%)
| 5 are buffer overflows affecting daemons (9%)
| 14 are buffer overflows affecting client software (25%)
| 2 can potentially affect both servers and clients (4%)
|
| So almost one third of our current vulnerabilities are buffer overflows
| affecting client software. These require the attacker to make you
| load/read/open a malicious document/image/playlist.

Yeah, mozilla/libpng vulns, etc.

| It's not because we
| haven't seen much viruses for Linux that we shouldn't worry about this
| attack vector.

They'll catch up when Linux takes over the market. I don't think we
should "cross that bridge when we come to it;" I think we should be
ready for it.

| Restricting ssp to daemons and +s programs is not very
| useful. A client-based vulnerability can be used together with a recent
| root escalation kernel vuln to compromise a machine completely. Weakest
| link.
|

Hey, if you want to protect client programs i.e. Mozilla, gftp,
gtk-gnutell, xchat. . . . . GO FOR IT. These aren't high-intensity
tasks; they eat about 1% of CPU time >99% of the time, and occasionally
spike to something like 50%, maybe touch 100% for about 10mS at a time.
~ Nobody's going to notice.

On this note though, if you follow the logic through, you wind up
protecting every lib too eventually; what about libpng and libjpeg vulns
that can be used to exploit generic apps (mozilla again, but this time
not moz's fault so protecting moz does nothing)? This is why I say to
suggest -fstack-protector in make.conf in the comments just above CFLAGS
as well.

Where do we find things that we just don't care about? gcc maybe; wtf
do you do to exploit a compiler? But glibc? Everything uses glibc, if
there's a vuln then everything is vulnerable. Libncurses, libpng, gif
libraries, all used by web browsers.

A safer (from a security point of view) venue may be to allow users to
add CFLAGS="-fstack-protector" and FEATURES="autonossp" (notice the
'no') to have things determined to not need SSP have it removed.
Selecting things to protect means you have to be active and aggressive
in finding those programs and libs which would be potential targets;
selecting things that just obviously shouldn't or wouldn't need
protection can be done passively, because it's not a security concern to
protect an app that doesn't need it (only an overhead or performance
concern, depending on app).

The 'autonossp' and 'autossp' venues can coexist; anything that gets ssp
with 'autossp' should not be stripped of it with 'autonossp'. It's up
to you to decide if you want to implement one or both, and which should
be focused on more in the case of both.

| --
| Koon

- --
gentoo-security [at] gentoo mailing list

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBUweDhDd4aOud5P8RAoC0AJ9kqf/cBy8eXJCDeu11fDYqnUNt4ACeL6+Z
tkRwGUwkCUkaV7/fGUWUPbA=
=AUoQ
-----END PGP SIGNATURE-----

--
gentoo-security [at] gentoo mailing list

nigelenki at comcast

Sep 23, 2004, 8:21 PM

Post #16 of 19 (1168 views)
Permalink

Re: [gentoo-dev] Re: Stack smash protected daemons [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm probably repeting myself here . . .heh.

Thierry Carrez wrote:
| Thierry Carrez wrote:
|
|
|>Restricting ssp to daemons and +s programs is not very
|>useful.
|
|
| Clarifying this :
|
| SSP is very useful, and it should be used on all executables on a given
| machine. I don't think we should only use it to protect daemons and SUID
| programs, since a lot of buffer overflows are discovered in client
| software and they are also a way of remotely compromising a machine. If
| you protect only exposed services, attackers will turn to passive
| attacks, like virus images, to always exploit the weakest link.
|

How about, make.conf default and make.conf.example:

#
# The "auto-nossp" USE flag will disable -fstack-protector on ebuilds
# that take a significant hit from SSP and aren't a major security
# threat. Ebuilds that break with SSP will have SSP disabled in all
# cases anyway.
#USE="X"
...
#
# For added security, the -fstack-protector flag can be added to prevent
# buffer overflow based attacks. -fno-stack-protector will disable this
# universally; nothing forces it on.
#
# Decent examples:
#CFLAGS="-march=i686 -O2 -pipe -fstack-protector"
#CFLAGS="-mcpu=pentium4 -O3 -pipe -fstack-protector"

This solution may have extra perks. As you said, more than just daemon
software is affected. Rather than tracking it all down, perhaps simply
looking for not-always-great-for-SSP things such as gcc (can you attack
gcc anyway? No really, I want to know) and have a USE flag disable SSP
for them.

Another reason for this route would be that using -fno-stack-protector
in CFLAGS would be overriden by builds explicitely enabling
- -fstack-protector. Using -fstack-protector in CFLAGS would be overriden
by ebuilds explicitely setting -fno-stack-protector. The logical
consequences of each (i.e. when -fstack would and wouldn't be applied
based on combinations of the user and portage enabling/disabling it) in
my eyes seem better with this approach.

It all depends on if you want fine control of programs which have SSP,
or fine control of programs which don't have SSP. This solution would
be the latter, and I think it makes more sense than the original
proposal; a wider spread usage of SSP is probably the only way to ensure
the best protection.

Comments?

| -K
|
| --
| gentoo-dev [at] gentoo mailing list
|
|

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBU5K8hDd4aOud5P8RAo08AJ4xNx6IkHDjDhQX43sfKNiNJmz10wCfbrM7
eI5ZweX0wl8uG7l0vH3Z+YI=
=C/8F
-----END PGP SIGNATURE-----

--
gentoo-security [at] gentoo mailing list

solar at gentoo

Sep 23, 2004, 11:02 PM

Post #17 of 19 (1167 views)
Permalink

Re: [gentoo-dev] Re: Stack smash protected daemons [In reply to]

dammit are we over complicating this?
You guys seem to be hung up on silly USE/FEATURE flag names.
How about we as Ciaran McCreesh proposed just add it to CFLAGS by
default and deploy stages in such a manner.
Solves everything for most cases and leave the option up to the user to
disable if he/she wants to.

On Thu, 2004-09-23 at 23:21, John Richard Moser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm probably repeting myself here . . .heh.
>
> Thierry Carrez wrote:
> | Thierry Carrez wrote:
> |
> |
> |>Restricting ssp to daemons and +s programs is not very
> |>useful.
> |
> |
> | Clarifying this :
> |
> | SSP is very useful, and it should be used on all executables on a given
> | machine. I don't think we should only use it to protect daemons and SUID
> | programs, since a lot of buffer overflows are discovered in client
> | software and they are also a way of remotely compromising a machine. If
> | you protect only exposed services, attackers will turn to passive
> | attacks, like virus images, to always exploit the weakest link.
> |
>
> How about, make.conf default and make.conf.example:
>
> #
> # The "auto-nossp" USE flag will disable -fstack-protector on ebuilds
> # that take a significant hit from SSP and aren't a major security
> # threat. Ebuilds that break with SSP will have SSP disabled in all
> # cases anyway.
> #USE="X"
> ...
> #
> # For added security, the -fstack-protector flag can be added to prevent
> # buffer overflow based attacks. -fno-stack-protector will disable this
> # universally; nothing forces it on.
> #
> # Decent examples:
> #CFLAGS="-march=i686 -O2 -pipe -fstack-protector"
> #CFLAGS="-mcpu=pentium4 -O3 -pipe -fstack-protector"
>
>
> This solution may have extra perks. As you said, more than just daemon
> software is affected. Rather than tracking it all down, perhaps simply
> looking for not-always-great-for-SSP things such as gcc (can you attack
> gcc anyway? No really, I want to know) and have a USE flag disable SSP
> for them.
>
> Another reason for this route would be that using -fno-stack-protector
> in CFLAGS would be overriden by builds explicitely enabling
> - -fstack-protector. Using -fstack-protector in CFLAGS would be overriden
> by ebuilds explicitely setting -fno-stack-protector. The logical
> consequences of each (i.e. when -fstack would and wouldn't be applied
> based on combinations of the user and portage enabling/disabling it) in
> my eyes seem better with this approach.
>
> It all depends on if you want fine control of programs which have SSP,
> or fine control of programs which don't have SSP. This solution would
> be the latter, and I think it makes more sense than the original
> proposal; a wider spread usage of SSP is probably the only way to ensure
> the best protection.
>
> Comments?
>
> | -K
> |
> | --
> | gentoo-dev [at] gentoo mailing list
> |
> |
>
> - --
> All content of all messages exchanged herein are left in the
> Public Domain, unless otherwise explicitly stated.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFBU5K8hDd4aOud5P8RAo08AJ4xNx6IkHDjDhQX43sfKNiNJmz10wCfbrM7
> eI5ZweX0wl8uG7l0vH3Z+YI=
> =C/8F
> -----END PGP SIGNATURE-----
>
> --
> gentoo-dev [at] gentoo mailing list
--
Ned Ludd <solar [at] gentoo>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer

Attachments:

signature.asc (0.18 KB)

nigelenki at comcast

Sep 23, 2004, 11:34 PM

Post #18 of 19 (1172 views)
Permalink

Re: [gentoo-dev] Re: Stack smash protected daemons [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ned Ludd wrote:
| dammit are we over complicating this?
| You guys seem to be hung up on silly USE/FEATURE flag names.
| How about we as Ciaran McCreesh proposed just add it to CFLAGS by
| default and deploy stages in such a manner.
| Solves everything for most cases and leave the option up to the user to
| disable if he/she wants to.
|

Fine by me. Not that my opinion matters, mind you *points to the domain
his e-mail comes from, distinctly NOT @gentoo.org* :)

[...]

- --
gentoo-dev [at] gentoo mailing list

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBU7/rhDd4aOud5P8RAjIgAJ9LjQmc35PsUFiBntwE6981UFEh9wCfSL6N
2RHyBB7Pi1LM/H6Y/JXkmIs=
=GdJl
-----END PGP SIGNATURE-----

--
gentoo-security [at] gentoo mailing list

nigelenki at comcast

Sep 26, 2004, 11:39 AM

Post #19 of 19 (1170 views)
Permalink

Re: [gentoo-dev] Stack smash protected daemons [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

TIME TO KILL THIS THREAD.

~ - Some people think SSP goes everywhere
~ - Some people think SSP is an ugly hack that shouldn't be used
~ - Some people think users don't want SSP
~ - Some people think users don't know about SSP and need education
~ - Some people want to poll the userbase

I HAVE REACHED A SOLUTION.

Phase 1: Documentation

On the advice of multiple contributers to this thread, Gentoo should
give brief documentation about SSP in the install guide. This would
bring SSP to users' attention and allow them to decide if they want to
Stage 1 + SSP their system, rather than Stage 2 or 3 or normal Stage 1.

Such documentation should contain external links to pages about SSP,
such as the white paper[1] and the main site[2]; or to the Hardened
Gentoo[3] page or documentation on there.

[1] http://www.trl.ibm.com/projects/security/ssp/main.html
[2] http://www.trl.ibm.com/projects/security/ssp/
[3] http://hardened.gentoo.org/

Brief documentation about SSP may be added to make.conf to get the
information to current users who won't read the install guide over
again. It may also be flashed on screen using 'einfo' after upgrading
portage for the next few stable versions; such a message would direct
the user to check out the comments in make.conf.example about CFLAGS and
- -fstack-protector. This message would of course later be removed when
enough of the user base has seen it.

Phase 2: Gather Information

If SSP becomes popular, then a lot of users will be compiling from Stage
1. Because SSP is off by default, Stage 2 and 3 will not be protected.

The Gentoo developers would need to find out if most users on given
archs were using and satisfied with SSP. It would also be important to
know if these users were using Stage 1 instead of 2 or 3 for this reason.

When polling users, remember that NEUTRALS DO NOT COUNT. If you have 20
people who don't want SSP, 20 that want it, and 400 that don't care, you
have a 50/50 split. Similarly, if you have 35 that want SSP, 5 that
don't, and 400 that don't care, you have only 1/8 objection and 7/8 for.
~ It works the other way too.

Phase 3: Deployment

If the information gathered in (Phase 2) displays that a significant
portion of the user base uses SSP, and especially if they forego Stage 2
or 3 in favor of Stage 1 just for SSP, then steps to enhance deployment
should be taken. Stage 2 and 3 tarballs should be released with
- -fstack-protector in CFLAGS, and with all contained, pre-built programs
compiled -fstack-protector.

Non-SSP stages may or may not be phased out eventually if this happens.
~ If this process evolves Gentoo into a state where it is acknowledged
that most non-neutral users want SSP, then the non-ssp stages will
vanish, and GRP packages may possibly become SSP-enabled as well.

If the facts show that most people are dissatisfied with or flat out
against SSP, then (Phase 3) will never occur.

Phase 3 is essentially "giving the users what they want" based on Phase
2 ("finding out what the users want"). It's justified because users can
still go without SSP if you do this, but it'd be more difficult. You
make it *easier* for *most* users to get what they want, but leave it
*possible* for the minority to change it back. Which is which is to be
determined.

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBVwz2hDd4aOud5P8RArKxAJ448lt0j1zL+m0UP++aecvLOXCVZwCgkPT0
tPzF+IuxqDOsnwB+/r0ac9E=
=dVlM
-----END PGP SIGNATURE-----

--
gentoo-security [at] gentoo mailing list

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads