Bug#650536: [new check] test for missing hardening build flags
[ Good god... did I really send a full quote in that mail? Sorry. ] Hi! * Alexander Reichle-Schmehl [111208 10:13]: > > If we can get a reliable backporter for hardening-wrapper as well, > > most of my concerns here covered. On the lintian.d.o side, it means we > > may have to nag DSA for an upgrade of hardening-wrapper every now and then. > Also note that for Lenny there has already been a backport by Ulises > Vitulli , whom I'll have to ping before hijacking his FWIW: I got the permission from Ulises to adopt the backport of hardening-wrapper. So from my point of view, you can introduce such a dependencie whenever it suites you :) Best Regards, Alexander -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#650536: [new check] test for missing hardening build flags
On Fri, Dec 09, 2011 at 09:27:18AM +0100, Alexander Reichle-Schmehl wrote: > Am 08.12.2011 23:40, schrieb Kees Cook: > >> Backporting concerns and output stability: > >> == > >> > >> Both the FTP-masters and Lintian.d.o needs everything in stable (or > >> stable-backports). > >> [..] > > Given that dpkg-buildflags won't be backported, perhaps just having lintian > > detect the lack of the "what are the hardening features?" query ability in > > dpkg-buildflags would be enough to disable the hardening tests in the > > backport? > > Why would you do that? The point of the lintian backport would be to > run the check on packages targeting unstable. It's not that uncommon > for developers to have some unstable chroots / pbuilder environments on > a stable+backports system, and as said, ftp-master and lintian lab use > the same. So the results of lintian backport should IMHO be as similar > to the real package as possible. Hm, while I see your point, I'm not sure what the best solution is. The information about what hardening features are available is coming from dpkg-buildflags. All that jumps to mind for me is having lintian keep static files with the dpkg-buildflags --query-features output for each release. It could be generated and stored instead of strictly being a manually updated list. -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#650536: [new check] test for missing hardening build flags
HI! Am 08.12.2011 23:40, schrieb Kees Cook: >> Backporting concerns and output stability: >> == >> >> Both the FTP-masters and Lintian.d.o needs everything in stable (or >> stable-backports). >> [..] > Given that dpkg-buildflags won't be backported, perhaps just having lintian > detect the lack of the "what are the hardening features?" query ability in > dpkg-buildflags would be enough to disable the hardening tests in the > backport? Why would you do that? The point of the lintian backport would be to run the check on packages targeting unstable. It's not that uncommon for developers to have some unstable chroots / pbuilder environments on a stable+backports system, and as said, ftp-master and lintian lab use the same. So the results of lintian backport should IMHO be as similar to the real package as possible. Best regards, Alexander -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#650536: [new check] test for missing hardening build flags
On Thu, Dec 08, 2011 at 11:50:19AM +0100, Jakub Wilk wrote: > Currently ldd is used to discover which libc the binaries is linked > to, in order to read symbol from the libc library. But this won't > work, even when using readelf, for foreign architecture binaries, > for the simple reason that such libc might not exist on the user's > system. Right. How do you think this should be handled? I could fall back to the earlier method of just looking for things named _chk()? -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#650536: [new check] test for missing hardening build flags
On Thu, Dec 08, 2011 at 12:06:37PM +0100, Niels Thykier wrote: > I was informed (and have verified) that hardening-check uses "ldd(1)". > Unfortunately, ldd(1) appears to be (semi-)executing the binaries it > is run on[1]. This smells like a CVE in the making, so would it be > possible for you to update hardening-check to use readelf instead[2]? Yeah, I can do this manually instead of invoking ldd(1). From the perspective of doing build checks, it seems like a non-issue, but better to just fix it anyway. I'll update hardening-check. -- 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#650536: [new check] test for missing hardening build flags
On Sat, Dec 03, 2011 at 11:20:05AM +0100, Niels Thykier wrote: > On 2011-12-02 01:33, Kees Cook wrote: > > 1) With these build tests added, all the other internal lintian tests > >need to either: > > a) add the new warnings to their "tags" file, or > > b) have all their builds adjusted to bring in the dpkg-buildflag > >defaults. > >It looks like a pretty large change, but it should be relatively > >mechanical to accomplish. I would think that "b" above is the better > >of the two options. > > > > I suspect this is mostly about updating the template rules file + > correct a few extra tests. As an added benefit it should be fairly > trivial (if we ignore architecture specificness for a moment). Okay, sounds good. I'll look at what it'll take to clear all the tests from these warnings, though I suspect this may come after solving the #2 problem below... > > 2) In reality, the tests are arch-dependent. For example, "relro" doesn't > >exist at all on ia64 hppa avr32, and "stackprotector" doesn't exist on > >ia64 alpha mips mipsel hppa arm. I think this expectation needs to be > >built into lintian's invocation of "hardening-check", but that means > >that the "tags" file in the internal lintian tests suddenly needs to > >be generated instead of being static. (i.e. on ia64 and hppa, "no-relro" > >shouldn't show up because it can never happen.) > > > > I proposed the use of the "post_test" sed script here, which hopefully > should do for the actual test. > The question is if we will need it only for the hardening test or we > need it for all the tests with C-binaries. The latter would be very > inconvient. > > Alternatively we can mark the tests architecture dependent. Though in > that case I would prefer being able to determine the architecture list > at test time. If we have to manually update the architecture list of > these tests, they will most likely end up being outdated and even > inconsistent. Right, a manual list is exactly what I want to avoid. I think what is needed is a new feature added to dpkg-buildflags to be able to query the list of hardening features. Both lintian and hardening-check could use it. > Accuracy of the checks: > === > > In the previous versions of hardening-check, the hardening function > check were prone to false-positives. If a binary was not using > protectable-functions at all it would have been tagged as unproected > (because there no protected functions in the binary). I am very pleased > to see that appears to have been fixed in the new version. > As I understand the code, this check should no longer have > false-positives. However it may have some false-negatives - particuarly > if protected and unprotected functions are mixed, it will assume the > binary is protected (in its Lintian output at least). > This check is not architecture dependent and should be fairly trivial > to include. Right. It's better than it was, but it can still produce false-positives. For example, if the only function used was gethostname(), it's possible to do compile-time verification to see that the _chk() version isn't needed, so even though the source was built with -D_FORTIFY_SOURCE=2, the unprotected function will be used. Not all functions are compile-time checkable, and trying to figure out which are which seems a bit out of scope at the moment. And because of this, we're forced into the false-negatives problem. This is why I left it as "possible". > The stack-protector is architecture dependent (as mentioned above). > Protected binaries will have a certain symbol (__stack_chk_fail), but > not all binaries need it[1]. In this case the symbol will be absent > without the binary is vulnerable, which currently leads to false-positives. > As I understand [1], the protection is only needed if the binaries > have an array on the stack. Can we detect the presence (or absence) of > stack arrays (beyond relying on __stack_chk_fail or analysing the binary > code)? If we can, we should be able to reduce the false-positives. We cannot, unfortunately. Or rather, it requires heavy static analysis of arch-dep assembly for the function preamble (which may change between compiler versions, optimizations, etc) and use of alloca(), effectively reverse engineering the asm back to its C form. Additionally, at that level it may be very hard to distinguish between a character array and other kinds of arrays (which would not trigger stack-protector). I'm open to ideas on this, but am currently coming up empty on easy solutions. This is, again, why I left it as "possible". > Finally the relro. This is also architecture dependent, but I do not > know anything about false-positives or false-negatives here. Kees, your > patch marks it "certain" so I presume we have a low false-positive > rating here (if we ignore architecture for a moment)? Correct, relro is a program header on the ELF binary (GNU_
Bug#650536: [new check] test for missing hardening build flags
* Niels Thykier , 2011-12-08, 12:06: I was informed (and have verified) that hardening-check uses "ldd(1)". Unfortunately, ldd(1) appears to be (semi-)executing the binaries it is run on[1]. This smells like a CVE in the making, AFAIUI, ldd in our libc is not vulnerable to arbitrary code execution since 2.10.1-7. The other problem with using ldd is that it won't work for binaries of foreign architecture. so would it be possible for you to update hardening-check to use readelf instead[2]? Currently ldd is used to discover which libc the binaries is linked to, in order to read symbol from the libc library. But this won't work, even when using readelf, for foreign architecture binaries, for the simple reason that such libc might not exist on the user's system. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#650536: [new check] test for missing hardening build flags
Package: lintian Version: 2.5.4 Followup-For: Bug #650536 Hi, I was informed (and have verified) that hardening-check uses "ldd(1)". Unfortunately, ldd(1) appears to be (semi-)executing the binaries it is run on[1]. This smells like a CVE in the making, so would it be possible for you to update hardening-check to use readelf instead[2]? ~Niels [1] Quote /usr/bin/ldd: """ # This is the `ldd' command, which lists what shared libraries are # used by given dynamically-linked executables. It works by invoking the # run-time dynamic linker as a command and setting the environment # variable LD_TRACE_LOADED_OBJECTS to a non-empty value. """ Also take a look at #514408. [2] objdump might work as well, but we are slowly migrating away from it due to issues like #604047. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#650536: [new check] test for missing hardening build flags
Hi! Am 08.12.2011 10:13, schrieb Alexander Reichle-Schmehl: > As you fellow backporter I took a quick glance at the hardening-wrapper > package, and didn't spotted any problems so far (as in: I could create > a backport, install it, and can still compile stuff). However, as I'm > not very familiar with it, I'll ping the maintainers for their opinion. ... or I read the bug log first, and notice that the maintainers of said package are already aware of it ;) Best regards, Alexander, who's going to get some coffee before writing more mails -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#650536: [new check] test for missing hardening build flags
Hi! As you fellow backporter I took a quick glance at the hardening-wrapper package, and didn't spotted any problems so far (as in: I could create a backport, install it, and can still compile stuff). However, as I'm not very familiar with it, I'll ping the maintainers for their opinion. Also note that for Lenny there has already been a backport by Ulises Vitulli , whom I'll have to ping before hijacking his former backport, too. Best regards, Alexander Am 03.12.2011 11:20, schrieb Niels Thykier: > On 2011-12-02 01:33, Kees Cook wrote: >> Hi! >> > > Hey, > > Kees, Jakub and I had a chat about this yesterday in #d-devel. Also, I > have CC'ed Alexander due to your/his role as our backporter and as ftp > team member (Alexander, you may want to fast-foward to "Backporting > concerns" below). > >> Attached is a first-pass at the lintian support for "hardening-check". >> >> There are two more things to do, which I'd like some direction on: >> >> 1) With these build tests added, all the other internal lintian tests >>need to either: >> a) add the new warnings to their "tags" file, or >> b) have all their builds adjusted to bring in the dpkg-buildflag >>defaults. >>It looks like a pretty large change, but it should be relatively >>mechanical to accomplish. I would think that "b" above is the better >>of the two options. >> > > I suspect this is mostly about updating the template rules file + > correct a few extra tests. As an added benefit it should be fairly > trivial (if we ignore architecture specificness for a moment). > >> 2) In reality, the tests are arch-dependent. For example, "relro" doesn't >>exist at all on ia64 hppa avr32, and "stackprotector" doesn't exist on >>ia64 alpha mips mipsel hppa arm. I think this expectation needs to be >>built into lintian's invocation of "hardening-check", but that means >>that the "tags" file in the internal lintian tests suddenly needs to >>be generated instead of being static. (i.e. on ia64 and hppa, "no-relro" >>shouldn't show up because it can never happen.) >> > > I proposed the use of the "post_test" sed script here, which hopefully > should do for the actual test. > The question is if we will need it only for the hardening test or we > need it for all the tests with C-binaries. The latter would be very > inconvient. > > Alternatively we can mark the tests architecture dependent. Though in > that case I would prefer being able to determine the architecture list > at test time. If we have to manually update the architecture list of > these tests, they will most likely end up being outdated and even > inconsistent. > >> Thoughts? >> >> -Kees >> > > Accuracy of the checks: > === > > In the previous versions of hardening-check, the hardening function > check were prone to false-positives. If a binary was not using > protectable-functions at all it would have been tagged as unproected > (because there no protected functions in the binary). I am very pleased > to see that appears to have been fixed in the new version. > As I understand the code, this check should no longer have > false-positives. However it may have some false-negatives - particuarly > if protected and unprotected functions are mixed, it will assume the > binary is protected (in its Lintian output at least). > This check is not architecture dependent and should be fairly trivial > to include. > > > The stack-protector is architecture dependent (as mentioned above). > Protected binaries will have a certain symbol (__stack_chk_fail), but > not all binaries need it[1]. In this case the symbol will be absent > without the binary is vulnerable, which currently leads to false-positives. > As I understand [1], the protection is only needed if the binaries > have an array on the stack. Can we detect the presence (or absence) of > stack arrays (beyond relying on __stack_chk_fail or analysing the binary > code)? If we can, we should be able to reduce the false-positives. > > > Finally the relro. This is also architecture dependent, but I do not > know anything about false-positives or false-negatives here. Kees, your > patch marks it "certain" so I presume we have a low false-positive > rating here (if we ignore architecture for a moment)? > > > There was some talk about including an filter (either in Lintian or in > hardening-check) based on architecture to avoid false-positives in relro > and stack-protector for architectures that do not support them. > > > Backporting concerns and output stability: > == > > Both the FTP-masters and Lintian.d.o needs everything in stable (or > stable-backports). The hardening-wrapper package appears to be small > and trivial enough to backport in itself. But there might be a concern > in terms of the hardening-includes that (if changed) may affect backport > builds. > If we can get a reliable backporte
Bug#650536: [new check] test for missing hardening build flags
On 2011-12-02 01:33, Kees Cook wrote: > Hi! > Hey, Kees, Jakub and I had a chat about this yesterday in #d-devel. Also, I have CC'ed Alexander due to your/his role as our backporter and as ftp team member (Alexander, you may want to fast-foward to "Backporting concerns" below). > Attached is a first-pass at the lintian support for "hardening-check". > > There are two more things to do, which I'd like some direction on: > > 1) With these build tests added, all the other internal lintian tests >need to either: > a) add the new warnings to their "tags" file, or > b) have all their builds adjusted to bring in the dpkg-buildflag >defaults. >It looks like a pretty large change, but it should be relatively >mechanical to accomplish. I would think that "b" above is the better >of the two options. > I suspect this is mostly about updating the template rules file + correct a few extra tests. As an added benefit it should be fairly trivial (if we ignore architecture specificness for a moment). > 2) In reality, the tests are arch-dependent. For example, "relro" doesn't >exist at all on ia64 hppa avr32, and "stackprotector" doesn't exist on >ia64 alpha mips mipsel hppa arm. I think this expectation needs to be >built into lintian's invocation of "hardening-check", but that means >that the "tags" file in the internal lintian tests suddenly needs to >be generated instead of being static. (i.e. on ia64 and hppa, "no-relro" >shouldn't show up because it can never happen.) > I proposed the use of the "post_test" sed script here, which hopefully should do for the actual test. The question is if we will need it only for the hardening test or we need it for all the tests with C-binaries. The latter would be very inconvient. Alternatively we can mark the tests architecture dependent. Though in that case I would prefer being able to determine the architecture list at test time. If we have to manually update the architecture list of these tests, they will most likely end up being outdated and even inconsistent. > Thoughts? > > -Kees > Accuracy of the checks: === In the previous versions of hardening-check, the hardening function check were prone to false-positives. If a binary was not using protectable-functions at all it would have been tagged as unproected (because there no protected functions in the binary). I am very pleased to see that appears to have been fixed in the new version. As I understand the code, this check should no longer have false-positives. However it may have some false-negatives - particuarly if protected and unprotected functions are mixed, it will assume the binary is protected (in its Lintian output at least). This check is not architecture dependent and should be fairly trivial to include. The stack-protector is architecture dependent (as mentioned above). Protected binaries will have a certain symbol (__stack_chk_fail), but not all binaries need it[1]. In this case the symbol will be absent without the binary is vulnerable, which currently leads to false-positives. As I understand [1], the protection is only needed if the binaries have an array on the stack. Can we detect the presence (or absence) of stack arrays (beyond relying on __stack_chk_fail or analysing the binary code)? If we can, we should be able to reduce the false-positives. Finally the relro. This is also architecture dependent, but I do not know anything about false-positives or false-negatives here. Kees, your patch marks it "certain" so I presume we have a low false-positive rating here (if we ignore architecture for a moment)? There was some talk about including an filter (either in Lintian or in hardening-check) based on architecture to avoid false-positives in relro and stack-protector for architectures that do not support them. Backporting concerns and output stability: == Both the FTP-masters and Lintian.d.o needs everything in stable (or stable-backports). The hardening-wrapper package appears to be small and trivial enough to backport in itself. But there might be a concern in terms of the hardening-includes that (if changed) may affect backport builds. If we can get a reliable backporter for hardening-wrapper as well, most of my concerns here covered. On the lintian.d.o side, it means we may have to nag DSA for an upgrade of hardening-wrapper every now and then. Jakub Wilk also expressed some concerns with the output of Lintian would/could (?) vary with the version of hardening-wrapper. Personally I am not too concerned here and I do not believe we have a conflict with our "deterministic-output"-clause[2]. Aside from possible regressions in hardening-check, I suspect the accuracy of it will only increase if anything. My greatest concern in this area is more that it may break our test-suite (i.e. make Lintian FTBFS). I /think/ this should more
