Bug#673112: lintian: hardening-no-stackprotector check has many false positives
Hi Niels,
On 22/05/12 14:05, Niels Thykier wrote:
[2] // Poor man's strdup
#include stdio.h
#include string.h
#include stdlib.h
int main(int argc, char **argv) {
const char *s = argv[0];
size_t l = strlen(s);
char *cpy = malloc (l + 1);
if (!cpy)
return 1;
strcpy(cpy, s);
cpy[0] = 'b';
printf(%s\n, cpy);
return 0;
}
I've been playing around with your example a bit. Since I stumbled upon some
cases where gcc didn't replace calls to memset and memmove with their hardened
versions, I modified your example to use memset and memmove. I ended up with the
following:
#include string.h
#include stdio.h
#include stdlib.h
int main(int argc, char** argv)
{
const char* s = argv[0];
size_t l = strlen(s);
char* cpy = malloc(l + 1);
if (!cpy)
return 1;
memset(cpy, s[0], l);
cpy[l] = 0;
printf(%s\n, cpy);
memmove(cpy, s, l);
cpy[0] = 'b';
printf(%s\n, cpy);
return 0;
}
Regardless of the flags passed to gcc [1], hardening-check reports the following
[2]:
Fortify Source functions: no, only unprotected functions found!
unprotected: memset
unprotected: memmove
So maybe memset and memmove are good candidates for the while list as well.
Cheers
[1] `dpkg-buildflags --get CFLAGS` `dpkg-buildflags --get CPPFLAGS`
`dpkg-buildflags --get LDFLAGS` and iterated over all the possible -O.
[2] With -Os the call to memset is optimized and not present at all.
--
Sebastian Ramacher
signature.asc
Description: OpenPGP digital signature
Bug#673112: lintian: hardening-no-stackprotector check has many false positives
On 2012-05-21 20:25, Modestas Vainius wrote: Hello, Hi, For the record, I have just demoted no-stackprotector to a wild-guess (thus, it is now an I tag) and moved it to a separate profile (debian/extra-hardening) so it is no longer enabled by default. On šeštadienis 19 Gegužė 2012 19:49:14 Russ Allbery wrote: Sven Joachim svenj...@gmx.de writes: Easier said then done, how should I override this warning: , | W: libncurses5: hardening-no-fortify-functions | usr/lib/i386-linux-gnu/libmenu.so.5.9 ` libncurses5 binary: hardening-no-fortify-functions usr/lib/*/libmenu.so.* Well, I get this nice lintian output: $ lintian -I amarok_2.5.0-2_amd64.changes [...] This is like 90 false positives in a single source package, it makes lintian output unreadable. I don't know how this hardening stuff is detected but I suspect this failure might be because the package is built with -fvisibility=hidden. If so, all KDE packages will suffer, and badly. [...] We use hardening-check (from hardening-includes) - as I recall it carries a list of unprotected functions and checks for them (via readelf). It maps them to a safe-variant and checks for that as well. If both protected and unprotected are used or if no unprotected functions are used, it should mark it safe. However, I believe Kees (CC'ed) can correct me on (or confirm) the above. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673112: lintian: hardening-no-stackprotector check has many false positives
On 2012-05-22 12:54, Niels Thykier wrote: On 2012-05-21 20:25, Modestas Vainius wrote: Hello, Hi, [...] We use hardening-check (from hardening-includes) - as I recall it carries a list of unprotected functions and checks for them (via readelf). It maps them to a safe-variant and checks for that as well. If both protected and unprotected are used or if no unprotected functions are used, it should mark it safe. However, I believe Kees (CC'ed) can correct me on (or confirm) the above. ~Niels Turns out hardening-check has a verbose flag that makes it print the affected functions - testing amarok (testing i386) I got[1]. Looks like memcpy is the primary source of false-positives (for amarok). If it turns out that memcpy is (in general) the primary source of these false-positives, perhaps it would be better to skip that particular function than disable the entire check. ~Niels [1] $ hardening-check --verbose $(find usr/lib/ -type f) | perl -ne \ 'print if /^\s+(un)?protected:/' | sort | uniq -c 1 protected: fprintf 1 protected: memcpy 1 protected: memmove 1 protected: memset 1 protected: pread64 1 protected: printf 1 protected: realpath 1 protected: snprintf 1 protected: sprintf 1 protected: strcat 1 protected: strcpy 1 protected: strncat 1 protected: strncpy 1 protected: vfprintf 1 protected: vsnprintf 1 unprotected: asprintf 1 unprotected: confstr 1 unprotected: fgets 1 unprotected: fprintf 2 unprotected: fread 1 unprotected: getcwd 1 unprotected: gethostname 43 unprotected: memcpy 1 unprotected: memmove 3 unprotected: memset 1 unprotected: pread64 1 unprotected: printf 1 unprotected: read 1 unprotected: readlink 1 unprotected: recv 1 unprotected: snprintf 2 unprotected: sprintf 1 unprotected: stpcpy 1 unprotected: strcat 2 unprotected: strcpy 2 unprotected: strncpy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673112: lintian: hardening-no-stackprotector check has many false positives
On 2012-05-22 13:05, Niels Thykier wrote:
[...]
Turns out hardening-check has a verbose flag that makes it print the
affected functions - testing amarok (testing i386) I got[1]. Looks like
memcpy is the primary source of false-positives (for amarok).
If it turns out that memcpy is (in general) the primary source of these
false-positives, perhaps it would be better to skip that particular
function than disable the entire check.
~Niels
[1]
[...]
Okay, final spam for now.
I think it would be a very good idea to drop at least memcpy from the
hardening-check because GCC 4.7 (at -O2 or higher), GCC may replace
strcpy and other functions with memcpy[1].
I have tested a little code snippet[2] with gcc-4.7 and it indeed it
replaces strcpy with memcpy at -O2. Also it never uses the fortified
variant of strcpy/memcpy (not even at -O0) in this trivial case.
So for -O0 binaries we would still get false-positives in this case (and
binaries compiled with 4.7), but we would presumably avoid a lot of
false-positiives for binaries compiled by gcc-4.7 -O2 in this way.
~Niels
[1] http://gcc.gnu.org/gcc-4.7/changes.html
A string length optimization pass has been added. It attempts to track
string lengths and optimize various standard C string functions like
strlen, strchr, strcpy, strcat, stpcpy and their _FORTIFY_SOURCE
counterparts into faster alternatives. This pass is enabled by default
at -O2 or above, unless optimizing for size, and can be disabled by the
-fno-optimize-strlen option. The pass can e.g. optimize
char *bar (const char *a)
{
size_t l = strlen (a) + 2;
char *p = malloc (l); if (p == NULL) return p;
strcpy (p, a); strcat (p, /); return p;
}
into:
char *bar (const char *a)
{
size_t tmp = strlen (a);
char *p = malloc (tmp + 2); if (p == NULL) return p;
memcpy (p, a, tmp); memcpy (p + tmp, /, 2); return p;
}
[...]
[2] // Poor man's strdup
#include stdio.h
#include string.h
#include stdlib.h
int main(int argc, char **argv) {
const char *s = argv[0];
size_t l = strlen(s);
char *cpy = malloc (l + 1);
if (!cpy)
return 1;
strcpy(cpy, s);
cpy[0] = 'b';
printf(%s\n, cpy);
return 0;
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673112: lintian: hardening-no-stackprotector check has many false positives
On Tue, May 22, 2012 at 12:54:19PM +0200, Niels Thykier wrote: On 2012-05-21 20:25, Modestas Vainius wrote: For the record, I have just demoted no-stackprotector to a wild-guess (thus, it is now an I tag) and moved it to a separate profile (debian/extra-hardening) so it is no longer enabled by default. Ah well. Too bad. Once build flags are exposed in the ELF itself, this will just have to be the way it is. On šeštadienis 19 Gegužė 2012 19:49:14 Russ Allbery wrote: Sven Joachim svenj...@gmx.de writes: Easier said then done, how should I override this warning: , | W: libncurses5: hardening-no-fortify-functions | usr/lib/i386-linux-gnu/libmenu.so.5.9 ` libncurses5 binary: hardening-no-fortify-functions usr/lib/*/libmenu.so.* Well, I get this nice lintian output: $ lintian -I amarok_2.5.0-2_amd64.changes [...] This is like 90 false positives in a single source package, it makes lintian output unreadable. I don't know how this hardening stuff is detected but I suspect this failure might be because the package is built with -fvisibility=hidden. If so, all KDE packages will suffer, and badly. [...] We use hardening-check (from hardening-includes) - as I recall it carries a list of unprotected functions and checks for them (via readelf). It maps them to a safe-variant and checks for that as well. If both protected and unprotected are used or if no unprotected functions are used, it should mark it safe. However, I believe Kees (CC'ed) can correct me on (or confirm) the above. Correct. If none of the functions are found, it passes. If there is a mix of protected and unprotected, it passes. If only protected are found, it passes. If only unprotected are found, it fails. It is, however, still an heuristic, since it is possible to only use the functions in ways that are compile-time verifiable, resulting in no need for the protected wrapper. -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673112: lintian: hardening-no-stackprotector check has many false positives
Hello, On šeštadienis 19 Gegužė 2012 19:49:14 Russ Allbery wrote: Sven Joachim svenj...@gmx.de writes: Easier said then done, how should I override this warning: , | W: libncurses5: hardening-no-fortify-functions | usr/lib/i386-linux-gnu/libmenu.so.5.9 ` libncurses5 binary: hardening-no-fortify-functions usr/lib/*/libmenu.so.* Well, I get this nice lintian output: $ lintian -I amarok_2.5.0-2_amd64.changes W: amarok: hardening-no-stackprotector usr/bin/amarok W: amarok: hardening-no-stackprotector usr/bin/amarokpkg W: amarok: hardening-no-fortify-functions usr/bin/amarokpkg W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_appletscript_simple_javascript.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_appletscript_simple_javascript.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_collection-audiocdcollection.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_collection-audiocdcollection.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_collection-ipodcollection.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_collection-mtpcollection.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_collection-mtpcollection.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_collection-mysqlservercollection.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_collection-playdarcollection.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_collection-playdarcollection.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_collection-umscollection.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_collection-umscollection.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_collection-upnpcollection.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_collection-upnpcollection.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_containment_vertical.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_containment_vertical.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_context_applet_albums.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_context_applet_albums.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_context_applet_currenttrack.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_context_applet_currenttrack.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_context_applet_info.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_context_applet_labels.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_context_applet_labels.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_context_applet_lyrics.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_context_applet_lyrics.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_context_applet_photos.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_context_applet_photos.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_context_applet_similarArtists.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_context_applet_similarArtists.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_context_applet_spectrum_analyzer.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_context_applet_spectrum_analyzer.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_context_applet_tabs.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_context_applet_tabs.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_context_applet_upcomingEvents.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_context_applet_upcomingEvents.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_context_applet_videoclip.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_context_applet_videoclip.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_context_applet_wikipedia.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_context_applet_wikipedia.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_data_engine_current.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_data_engine_info.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_data_engine_labels.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_data_engine_lyrics.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_data_engine_lyrics.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_data_engine_photos.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_data_engine_similarArtists.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_data_engine_spectrum_analyzer.so W: amarok: hardening-no-fortify-functions usr/lib/kde4/amarok_data_engine_spectrum_analyzer.so W: amarok: hardening-no-stackprotector usr/lib/kde4/amarok_data_engine_tabs.so W: amarok:
Bug#673112: lintian: hardening-no-stackprotector check has many false positives
On 2012-05-18 22:34 +0200, Russ Allbery wrote:
Ralf Jung p...@ralfj.de writes:
I'd like to extend this to hardening-no-fortify-functions: My package
definitely has -D_FORTIFY_SOURCE=2 set (an excerpt from the build flags:
-fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -D_FORTIFY_SOURCE=2), but I get a
hardening-no-stackprotector and hardening- no-fortify-functions for its
only binary.
False positives for _FORTIFY_SOURCE are somewhat rarer, and that one is
much easier to miss applying due to the CPPFLAGS vs. CFLAGS distinction.
My immediate inclination would be to ask people to add an override for
false positives for it, since it's more likely that the tag is valid.
Easier said then done, how should I override this warning:
,
| W: libncurses5: hardening-no-fortify-functions
usr/lib/i386-linux-gnu/libmenu.so.5.9
`
Using the output verbatim only works for one architecture and generates
an additional problem (unused-override) for all others, substituting
${DEB_HOST_MULTIARCH} at build time instead leads to
/usr/share/lintian/overrides/libncurses5 having architecture-dependent
content, breaking multiarch coinstallability.
Cheers,
Sven
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673112: lintian: hardening-no-stackprotector check has many false positives
Sven Joachim svenj...@gmx.de writes: Easier said then done, how should I override this warning: , | W: libncurses5: hardening-no-fortify-functions usr/lib/i386-linux-gnu/libmenu.so.5.9 ` libncurses5 binary: hardening-no-fortify-functions usr/lib/*/libmenu.so.* -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673112: lintian: hardening-no-stackprotector check has many false positives
Hi, I'd like to extend this to hardening-no-fortify-functions: My package definitely has -D_FORTIFY_SOURCE=2 set (an excerpt from the build flags: -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2), but I get a hardening-no-stackprotector and hardening- no-fortify-functions for its only binary. Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673112: lintian: hardening-no-stackprotector check has many false positives
Ralf Jung p...@ralfj.de writes: I'd like to extend this to hardening-no-fortify-functions: My package definitely has -D_FORTIFY_SOURCE=2 set (an excerpt from the build flags: -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2), but I get a hardening-no-stackprotector and hardening- no-fortify-functions for its only binary. False positives for _FORTIFY_SOURCE are somewhat rarer, and that one is much easier to miss applying due to the CPPFLAGS vs. CFLAGS distinction. My immediate inclination would be to ask people to add an override for false positives for it, since it's more likely that the tag is valid. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673112: lintian: hardening-no-stackprotector check has many false positives
Package: lintian Version: 2.5.7 Severity: normal The new hardening warnings are certainly a useful reminder to use dpkg-buildflags, but especially hardening-no-stackprotector seems to have a high number of false positives. In ncurses-examples alone there are no less than 40 hardening-no-stackprotector warnings, and the package ships 59 binaries in total, all built with -fstack-protector. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.4.0-rc7-nouveau (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lintian depends on: ii binutils 2.22-6 ii bzip2 1.0.6-1 ii diffstat 1.55-2 ii file 5.11-1 ii gettext0.18.1.1-7 ii hardening-includes 2.1 ii intltool-debian0.35.0+20060710.1 ii libapt-pkg-perl0.1.26+b1 ii libc-bin 2.13-32 ii libclass-accessor-perl 0.34-1 ii libclone-perl 0.31-1+b2 ii libdigest-sha-perl 5.71-1 ii libdpkg-perl 1.16.3 ii libemail-valid-perl0.190-1 ii libipc-run-perl0.91-1 ii libparse-debianchangelog-perl 1.2.0-1 ii libtimedate-perl 1.2000-1 ii liburi-perl1.60-1 ii locales2.13-32 ii man-db 2.6.1-2 ii patchutils 0.3.2-1.1 ii perl [libdigest-sha-perl] 5.14.2-10 ii unzip 6.0-6 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch none ii dpkg-dev 1.16.3 ii libhtml-parser-perl3.69-2 ii libtext-template-perl 1.45-2 ii man-db 2.6.1-2 ii xz-utils 5.1.1alpha+20110809-3 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
