Re: [Cooker] ProPolice stack protection for next Mandrake release?
Vincent Danen [EMAIL PROTECTED] writes:
Something like StackGuard+FormatGuard (from Immunix although I think
they're quite out-dated) would be good (cover buffer overflows and
format string vulns all at the same time).
the later should be covered if one check compiler output with modern
gcc.
i once again promote pixel install deps, build it, check it and offer
to upload it script that filter output and only output stderr thus
highlighting gcc warnings:
#!/usr/bin/perl
use MDK::Common;
use POSIX;
my $rpm = rpm --nosignature;
my $rpmdir = chomp_(`rpm --eval '%_topdir'`);
my $tmppath = chomp_(`rpm --eval '%_tmppath'`);
s|/$|| foreach $rpmdir, $tmppath;
if ($0 =~ /isrpms/i) {
@ARGV == 1 or die isrpms package name\n;
my $srpm = previous_pkg('SRPMS', $ARGV[0]);
print installing $srpm\n;
system(rpm -i $srpm);
my $name = pkg_info($srpm)-{name};
chdir $rpmdir/SPECS;
-e $name.spec or die bad spec file name, missing $name.spec\n;
system(emacsclient --no-wait $name.spec 2/dev/null);
} elsif ($0 =~ /compare/i) {
@ARGV or die Compare_package_files rpm file\n;
foreach (@ARGV) {
my $info = pkg_info($_);
my $previous = previous_pkg('RPMS', $info-{name});
compare_package_files($info, $previous);
}
} else {
goto upload;
}
exit 0;
upload:
my $short_circuit = $ARGV[0] eq '--short-circuit' shift(@ARGV);
my ($q_spec) = @ARGV;
if ($q_spec =~ /\.src\.rpm$/) {
system(rpm, -i, $q_spec) == 0 or die bad srpm $q_spec\n;
($q_spec) = `$rpm -qpl $q_spec` =~ /(.*)\.spec$/m or internal_error(missing
spec);
}
-e $q_spec or $q_spec = $rpmdir/SPECS/$q_spec.spec;
-e $q_spec @ARGV == 1 or die Upload spec file\n;
my $spec = basename($q_spec);
my $buildlog = $tmppath/.upload-$spec;
$| = 1;
system(chmod, 644, $q_spec, grep { -f $_ } glob_($rpmdir/SOURCES/*));
if (system(rpmbuild -bs $q_spec $buildlog) != 0) {
system(rpmbuild -bs $q_spec /dev/null 2 $buildlog);
if (my @deps_needed = cat_($buildlog) =~ /^\s+(\S+)\s+.*is needed by/gm) {
foreach (@deps_needed) {
system(sudo ue -u $_);
system(sudo ue -c $_);
}
warn Waiting for @deps_needed to be installed\n;
sleep 120;
}
if (my @deps_conflict = cat_($buildlog) =~ /^\s+(\S+)\s+.*conflicts with/gm) {
@deps_conflict = map { chomp_(`rpm -q --whatprovides --qf '%{name}\n' $_`) }
@deps_conflict;
print STDERR There are conflicting packages.\nRemove packages @deps_conflict
(Y/n) ?;
STDIN !~ /n/i or exit 0;
system(sudo ue -e $_) foreach @deps_conflict;
warn Waiting for @deps_conflict to be removed\n;
sleep 120;
}
system(rpmbuild -bs $q_spec $buildlog) == 0 or die rpmbuild -bs $spec
failed\n;
}
my ($srpm) = map { if_(/^Wrote: (.*)/, $1) } cat_($buildlog);
my $info = pkg_info($srpm);
my $previous_srpm = eval { previous_pkg('SRPMS', $info-{name},
$info-{name}-$info-{version}) };
my $previous = $previous_srpm pkg_info($previous_srpm);
my $cooker_or_contrib;
if ($previous_srpm) {
$info-{version} eq $previous-{version} $info-{release} eq
$previous-{release}
and die ERROR: package $info-{name} already exists in cooker
($previous_srpm)\ndid you increase the release number?\n;
if ($previous_srpm =~ m|mandrake/uploads|) {
print package $info-{name} is already in the upload queue
($previous_srpm)\n;
print continue anyway (y/N)? ;
STDIN =~ /^y/i or exit 1;
}
$cooker_or_contrib = $previous_srpm =~ m|contrib/| ? 'contrib' : 'cooker';
}
while (!$cooker_or_contrib) {
print($previous_srpm ? Weird, $info-{name} is both in contrib and main :
$info-{name} is neither in contrib nor main);
print , what do you choose (contrib/cooker)? ;
my $r = STDIN;
$cooker_or_contrib = 'contrib' if $r =~ /con/i;
$cooker_or_contrib = 'cooker' if $r =~ /coo/i;
$cooker_or_contrib or print qq(Bad answer, please type cooker or contrib\n);
};
if ($short_circuit) {
print installing...\n;
system(rpmbuild -bi --short-circuit $q_spec $buildlog) == 0 or die rpmbuild
-bi --short-circuit $spec failed\n;
system(rpmbuild -bb --short-circuit $q_spec $buildlog) == 0 or die rpmbuild
-bb --short-circuit $spec failed\n;
} else {
print building...\n;
system(rpmbuild -bb $q_spec $buildlog) == 0 or die rpmbuild -bb $spec
failed\n;
}
my @rpms = map { pkg_info($_) } map { if_(/^Wrote: (.*)/, $1) } cat_($buildlog);
if ($previous_srpm) {
@rpms = compare_package_files($previous, @rpms);
compare_package_requires($previous, @rpms);
compare_package_provides($previous, @rpms);
} else {
if (any { $_-{name} =~ /-debug$/ } @rpms) {
print Do you want to upload $info-{name}-debug (the debug version) (y/N)? ;
if (STDIN !~ /^y/i) {
@rpms = grep { $_-{name} !~ /-debug$/ } @rpms;
}
}
}
{
my $rpms = join( , map { $_-{file} } @rpms);
if (my $s = `rpmlint $srpm $rpms`) {
print
Re: [Cooker] ProPolice stack protection for next Mandrake release?
Aleksander Adamowski ha scritto: Giuseppe Ghibò wrote: I would add also perl, php and python to the list and would remove other non-server and non-suid client applications, otherwise better to apply stack protection to everything... Added. I've built our gcc RPM with stackprotector enabled some months ago (latest were gcc-3.3-2mdk(s) for cooker, and gcc-3.2.2-3mdk(s) for 9.1). IMHO what this could replace is the %serverbuild macro, which should have -fstack-protector enabled. I don't know that macro, that's interesting. You could add this idea to the Wiki page. if I remember right such macro just avoid omitting frame pointer for getting libsafe working. From benchmark (ssbench) I don't see any appreciable slow down, but it would be interesting to see some BIG benchmark for instance to Apache or some mailer, to see the effective impact. If someone has one or is willing to do some intensive benchmark... See this page: http://www.trl.ibm.com/projects/security/ssp/node5.html#SECTION00051000 They state that in worst case it can add 8% performance loss. Worst case being a program that uses massive amounts of function calls, with extremely short function bodies. In practice, it's been shown to not exceed 4% with the Perl benchmark, and be close to 0% for imapd. Honestly I would trust to benchmark made myself, or at least reproducibile, otherwise is like considering only BOGOMIPS... ;-) As I said on a quick benchmark with ssbench I get results even more optmistic, but would be better to do test on the real word and on INTENSIVE tasks (e.g. some WebBench for apache, or for instance some mailer with amavis + spamassassin [etc.]). Also consider that in most cases servers could be tweaked in kernel parameters to achieve even 50% better performance (e.g. tuning parameters in sysctl.conf), so IMHO a 5% loss is not that dramatic (at least for servers). Bye. Giuseppe.
Re: [Cooker] ProPolice stack protection for next Mandrake release?
Aleksander Adamowski ha scritto: Giuseppe Ghibò wrote: I would add also perl, php and python to the list and would remove other non-server and non-suid client applications, otherwise better to apply stack protection to everything... Notice that the list is in _decreasing order of importance_ (or network exposure and risks). I'm proposing to settle on a threshold, e.g. We only rebuild servers that run as root and the libraries they use. BTW, your suggestions are very constructive, create an account on Wiki and ask Warly for the password, then feel free to add your ideas to that topic on Wiki. Honestly right now I don't have much time to do that, as I'm very busy with my packages before next 9.2RC1... Bye. Giuseppe.
Re: [Cooker] ProPolice stack protection for next Mandrake release?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Giuseppe Ghibò wrote: Honestly I would trust to benchmark made myself, or at least reproducibile, otherwise is like considering only BOGOMIPS... ;-) As I said on a quick benchmark with ssbench I get results even more optmistic, but would be better to do test on the real word and on INTENSIVE tasks (e.g. some WebBench for apache, or for instance some mailer with amavis + spamassassin [etc.]). Hmmm, yes, I have also been meaning to benchmark samba again, either with Netbench, or with the stuff in the samba3-test package. Also consider that in most cases servers could be tweaked in kernel parameters to achieve even 50% better performance (e.g. tuning parameters in sysctl.conf), so IMHO a 5% loss is not that dramatic (at least for servers). Note that the preformance difference between win2k and win2k3 server is quoted as 10%, currently samba3 is faster than win2k and slower than win2k3, which means 5% may just make us slower than win2k ... Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/Q+n6rJK6UGDSBKcRAighAKCox0Ttg0lMX5XdroRaa2P00syskgCfae7n DgdcFkvf3PNuBHf8+XEUNAQ= =BAr3 -END PGP SIGNATURE- * Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. *
Re: [Cooker] ProPolice stack protection for next Mandrake release?
Han Boetes ha scritto: Aleksander Adamowski [EMAIL PROTECTED] wrote: How about adding ProPolice stack protection to stock Mandrake GCC? For discussion, see this Mandrake Wiki topic: http://qa.mandrakesoft.com/twiki/bin/view/Main/ProPolice OpenBSD already did that. I would add also perl, php and python to the list and would remove other non-server and non-suid client applications, otherwise better to apply stack protection to everything... If not enabled by default this is a great idea. And then lets get W^X as well ;) # Han I've built our gcc RPM with stackprotector enabled some months ago (latest were gcc-3.3-2mdk(s) for cooker, and gcc-3.2.2-3mdk(s) for 9.1). IMHO what this could replace is the %serverbuild macro, which should have -fstack-protector enabled. From benchmark (ssbench) I don't see any appreciable slow down, but it would be interesting to see some BIG benchmark for instance to Apache or some mailer, to see the effective impact. If someone has one or is willing to do some intensive benchmark... Bye. Giuseppe. Also we have to be sure, that such patch doesn't have side effect on applications. For instance I've heard that mozilla as well as XFree86 weren't compiling/working with stack-protector enabled.
Re: [Cooker] ProPolice stack protection for next Mandrake release?
Michael Scherer ha scritto: On Sunday 17 August 2003 17:47, Aleksander Adamowski wrote: How about adding ProPolice stack protection to stock Mandrake GCC? For discussion, see this Mandrake Wiki topic: http://qa.mandrakesoft.com/twiki/bin/view/Main/ProPolice OpenBSD already did that. having the patch would be nice, but not applied as default. An alternative would be to have a parallel protected build of all the applications (e.g. with RPM named mdks instead of mdk) and let users (or installer) decide to which level install the protected one (e.g. level5 install stack protected RPM version only for the running daemons, level10 install the stack protected RPM version for everything). we already have libsafe for a runtime protection, which is more flexible than compile time protection. The problem is that libsafe doesn't cover all the functions, but just a subset of common one where buffer overrun could occur (and note that %serverbuild macro in our RPM was introduced for libsafe). For instance in the case of the zlib exploit, libsafe wouldn't have it catched, while if it would have been compiled with -fstack-protector, the exploit would have been blocked (and logged). in fact with the patch, you only would need to rebuild and change the .rpmmacro files of the user who is used to build. Bye. Giuseppe.
Re: [Cooker] ProPolice stack protection for next Mandrake release?
Giuseppe Ghibò wrote: I would add also perl, php and python to the list and would remove other non-server and non-suid client applications, otherwise better to apply stack protection to everything... Added. I've built our gcc RPM with stackprotector enabled some months ago (latest were gcc-3.3-2mdk(s) for cooker, and gcc-3.2.2-3mdk(s) for 9.1). IMHO what this could replace is the %serverbuild macro, which should have -fstack-protector enabled. I don't know that macro, that's interesting. You could add this idea to the Wiki page. From benchmark (ssbench) I don't see any appreciable slow down, but it would be interesting to see some BIG benchmark for instance to Apache or some mailer, to see the effective impact. If someone has one or is willing to do some intensive benchmark... See this page: http://www.trl.ibm.com/projects/security/ssp/node5.html#SECTION00051000 They state that in worst case it can add 8% performance loss. Worst case being a program that uses massive amounts of function calls, with extremely short function bodies. In practice, it's been shown to not exceed 4% with the Perl benchmark, and be close to 0% for imapd. -- Aleksander Adamowski Jabber JID (to nie e-mail!): [EMAIL PROTECTED] GG#: 274614 ICQ UIN: 19780575 http://olo.office.altkom.com.pl
Re: [Cooker] ProPolice stack protection for next Mandrake release?
Giuseppe Ghibò wrote: I would add also perl, php and python to the list and would remove other non-server and non-suid client applications, otherwise better to apply stack protection to everything... Notice that the list is in _decreasing order of importance_ (or network exposure and risks). I'm proposing to settle on a threshold, e.g. We only rebuild servers that run as root and the libraries they use. BTW, your suggestions are very constructive, create an account on Wiki and ask Warly for the password, then feel free to add your ideas to that topic on Wiki. -- Aleksander Adamowski Jabber JID (to nie e-mail!): [EMAIL PROTECTED] GG#: 274614 ICQ UIN: 19780575 http://olo.office.altkom.com.pl
Re: [Cooker] ProPolice stack protection for next Mandrake release?
Giuseppe Ghibò [EMAIL PROTECTED] wrote: IMHO what this could replace is the %serverbuild macro, which should have -fstack-protector enabled. Not a bad idea at all. Perhaps other security sensetive software as well. Like for example suid stuff ( cdrecord ) From benchmark (ssbench) I don't see any appreciable slow down, but it would be interesting to see some BIG benchmark for instance to Apache or some mailer, to see the effective impact. If someone has one or is willing to do some intensive benchmark... On OpenBSD they found something like about 5%. And the whole OS except for some ports/packages that don't like it is build with stackprotector. Also we have to be sure, that such patch doesn't have side effect on applications. For instance I've heard that mozilla as well as XFree86 weren't compiling/working with stack-protector enabled. /usr/ports% grep stack-protector **/Makefile cad/klogic/Makefile:CFLAGS+=-fno-stack-protector www/mozilla-firebird/Makefile:CFLAGS+= -fno-stack-protector www/mozilla/Makefile:CFLAGS+= -fno-stack-protector It's not that dramatic :) # Han -- http://www.xs4all.nl/~hanb/software http://www.xs4all.nl/~hanb/documents/quotingguide.html
Re: [Cooker] ProPolice stack protection for next Mandrake release?
On 08.17, Aleksander Adamowski wrote: How about adding ProPolice stack protection to stock Mandrake GCC? I hope not. I don't see the point of slowing down all the system (you have to rebuild glibc, the kernel at least) just to protect against buffer overflows. Buffer overflows are porpular in windows because it is damned open, outlook executes automagically even a pig if it comes in an e-mail, administrators tend to give admin permissions to everybody because of badly designed apps (I have seen Photoshop not working because it wanted to write at C:\, and us, poor Unix admins, had made it read-only), and so on. In linux, you can do 2 things: - shoot yourself on the feet, so you just break your own account. - try to get root first, to make something useful with a buffer overflow. And how about things written in other languages ? For example, in C++ you are not allowed to reorder the stack. Even more, you do not know the size the stack will grow to when you enter a function. I see no gain here. Some pointer to more info ? TIA -- J.A. Magallon [EMAIL PROTECTED] \ Software is like sex: werewolf.able.es \ It's better when it's free Mandrake Linux release 9.2 (Cooker) for i586 Linux 2.4.22-rc2-jam1m (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-1mdk))
Re: [Cooker] ProPolice stack protection for next Mandrake release?
On Sunday 17 August 2003 17:47, Aleksander Adamowski wrote: How about adding ProPolice stack protection to stock Mandrake GCC? For discussion, see this Mandrake Wiki topic: http://qa.mandrakesoft.com/twiki/bin/view/Main/ProPolice OpenBSD already did that. having the patch would be nice, but not applied as default. we already have libsafe for a runtime protection, which is more flexible than compile time protection. in fact with the patch, you only would need to rebuild and change the .rpmmacro files of the user who is used to build. -- Michaël Scherer
Re: [Cooker] ProPolice stack protection for next Mandrake release?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 J.A. Magallon wrote: | On 08.17, Aleksander Adamowski wrote: | |How about adding ProPolice stack protection to stock Mandrake GCC? | | In linux, you can do 2 things: | - shoot yourself on the feet, so you just break your own account. | - try to get root first, to make something useful with a buffer | overflow. | I see no gain here. Some pointer to more info ? Well, I do - you usually use buffer overflow to gain root :-) E.g. by overflowing the buffer of some process running as root (was popular with sendmail, lpr, ...) Jan - -- Jan Ciger VRlab EPFL Switzerland GPG public key : http://www.keyserver.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/QU97n11XseNj94gRAqk1AKCGewrnm1/1SiySJaQeD1yvnonvGACgzLZ4 rf5Lejgg3SGvPRu1ZEGFhmk= =NA3i -END PGP SIGNATURE-
Re: [Cooker] ProPolice stack protection for next Mandrake release?
On Mon Aug 18, 2003 at 10:13:20PM +0200, J.A. Magallon wrote:
How about adding ProPolice stack protection to stock Mandrake GCC?
I hope not.
I don't see the point of slowing down all the system (you have to
rebuild glibc, the kernel at least) just to protect against
buffer overflows.
Buffer overflows are porpular in windows because it is damned open,
outlook executes automagically even a pig if it comes in an e-mail,
administrators tend to give admin permissions to everybody
because of badly designed apps (I have seen Photoshop not working
because it wanted to write at C:\, and us, poor Unix admins, had
made it read-only), and so on.
In linux, you can do 2 things:
- shoot yourself on the feet, so you just break your own account.
- try to get root first, to make something useful with a buffer
overflow.
And how about things written in other languages ?
For example, in C++ you are not allowed to reorder the stack.
Even more, you do not know the size the stack will grow to when
you enter a function.
I see no gain here. Some pointer to more info ?
Not exactly true. A lot of vulns use buffer overflows to obtain root
priv... you don't start off with root and overflow buffers for kicks.
I'd like to see something like this, but not for a desktop OS. This is more
suited to a hardened version of Corporate Server or something.
Something like StackGuard+FormatGuard (from Immunix although I think they're
quite out-dated) would be good (cover buffer overflows and format string
vulns all at the same time).
--
MandrakeSoft Security; http://www.mandrakesecure.net/
Online Security Resource Book; http://linsec.ca/
lynx -source http://linsec.ca/vdanen.asc | gpg --import
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
pgp0.pgp
Description: PGP signature
Re: [Cooker] ProPolice stack protection for next Mandrake release?
Aleksander Adamowski [EMAIL PROTECTED] wrote: How about adding ProPolice stack protection to stock Mandrake GCC? For discussion, see this Mandrake Wiki topic: http://qa.mandrakesoft.com/twiki/bin/view/Main/ProPolice OpenBSD already did that. If not enabled by default this is a great idea. And then lets get W^X as well ;) # Han -- http://www.xs4all.nl/~hanb/software http://www.xs4all.nl/~hanb/documents/quotingguide.html
