Bug#709415: lintian: false positive for hardening-no-fortify-functions

[Russ Allbery]

Package: lintian
Version: 2.5.11
Severity: normal

I'm getting these for a few different packages. Not sure if they're
related, but I took a moment to track this one down. In the new
xml-security-c 1.7.0-1, I get:

W: xml-security-c-utils: hardening-no-fortify-functions usr/bin/xmlsec-xklient

but the relevant build lines are:

g++ -DHAVE_CONFIG_H -I. -I.. -I../xsec/framework -I.. -D_FORTIFY_SOURCE=2 -Wall -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -O2 -DNDEBUG -pthread -DXSEC_LIBRARY_BUILD -c -o xklient.o `test -f 'tools/xklient/xklient.cpp' || echo './'`tools/xklient/xklient.cpp
tools/xklient/xklient.cpp: In function 'int doParsedMsgDump(xercesc_3_1::DOMDocument*)':
tools/xklient/xklient.cpp:3815:6: warning: variable 'errorsOccured' set but not used [-Wunused-but-set-variable]
/bin/sh ../libtool --tag=CXX --mode=link g++ -Wall -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -O2 -DNDEBUG -pthread -DXSEC_LIBRARY_BUILD -fPIE -pie -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o xklient xklient.o libxml-security-c.la -lxerces-c -lm -lssl -lcrypto
libtool: link: g++ -Wall -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -O2 -DNDEBUG -pthread -DXSEC_LIBRARY_BUILD -fPIE -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/xklient xklient.o -Wl,--as-needed ./.libs/libxml-security-c.so -lxerces-c -lm -lssl -lcrypto -pthread

so all the appropriate flags should be there.

hardening-check of course has the same issue:

% hardening-check xmlsec-xklient
xmlsec-xklient:
Position Independent Executable: yes
Stack protected: yes
Fortify Source functions: no, only unprotected functions found!
Read-only relocations: yes
Immediate binding: yes

I get the same thing from libkopenafs1:

% hardening-check /usr/lib/libkopenafs.so
/usr/lib/libkopenafs.so:
Position Independent Executable: no, regular shared library (ignored)
Stack protected: no, not found!
Fortify Source functions: no, only unprotected functions found!
Read-only relocations: yes
Immediate binding: yes

even though it's built with hardening-wrappers, although I wasn't as sure
with it since it incorporates some assembly and I wasn't sure if that
would confuse the check. Note that libkopenafs1 hardly calls anything in
libc:

Symbol table '.dynsym' contains 21 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 NOTYPE WEAK DEFAULT UND _ITM_deregisterTMCloneTab
2: 00000000 0 FUNC GLOBAL DEFAULT UND free@GLIBC_2.0 (3)
3: 00000000 0 FUNC GLOBAL DEFAULT UND signal@GLIBC_2.0 (3)
4: 00000000 0 FUNC GLOBAL DEFAULT UND ioctl@GLIBC_2.0 (3)
5: 00000000 0 FUNC WEAK DEFAULT UND __cxa_finalize@GLIBC_2.1.3 (4)
6: 00000000 0 FUNC GLOBAL DEFAULT UND malloc@GLIBC_2.0 (3)
7: 00000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
8: 00000000 0 FUNC GLOBAL DEFAULT UND open@GLIBC_2.0 (5)
9: 00000000 0 FUNC GLOBAL DEFAULT UND __errno_location@GLIBC_2.0 (5)
10: 00000000 0 FUNC GLOBAL DEFAULT UND syscall@GLIBC_2.0 (3)
11: 00000000 0 FUNC GLOBAL DEFAULT UND getgroups@GLIBC_2.0 (3)
12: 00000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
13: 00000000 0 NOTYPE WEAK DEFAULT UND _ITM_registerTMCloneTable
14: 00000000 0 FUNC GLOBAL DEFAULT UND close@GLIBC_2.0 (5)
15: 000008b0 86 FUNC GLOBAL DEFAULT 12 k_unlog@@KOPENAFS_1.0
16: 00000000 0 OBJECT GLOBAL DEFAULT ABS KOPENAFS_1.0
17: 00000870 56 FUNC GLOBAL DEFAULT 12 k_pioctl@@KOPENAFS_1.0
18: 00000790 187 FUNC GLOBAL DEFAULT 12 k_hasafs@@KOPENAFS_1.0
19: 00000910 361 FUNC GLOBAL DEFAULT 12 k_haspag@@KOPENAFS_1.0
20: 00000850 25 FUNC GLOBAL DEFAULT 12 k_setpag@@KOPENAFS_1.0

so I'm not sure what hardening-check has to complain about.

-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.8-2-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lintian depends on:
ii binutils 2.22-8
ii bzip2 1.0.6-4
ii diffstat 1.55-3
ii file 1:5.11-3
ii gettext 0.18.1.1-10
ii hardening-includes 2.3
ii intltool-debian 0.35.0+20060710.1
ii libapt-pkg-perl 0.1.28
ii libarchive-zip-perl 1.30-6
ii libc-bin 2.13-38
ii libclass-accessor-perl 0.34-1
ii libclone-perl 0.31-1+b2
ii libdpkg-perl 1.16.10
ii libemail-valid-perl 0.190-1
ii libipc-run-perl 0.92-1
ii libparse-debianchangelog-perl 1.2.0-1
ii libtext-levenshtein-perl 0.06~01-2
ii libtimedate-perl 1.2000-1
ii liburi-perl 1.60-1
ii locales 2.17-3
ii man-db 2.6.3-3
ii patchutils 0.3.2-1.1
ii perl [libdigest-sha-perl] 5.14.2-21
ii t1utils 1.37-2

lintian recommends no packages.

Versions of packages lintian suggests:
pn binutils-multiarch <none>
ii dpkg-dev 1.16.10
ii libhtml-parser-perl 3.71-1
pn libperlio-gzip-perl <none>
ii libtext-template-perl 1.45-2
ii man-db 2.6.3-3
ii xz-utils [lzma] 5.1.1alpha+20120614-2

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Niels Thykier]

On 2013-05-23 09:18, Russ Allbery wrote:
> Package: lintian
> Version: 2.5.11
> Severity: normal
>

Hi,

Assuming you were using 2.5.11 for test, you may want to retry with
2.5.12. The latter did another false-positive -> false-negative
trade-off (memset and memmove).

> I'm getting these for a few different packages. Not sure if they're
> related, but I took a moment to track this one down. In the new
> xml-security-c 1.7.0-1, I get:
>
> W: xml-security-c-utils: hardening-no-fortify-functions usr/bin/xmlsec-xklient
>
> but the relevant build lines are:
>

> [...]

>
> so all the appropriate flags should be there.
>
> hardening-check of course has the same issue:
>
> % hardening-check xmlsec-xklient
> xmlsec-xklient:

> [...]

>
> I get the same thing from libkopenafs1:
>
> % hardening-check /usr/lib/libkopenafs.so
> /usr/lib/libkopenafs.so:

> [...]

>
> even though it's built with hardening-wrappers, although I wasn't as sure
> with it since it incorporates some assembly and I wasn't sure if that
> would confuse the check. Note that libkopenafs1 hardly calls anything in
> libc:
>

> [...]

> so I'm not sure what hardening-check has to complain about.
>

> [...]


Try running hardening-check with --verbose, this will make
hardening-check list all the "protectable" functions that appear in the
binary. Example:

"""
$ hardening-check --verbose /bin/ls
/bin/ls:
Position Independent Executable: no, normal executable!
Stack protected: yes
Fortify Source functions: yes (some protected functions found)
unprotected: mempcpy
[...]
protected: mempcpy
[...]
Read-only relocations: yes
Immediate binding: no, not found!
"""

As long as there is at least 1 protected function or no unprotected
ones, Lintian should consider it "hardened".

~Niels

[Russ Allbery]

Niels Thykier <ni...@thykier.net> writes:

> Assuming you were using 2.5.11 for test, you may want to retry with
> 2.5.12. The latter did another false-positive -> false-negative
> trade-off (memset and memmove).

Looks like that won't help for libkopenafs1:

% hardening-check --verbose /usr/lib/libkopenafs.so.1
/usr/lib/libkopenafs.so.1:

Position Independent Executable: no, regular shared library (ignored)
Stack protected: no, not found!
Fortify Source functions: no, only unprotected functions found!

unprotected: getgroups
Read-only relocations: yes
Immediate binding: yes

That's the one built with hardening-wrappers installed.

Also looks like that's not the issue for xml-security-c-utils:

% hardening-check --verbose xmlsec-xklient

xmlsec-xklient:
Position Independent Executable: yes

Stack protected: yes

Fortify Source functions: no, only unprotected functions found!

unprotected: fread
Read-only relocations: yes
Immediate binding: yes

(Thanks for the note about --verbose!)

--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>

[Niels Thykier]

On 2013-05-23 09:40, Russ Allbery wrote:
> Niels Thykier <ni...@thykier.net> writes:
>
>> Assuming you were using 2.5.11 for test, you may want to retry with
>> 2.5.12. The latter did another false-positive -> false-negative
>> trade-off (memset and memmove).
>
> Looks like that won't help for libkopenafs1:
>
> % hardening-check --verbose /usr/lib/libkopenafs.so.1

> [...]

>
> That's the one built with hardening-wrappers installed.
>
> Also looks like that's not the issue for xml-security-c-utils:
>
> % hardening-check --verbose xmlsec-xklient

> [...]
>

Indeed. Sadly there is nothing on the Lintian side (or in
hardening-check) that allows us to get any more information to improve
the accuracy (without doing something drastic like decompiling the
binary and analysing that - but even then).
To be honest, I have been considering if we should reduce and disable
this tag like we did with the stack-protector tag. In terms of
accuracy, blhc beats hardening-check/lintian by miles. Even if
people/upstreams tend to mistake C{,XX}FLAGS vs. CPPFLAGS, I suspect we
would be better off by disabling this tag (e.g. less frustation from our
users). The tag would still be available via the debian/extra-hardening
profile, so people can opt-in.

NB: I would still keep hardening-no-relro, which has very few
false-positives to my knowledge (most overridden tags appear to be
non-free packages, so probably caused by the binaries not being
re-buildable).

> (Thanks for the note about --verbose!)
>

You are welcome. :) It happens to be the way we implement the fp->fn
trade-offs.

~Niels

[Russ Allbery]

Niels Thykier <ni...@thykier.net> writes:

> To be honest, I have been considering if we should reduce and disable
> this tag like we did with the stack-protector tag. In terms of
> accuracy, blhc beats hardening-check/lintian by miles. Even if
> people/upstreams tend to mistake C{,XX}FLAGS vs. CPPFLAGS, I suspect we
> would be better off by disabling this tag (e.g. less frustation from our
> users). The tag would still be available via the debian/extra-hardening
> profile, so people can opt-in.

I'm at least seeing a lot of false positives for a tag that's marked
possible. We could drop it to wild-guess, which IIRC would make it
info-level instead of a warning, which feels about right for the level of
false positive vs. false negative tradeoff we have at the moment.

>> (Thanks for the note about --verbose!)

> You are welcome. :) It happens to be the way we implement the fp->fn
> trade-offs.

It would be neat to include the list of unprotected functions as
additional data for the tag.

--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>

[Niels Thykier]

On 2013-05-23 10:09, Russ Allbery wrote:
> Niels Thykier <ni...@thykier.net> writes:
>
>> To be honest, I have been considering if we should reduce and disable
>> this tag like we did with the stack-protector tag. In terms of
>> accuracy, blhc beats hardening-check/lintian by miles. Even if
>> people/upstreams tend to mistake C{,XX}FLAGS vs. CPPFLAGS, I suspect we
>> would be better off by disabling this tag (e.g. less frustation from our
>> users). The tag would still be available via the debian/extra-hardening
>> profile, so people can opt-in.
>
> I'm at least seeing a lot of false positives for a tag that's marked
> possible. We could drop it to wild-guess, which IIRC would make it
> info-level instead of a warning, which feels about right for the level of
> false positive vs. false negative tradeoff we have at the moment.
>

Granted, I have demoted the certainty accordingly.

>>> (Thanks for the note about --verbose!)
>
>> You are welcome. :) It happens to be the way we implement the fp->fn
>> trade-offs.
>
> It would be neat to include the list of unprotected functions as
> additional data for the tag.
>

In the tag description or the tag "extra"? For the former, the problem
might be that the list is (or could be) architecture dependent. For the
latter, it would need some changes to hardening-info{,-helper} +
c/binaries. But also some consideration to handle 5+ unprotected
functions. Example even the following is getting rather lengthy

... hardening-no-fortity-functions path/to/file func1, func2, func3, ...

~Niels

[Russ Allbery]

Niels Thykier <ni...@thykier.net> writes:

> In the tag description or the tag "extra"? For the former, the problem
> might be that the list is (or could be) architecture dependent. For the
> latter, it would need some changes to hardening-info{,-helper} +
> c/binaries. But also some consideration to handle 5+ unprotected
> functions. Example even the following is getting rather lengthy

> ... hardening-no-fortity-functions path/to/file func1, func2, func3, ...

I was thinking the tag extra, just to list the unprotected functions, but
it was more a matter of curiosity than anything I think is horribly
important.

--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>