Re: MIT discovered issue with gcc
Miles, the GCC developers don't consider this to be a bug, and so I doubt that any of it will be "fixed". For example, here is a "bug" cited in the paper: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 If you have a moment, read through that thread. It gets pretty testy as the developers argue over whether or not it's a bug. Eventually it was closed as "invalid', i.e. not really a true bug. It's not just GCC, either. Take a look at this series of blog posts by the LLVM team: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html Compiler developers, for better or worse, reserve the right to do whatever they want with undefined behavior, and it's up to the person writing the C code to not include undefined behavior in their own program. Therefore, a Linux distribution has 2 choices: (1) wait for upstream patches for bugs/vulnerabilities as they are found, or (2) recompile all packages with optimizations disabled. I don't think proposal #2 would get very far... On Tue, Nov 26, 2013 at 1:54 PM, Miles Fidelman wrote: > Going back through the discussion on this thread, I'm taken by two main > reactions: > > - discussion of the specific class of bugs/security holes > - a lot of comments that "this is an issue for upstream" > > What I haven't seen, so I'll add it to the discussion, is that this > strikes me as an issue for "WAY upstream" - i.e., if gcc's optimizer is > opening a class of security holes - then it's gcc that has to be fixed, > after which that class of holes would go away after the next build of any > impacted package. > > Miles Fidelman > > > > -- > To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/5294ee82.8050...@meetinghouse.net > > -- Mark E. Haase CISSP, CEH Sr. Security Software Engineer www.lunarline.com 3300 N Fairfax Drive, Suite 308, Arlington, VA 22201 202-815-0201 "Solutions Built on Security" TM Lunarline, Inc. is an ISO 9001 and CMMI Level 2 Certified SDVOSB Information Assurance\ Cyber Security Services Company.
Re: MIT discovered issue with gcc
The researchers' point was that an attacker might be able to remap that memory
page so that dereferencing a null pointer would NOT segfault. (I don't actually
know how feasible this is; I'm just paraphrasing their argument. They footnote
this claim but I didn't bother to read the cited sources.)
Checking if tun is null is [apparently] a valid precautionary measure -- not
useless -- except an optimizer might remove it. The order of these statements
is definitely wrong, but the authors are claiming that this optimization turns
an otherwise innocuous bug into an exploitable vulnerability.
Anyway, I don't see what this has to do with Debian. It's an interesting paper,
but Debian can't find and fix all upstream bugs, nor do I think most users
would be happy if suddenly everything was compiled without any optimizations.
--
Mark E. Haase
> On Nov 23, 2013, at 10:09 AM, Robert Baron
> wrote:
>
> Aren't many of the constructs used as examples in the paper are commonly
> used in c programming. For example it is very common to see a function that
> has a pointer as a parameter defined as:
>
> int func(void *ptr)
> {
> if(!ptr) return SOME_ERROR;
> /* rest of function*/
> return 1;
> }
>
> Isn't it interesting that their one example will potentially dereference the
> null pointer even before compiler optimizations (from the paper):
>
> struct tun_struct *tun=;
> struct sock *sk = tun->sk;
> if(*tun) return POLLERR;
>
> The check to see that tun is non-null should occur before use, as in - quite
> frankly it is useless to check after as tun cannot be the null pointer (the
> program hasn't crashed):
>
> struct tun_struct *tun=;
> if(*tun) return POLLERR;
> struct sock *sk = tun->sk;
>
> I am under the impression that these problems are rather widely known among c
> programmers (perhaps not the kids fresh out of college). But this is why
> teams need to have experienced people.
>
> Furthermore, it is very common to find code that works before optimization,
> and fails at certain optimization levels. Recently, I was compiling a
> library that failed its own tests under the optimization level set in the
> makefile but passed its own test at a lower level of optimization.
>
> PS: I liked their first example, as it appears to be problematic.
>
>
>> On Sat, Nov 23, 2013 at 8:17 AM, Joel Rees wrote:
>> Deja gnu?
>>
>> On Sat, Nov 23, 2013 at 10:34 AM, Andrew McGlashan
>> wrote:
>> > Hi,
>> >
>> > The following link shows the issue in a nutshell:
>> >
>> > http://www.securitycurrent.com/en/research/ac_research/mot-researchers-uncover-security-flaws-in-c
>> >
>> > [it refers to the PDF that I mentioned]
>> >
>> > --
>> > Kind Regards
>> > AndrewM
>>
>> I seem to remember discussing the strange optimizations that optimized
>> away range checks because the code that was being firewalled "had to
>> be correct".
>>
>> Ten years ago, it was engineers that understood pointers but didn't
>> understand logic. This time around, maybe it's a new generation of
>> sophomoric programmers, or maybe we have moles in our ranks.
>>
>> The sky is not falling, but it sounds like I don't want to waste my
>> time with Clang yet. And I probably need to go make myself persona
>> non-grata again in some C language forums
>>
>> --
>> Joel Rees
>>
>> Be careful where you see conspiracy.
>> Look first in your own heart.
>>
>>
>> --
>> To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>> Archive:
>> http://lists.debian.org/caar43io_4l7+vil8vqzpzro+fdm1vhpphepomp88hiwbn+f...@mail.gmail.com
>
