From timb at openvas.org Wed Aug 19 16:11:19 2009 From: timb at openvas.org (Tim Brown) Date: Wed, 19 Aug 2009 15:11:19 +0100 Subject: [Openvas-distro] Hardening OpenVAS Message-ID: <200908191511.21302.timb@openvas.org> Hey all, So as a security related project I think we should take a lead with respect to hardening our code. I've just taken the latest openvas* source packages and rebuilt them using DEB_BUILD_HARDENING=1 (http://wiki.debian.org/Hardening). I will run it for a week or two on x86_64 to see if it shows any bugs up but if not, I would like to apply it to the official packaging. Does anyone have any issues with such a plan? Tim PS Anyone compiling for other platforms is welcome to join in this exercise... and in fact we should consider moving the hardening into the mainline build tree in due course? -- Tim Brown From bitdealer at gmail.com Wed Aug 19 17:25:52 2009 From: bitdealer at gmail.com (Stephan Kleine) Date: Wed, 19 Aug 2009 17:25:52 +0200 Subject: [Openvas-distro] Hardening OpenVAS In-Reply-To: References: <200908191511.21302.timb@openvas.org> Message-ID: I would love it if you fix your code to comply with those. E.g. Mandriva 2009.1 uses "-Werror=format-security" by default and currently all builds for it are broken (see http://wald.intevation.org/tracker/index.php?func=detail&aid=1051&group_id=29&atid=220 ) Also most newer distros already use -D_FORTIFY_SOURCE=2 and -fstack-protector so those shouldn't be a problem. Regarding -fPIE -pie, ld -z relro & ld -z now I have no idea but just would like to ask you to only use them __additionally__ to the distros compilation flags in $RPM_OPT_FLAGS (and whatever Debian uses) instead of trying to replace them. My $0,02. Cheers, Stephan PS: Sent two times cause it didn't get send to the list. Sorry Tim. > On Wed, Aug 19, 2009 at 4:11 PM, Tim Brown wrote: >> Hey all, >> >> So as a security related project I think we should take a lead with respect to >> hardening our code. ?I've just taken the latest openvas* source packages and >> rebuilt them using DEB_BUILD_HARDENING=1 (http://wiki.debian.org/Hardening). >> I will run it for a week or two on x86_64 to see if it shows any bugs up but >> if not, I would like to apply it to the official packaging. ?Does anyone have >> any issues with such a plan? >> >> Tim >> >> PS Anyone compiling for other platforms is welcome to join in this exercise... >> and in fact we should consider moving the hardening into the mainline build >> tree in due course? >> -- >> Tim Brown >> >> >> _______________________________________________ >> Openvas-distro mailing list >> Openvas-distro at wald.intevation.org >> http://lists.wald.intevation.org/mailman/listinfo/openvas-distro >> > From waja at cyconet.org Wed Aug 19 18:57:41 2009 From: waja at cyconet.org (Jan Wagner) Date: Wed, 19 Aug 2009 18:57:41 +0200 Subject: [Openvas-distro] [Openvas-distro-deb] Hardening OpenVAS In-Reply-To: <200908191511.21302.timb@openvas.org> References: <200908191511.21302.timb@openvas.org> Message-ID: <200908191857.45369.waja@cyconet.org> Hi there, On Wednesday 19 August 2009, Tim Brown wrote: > So as a security related project I think we should take a lead with respect > to hardening our code. I've just taken the latest openvas* source packages > and rebuilt them using DEB_BUILD_HARDENING=1 > (http://wiki.debian.org/Hardening). I will run it for a week or two on > x86_64 to see if it shows any bugs up but if not, I would like to apply it > to the official packaging. Does anyone have any issues with such a plan? good point. What about uploading those packages to experimental beside having normal packages in unstable next 1 or 2 (release) rounds? With kind regards, Jan. -- Never write mail to , you have been warned! -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GIT d-- s+: a- C+++ UL++++ P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++ ------END GEEK CODE BLOCK------ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.wald.intevation.org/pipermail/openvas-distro/attachments/20090819/43d07f13/attachment.pgp From timb at openvas.org Wed Aug 19 20:54:24 2009 From: timb at openvas.org (Tim Brown) Date: Wed, 19 Aug 2009 19:54:24 +0100 Subject: [Openvas-distro] Hardening OpenVAS In-Reply-To: References: <200908191511.21302.timb@openvas.org> Message-ID: <200908191954.26555.timb@openvas.org> On Wednesday 19 August 2009 16:25:52 Stephan Kleine wrote: > I would love it if you fix your code to comply with those. E.g. > Mandriva 2009.1 uses "-Werror=format-security" by default and > currently all builds for it are broken (see > http://wald.intevation.org/tracker/index.php?func=detail&aid=1051&group_id= >29&atid=220 ) Curious, that builds fine for me on Debian using the same flags... didn't get a similar error.... In fact, the latest versions of all key modules build fine. Looks like Felix's patch (in the bug report) which is in trunk and current releases does the trick in the first case. The later cases you report are a bug^Wfeature in gcc IMO. It does not appear that gcc is able to determine that the format string is generated by GNU gettext and therefore throws a wobbly. Not sure how to resolve, so if anyone else has thoughts I'd be please to hear them. *wanders over to gcc on FreeNode* > Also most newer distros already use -D_FORTIFY_SOURCE=2 and > -fstack-protector so those shouldn't be a problem. Yes, I know.. my original thoughts were primarily around being a good Debian citizen and applying the hardening wrapper, but I figured I might as well let other package maintainers know. > Regarding -fPIE -pie, ld -z relro & ld -z now I have no idea but just > would like to ask you to only use them __additionally__ to the distros > compilation flags in $RPM_OPT_FLAGS (and whatever Debian uses) instead > of trying to replace them. At this stage I'm not proposing to change the underlying build platform but simply turn on hardening for Debian. Of course if it works, then we might consider how to extend it out to be the default irrespective of the platform. Tim -- Tim Brown From bitdealer at gmail.com Wed Aug 19 21:30:40 2009 From: bitdealer at gmail.com (Stephan Kleine) Date: Wed, 19 Aug 2009 21:30:40 +0200 Subject: [Openvas-distro] Hardening OpenVAS In-Reply-To: <200908191954.26555.timb@openvas.org> References: <200908191511.21302.timb@openvas.org> <200908191954.26555.timb@openvas.org> Message-ID: On Wed, Aug 19, 2009 at 8:54 PM, Tim Brown wrote: > On Wednesday 19 August 2009 16:25:52 Stephan Kleine wrote: > >> I would love it if you fix your code to comply with those. E.g. >> Mandriva 2009.1 uses "-Werror=format-security" by default and >> currently all builds for it are broken (see >> http://wald.intevation.org/tracker/index.php?func=detail&aid=1051&group_id= >>29&atid=220 ) > > Curious, that builds fine for me on Debian using the same flags... didn't get > a similar error.... ?In fact, the latest versions of all key modules build > fine. No, they are as broken as they ever were (regarding this issue). Please correct me if I am wrong but Debian uses "-Wformat-security" while Mandriva uses "-Werror=format-security" so Debian just prints a warning and moves on while Mandriva bails, right? (so, imho the Debian approach is kinda half assed) > Looks like Felix's patch (in the bug report) which is in trunk and > current releases does the trick in the first case. That patch is unrelated (it merely replaces g_strdup_printf with g_strdup since that made no sense there anyways). >?The later cases you report > are a bug^Wfeature in gcc IMO. ?It does not appear that gcc is able to > determine that the format string is generated by GNU gettext and therefore > throws a wobbly. ?Not sure how to resolve, so if anyone else has thoughts I'd > be please to hear them. *wanders over to gcc on FreeNode* Dunno if that also could be a Mandriva gcc bug but I kinda doubt it since it also compiles their whole distro just fine and therefore I consider my warning vs. error theory more likely ;D iow: try to compile on Debian with "-Werror=format-security" instead of "-Wformat-security" and see if that works since just generating a few more warnings in the build log is kinda pointless if you ask me. Cheers, Stephan. From timb at openvas.org Wed Aug 19 21:43:10 2009 From: timb at openvas.org (Tim Brown) Date: Wed, 19 Aug 2009 20:43:10 +0100 Subject: [Openvas-distro] Hardening OpenVAS In-Reply-To: References: <200908191511.21302.timb@openvas.org> <200908191954.26555.timb@openvas.org> Message-ID: <200908192043.12964.timb@openvas.org> On Wednesday 19 August 2009 20:30:40 Stephan Kleine wrote: > On Wed, Aug 19, 2009 at 8:54 PM, Tim Brown wrote: > > On Wednesday 19 August 2009 16:25:52 Stephan Kleine wrote: > >> I would love it if you fix your code to comply with those. E.g. > >> Mandriva 2009.1 uses "-Werror=format-security" by default and > >> currently all builds for it are broken (see > >> http://wald.intevation.org/tracker/index.php?func=detail&aid=1051&group_ > >>id= 29&atid=220 ) > > > > Curious, that builds fine for me on Debian using the same flags... didn't > > get a similar error.... ?In fact, the latest versions of all key modules > > build fine. > > No, they are as broken as they ever were (regarding this issue). > Please correct me if I am wrong but Debian uses "-Wformat-security" > while Mandriva uses "-Werror=format-security" so Debian just prints a > warning and moves on while Mandriva bails, right? (so, imho the Debian > approach is kinda half assed) Yes sorry, I started off commenting based on your initial bug report and didn't see the pdf stuff, I then came back to the email and changed some bits but clearly the email no longer made sense :(. You're absolutely right the others are broken with -Werror=format-security, but as I noted later this appears to be due to a feature of gcc. > > Looks like Felix's patch (in the bug report) which is in trunk and > > current releases does the trick in the first case. > > That patch is unrelated (it merely replaces g_strdup_printf with > g_strdup since that made no sense there anyways). > > >?The later cases you report > > are a bug^Wfeature in gcc IMO. ?It does not appear that gcc is able to > > determine that the format string is generated by GNU gettext and > > therefore throws a wobbly. ?Not sure how to resolve, so if anyone else > > has thoughts I'd be please to hear them. *wanders over to gcc on > > FreeNode* > > Dunno if that also could be a Mandriva gcc bug but I kinda doubt it > since it also compiles their whole distro just fine and therefore I > consider my warning vs. error theory more likely ;D > > iow: try to compile on Debian with "-Werror=format-security" instead > of "-Wformat-security" and see if that works since just generating a > few more warnings in the build log is kinda pointless if you ask me. That last paragraph of mine was me agreeing with you that -Werror caused the compiler to bail, but that having read up on it, that it appears to be gcc failing to recognise that the value passed in the format string parameter is not a simple string but rather a call out to GNU gettext. Further more it appears that this is a known problem. Hope I make more sense this time. Tim -- Tim Brown From timb at openvas.org Sun Aug 23 03:11:57 2009 From: timb at openvas.org (Tim Brown) Date: Sun, 23 Aug 2009 02:11:57 +0100 Subject: [Openvas-distro] Hardening OpenVAS In-Reply-To: <200908192043.12964.timb@openvas.org> References: <200908191511.21302.timb@openvas.org> <200908192043.12964.timb@openvas.org> Message-ID: <200908230211.59540.timb@openvas.org> On Wednesday 19 August 2009 20:43:10 Tim Brown wrote: > On Wednesday 19 August 2009 20:30:40 Stephan Kleine wrote: > > On Wed, Aug 19, 2009 at 8:54 PM, Tim Brown wrote: > > > On Wednesday 19 August 2009 16:25:52 Stephan Kleine wrote: > > >> I would love it if you fix your code to comply with those. E.g. > > >> Mandriva 2009.1 uses "-Werror=format-security" by default and > > >> currently all builds for it are broken (see > > >> http://wald.intevation.org/tracker/index.php?func=detail&aid=1051&grou > > >>p_ id= 29&atid=220 ) > > > > > > Curious, that builds fine for me on Debian using the same flags... > > > didn't get a similar error.... ?In fact, the latest versions of all key > > > modules build fine. > > > > No, they are as broken as they ever were (regarding this issue). > > Please correct me if I am wrong but Debian uses "-Wformat-security" > > while Mandriva uses "-Werror=format-security" so Debian just prints a > > warning and moves on while Mandriva bails, right? (so, imho the Debian > > approach is kinda half assed) > > Yes sorry, I started off commenting based on your initial bug report and > didn't see the pdf stuff, I then came back to the email and changed some > bits but clearly the email no longer made sense :(. You're absolutely > right the others are broken with -Werror=format-security, but as I noted > later this appears to be due to a feature of gcc. > > > > Looks like Felix's patch (in the bug report) which is in trunk and > > > current releases does the trick in the first case. > > > > That patch is unrelated (it merely replaces g_strdup_printf with > > g_strdup since that made no sense there anyways). > > > > >?The later cases you report > > > are a bug^Wfeature in gcc IMO. ?It does not appear that gcc is able to > > > determine that the format string is generated by GNU gettext and > > > therefore throws a wobbly. ?Not sure how to resolve, so if anyone else > > > has thoughts I'd be please to hear them. *wanders over to gcc on > > > FreeNode* > > > > Dunno if that also could be a Mandriva gcc bug but I kinda doubt it > > since it also compiles their whole distro just fine and therefore I > > consider my warning vs. error theory more likely ;D > > > > iow: try to compile on Debian with "-Werror=format-security" instead > > of "-Wformat-security" and see if that works since just generating a > > few more warnings in the build log is kinda pointless if you ask me. > > That last paragraph of mine was me agreeing with you that -Werror caused > the compiler to bail, but that having read up on it, that it appears to be > gcc failing to recognise that the value passed in the format string > parameter is not a simple string but rather a call out to GNU gettext. > Further more it appears that this is a known problem. Heh, looks like I was over complicating my own thoughts on this bug. In the case you reported, it turns out that the bug could be resolved cheaply by redefining the PRINT macro in pdf_output from: #define PRINT(file, x) { char * s = _2l(x); fprintf(file, s); g_free(s); } to: #define PRINT(file, x) { char * s = _2l(x); fprintf(file, "%s", s); g_free(s); } Bug is fixed in trunk... Tim -- Tim Brown From marco.bonetti at slackware.it Mon Aug 24 18:03:34 2009 From: marco.bonetti at slackware.it (Marco Bonetti) Date: Mon, 24 Aug 2009 18:03:34 +0200 (CEST) Subject: [Openvas-distro] Hardening OpenVAS In-Reply-To: <200908191511.21302.timb@openvas.org> References: <200908191511.21302.timb@openvas.org> Message-ID: <53123.88.149.157.90.1251129814.squirrel@webmail.slackware.it> On Wed, August 19, 2009 16:11, Tim Brown wrote: > PS Anyone compiling for other platforms is welcome to join in this > exercise... and in fact we should consider moving the hardening into the > mainline build tree in due course? The Slackware philosophy is to keep the number of "--enable-*"configure arguments as low as possible, compatible with the features requested from one package. Keep in mind that this is due mainly because the official Slackware distribution has a limited number of packages when compared to other major distros and everything extra, like OpenVAS, is distributed by third parties. I'm ok if you, the developers, will start pushing the use of extra hardening options when compiling OpenVAS and I really like the idea: just keep in mind that the slackbuilds published on SlackBuilds.org will have those features turned off if the user has to enable them at compile time but I will surely add an enviroment variable to turn them on. It's the SlackBuilds.org way of enabling extra features which have some uncovered, experimental or just unconventional, like this, dependencies. When those features will be automatically enabled at compile time without the need of a configure option I'll have no problems at building the packages as they are :-) Just my 2 cents, ciao -- Marco Bonetti BT3 EeePC enhancing module: http://sid77.slackware.it/bt3/ Slackintosh Linux Project Developer: http://workaround.ch/ Linux-live for powerpc: http://workaround.ch/pub/rsync/mb/linux-live/ My GnuPG key id: 0x86A91047