Re: US-CERT Vulnerability Note VU#162289

Ian, Sounds great, thanks, I'll work with Chad to get the vul note updated accordingly. rCs "Robert C. Seacord" <[EMAIL PROTECTED]> writes: Once a new version or patch is available that will warn users that this optimization is taking place, I will recommend that we change the work aro

Re: US-CERT Vulnerability Note VU#162289

"Robert C. Seacord" <[EMAIL PROTECTED]> writes: > Once a new version or patch is available that will warn users that > this optimization is taking place, I will recommend that we change the > work around from "Avoid newer versions of gcc" to "Avoid effected > versions of gcc" and/or recommend that

Re: US-CERT Vulnerability Note VU#162289

Daniel Jacobowitz wrote: On Fri, Apr 25, 2008 at 11:45:25AM -0400, Paul Koning wrote: Robert> To me, the whole notion of this vulnerability node is flawed Robert> in that respect. You can write a lengthy and useful book on Robert> pitfalls in C that must be avoided, but I see no reason to Ro

Re: US-CERT Vulnerability Note VU#162289

* Robert Dewar: > To me, the whole notion of this vulnerability node > is flawed in that respect. You can write a lengthy > and useful book on pitfalls in C that must be > avoided, but I see no reason to turn such a book > into a cert advisory, I think it's useful to point out in security advisor

RE: US-CERT Vulnerability Note VU#162289

Daniel Jacobowitz wrote on : > On Fri, Apr 25, 2008 at 11:45:25AM -0400, Paul Koning wrote: >> Robert> To me, the whole notion of this vulnerability node is flawed >> Robert> in that respect. You can write a lengthy and useful book on >> Robert> pitfalls in C that must be avoided, but I see no

Re: US-CERT Vulnerability Note VU#162289

Daniel Jacobowitz wrote: The R in CERT is "Response" (at least it used to be; I can't find an expansion on their web site...). They're responding to a problem that was reported to them, and alerting others to the problem. We can argue about the details, but not about the need to respond. I a

Re: US-CERT Vulnerability Note VU#162289

On Fri, Apr 25, 2008 at 11:45:25AM -0400, Paul Koning wrote: > Robert> To me, the whole notion of this vulnerability node is flawed > Robert> in that respect. You can write a lengthy and useful book on > Robert> pitfalls in C that must be avoided, but I see no reason to > Robert> turn such a bo

Re: US-CERT Vulnerability Note VU#162289

> "Robert" == Robert Dewar <[EMAIL PROTECTED]> writes: Robert> Another general point is that conceptually this is not an Robert> optimization issue at all. Robert> The programmer writes code that is undefined according to the Robert> standard. ... Robert> To me, the whole notion of thi

RE: US-CERT Vulnerability Note VU#162289

Robert Dewar wrote on : > One thing to realize in this discussion is that it is not > possible in general to warn when a programmer is depending > on undefined behavior, since by definition you cannot in > general guess what misunderstandings the programmer has > about C, and hence what behavior i

Re: US-CERT Vulnerability Note VU#162289

Robert Dewar wrote: Paul Koning wrote: That said, it certainly is helpful if the compiler can detect some undefined actions and warn about them. But that doesn't create a duty to warn about all of them. If it were reasonable to require a compiler to generate a warning for a particula

Re: US-CERT Vulnerability Note VU#162289

Paul Koning wrote: That said, it certainly is helpful if the compiler can detect some undefined actions and warn about them. But that doesn't create a duty to warn about all of them. If it were reasonable to require a compiler to generate a warning for a particular case, the standard would ha

Re: US-CERT Vulnerability Note VU#162289

Another general point is that conceptually this is not an optimization issue at all. The programmer writes code that is undefined according to the standard. Whatever expectation the programmer has for this code is based on either a fundamental misunderstanding of the semantics of C, or there is

Re: US-CERT Vulnerability Note VU#162289

One thing to realize in this discussion is that it is not possible in general to warn when a programmer is depending on undefined behavior, since by definition you cannot in general guess what misunderstandings the programmer has about C, and hence what behavior is expected. There are some cases

RE: US-CERT Vulnerability Note VU#162289

Mark Syddall wrote: ^ Should read "Dave Korn." Apologies all recipients, we had mailserver trouble at this end and somehow some of the resends got the admin's From: line on them by mistake. > Robert C. Seacord wrote on : > >> I am getting tired with the personal/organizational at

RE: US-CERT Vulnerability Note VU#162289

Robert C. Seacord wrote on : > I am getting tired with the personal/organizational attacks. > If you expect a response, please keep your comments professional. Will you address the methodological flaws in your study, or do you consider them to be "personal/organizational attacks"? cheers,

Re: US-CERT Vulnerability Note VU#162289

> "Paul" == Paul Schlie <[EMAIL PROTECTED]> writes: Paul> Mark Mitchell wrote: >> ... >> >> And: >> >>> Addition or subtraction of a pointer into, or just beyond, an >>> array object and an integer type produces a result that does not >>> point into, or just beyond, the same array ob

Re: US-CERT Vulnerability Note VU#162289

Mark Mitchell wrote: > ... > > And: > >> Addition or subtraction of a pointer into, or just beyond, an array object >> and an integer type produces a result that does not point into, or just >> beyond, the same array object (6.5.6). >> >> is undefined behavior. So then unless the compiler can det

Re: US-CERT Vulnerability Note VU#162289

Robert C. Seacord wrote: The following article encapsulates my understanding of undefined behavior based on these discussions: MSC15-A. Do not depend on undefined behavior I think tha

Re: US-CERT Vulnerability Note VU#162289

Robert C. Seacord wrote: Just because a program contains undefined behavior, does not mean that it erroneous. It simply gives the compiler latitude with how to handle the undefined behavior, while still conforming. Actually, erroneous and undefined are approximately synonymous. There are var

Re: US-CERT Vulnerability Note VU#162289

Robert C. Seacord wrote: > Neil, > > I'm not sure I understand what you mean by the following: > >> A program that does not satisfy this constraint is erroneous, and many >> compilers take advantage of this constraint to optimize code more >> effectively. > Just because a program contains undefi

Re: US-CERT Vulnerability Note VU#162289

Neil Booth <[EMAIL PROTECTED]> writes: > At a minimum the wording should be something more like: > > In the C language, given an object OBJ and a pointer BUF into OBJ, > > char *buf; > int len; > > the C standard requires that the result of > > buf + len > > must point

Re: US-CERT Vulnerability Note VU#162289

Neil, I'm not sure I understand what you mean by the following: A program that does not satisfy this constraint is erroneous, and many compilers take advantage of this constraint to optimize code more effectively. Just because a program contains undefined behavior, does not mean that it erron

Re: US-CERT Vulnerability Note VU#162289

David Miller wrote:- > From: Joe Buck <[EMAIL PROTECTED]> > Date: Wed, 23 Apr 2008 08:24:44 -0700 > > > If CERT is to maintain its reputation, it needs to do better. The warning > > is misdirected in any case; given the very large number of compilers that > > these coding practices cause trouble

Re: US-CERT Vulnerability Note VU#162289

* Brad Roberts: > Additionally, the linked to notes for GCC are reflective of the original > innaccuracies: > > http://www.kb.cert.org/vuls/id/CRDY-7DWKWM > > Vendor Statement > No statement is currently available from the vendor regarding this > vulnerability. Chad, it would be helpful if you

Re: US-CERT Vulnerability Note VU#162289

From: Joe Buck <[EMAIL PROTECTED]> Date: Wed, 23 Apr 2008 08:24:44 -0700 > If CERT is to maintain its reputation, it needs to do better. The warning > is misdirected in any case; given the very large number of compilers that > these coding practices cause trouble for, you need to focus on the bad

RE: US-CERT Vulnerability Note VU#162289

Dave Korn wrote: [ ... lots of exciting commentary on scientific method/etc. that I leave out for the protection of the innocent ... ] Huzzah! Way to stick it to the man! :-) :-) > This VU falls massively far below the standards we have come to expect > from CERT, and should be withdrawn and

RE: US-CERT Vulnerability Note VU#162289

Mark Mitchell wrote on : > Chad Dougherty wrote: > >> The vulnerability note has been significantly reworked to focus on the >> issue of undefined behavior handling in the compiler and the fact that >> conforming implementations are not required to warn of this condition. >> I've tried to incorpo

Re: US-CERT Vulnerability Note VU#162289

On Wed, Apr 23, 2008 at 12:25:06PM -0400, Daniel Berlin wrote: > On Wed, Apr 23, 2008 at 9:55 AM, Richard Guenther > <[EMAIL PROTECTED]> wrote: > > > > On Wed, Apr 23, 2008 at 1:59 PM, Chad Dougherty <[EMAIL PROTECTED]> wrote: > > > Brad Roberts wrote: > > > > Which is in general a bad advice as

Re: US-CERT Vulnerability Note VU#162289

On Wed, Apr 23, 2008 at 9:55 AM, Richard Guenther <[EMAIL PROTECTED]> wrote: > > On Wed, Apr 23, 2008 at 1:59 PM, Chad Dougherty <[EMAIL PROTECTED]> wrote: > > Brad Roberts wrote: > > Which is in general a bad advice as older gcc versions may have wrong-code > bugs that are serious and have secu

Re: US-CERT Vulnerability Note VU#162289

On Wed, Apr 23, 2008 at 09:06:56AM -0400, Chad Dougherty wrote: > David Miller wrote: > >CERT is asking these vendors for "approval" for the text they will add > >mentioning anything about their product. That's the bit I'm talking > >about. > > > >They are getting protection and consideration that

Re: US-CERT Vulnerability Note VU#162289

On Wed, Apr 23, 2008 at 1:59 PM, Chad Dougherty <[EMAIL PROTECTED]> wrote: > Brad Roberts wrote: > > > Additionally, the linked to notes for GCC are reflective of the original > innaccuracies: > > http://www.kb.cert.org/vuls/id/CRDY-7DWKWM > > > > Vendor Statement > > No statement is currently avai

Re: US-CERT Vulnerability Note VU#162289

David Miller wrote: CERT is asking these vendors for "approval" for the text they will add mentioning anything about their product. That's the bit I'm talking about. They are getting protection and consideration that was not really afforded to GCC. CERT treated GCC differently. This is not t

Re: US-CERT Vulnerability Note VU#162289

From: Chad Dougherty <[EMAIL PROTECTED]> Date: Wed, 23 Apr 2008 08:37:11 -0400 > David Miller wrote: > > How, may I ask, did that policy apply to the GCC "vendor" > > when this all got started? > > Our own testing of multiple versions of gcc on multiple platforms and > subsequent confirmation by

Re: US-CERT Vulnerability Note VU#162289

David Miller wrote: How, may I ask, did that policy apply to the GCC "vendor" when this all got started? Our own testing of multiple versions of gcc on multiple platforms and subsequent confirmation by Mark that it was intentional, desired behavior. This all occurred prior to even the initia

Re: US-CERT Vulnerability Note VU#162289

From: Chad Dougherty <[EMAIL PROTECTED]> Date: Wed, 23 Apr 2008 07:52:26 -0400 > We won't include information about other vendors without either a > statement from them or independent verification of their affectedness. How, may I ask, did that policy apply to the GCC "vendor" when this all go

Re: US-CERT Vulnerability Note VU#162289

Brad Roberts wrote: Additionally, the linked to notes for GCC are reflective of the original innaccuracies: http://www.kb.cert.org/vuls/id/CRDY-7DWKWM Vendor Statement No statement is currently available from the vendor regarding this vulnerability. US-CERT Addendum Vendors and developers

Re: US-CERT Vulnerability Note VU#162289

Mark Mitchell wrote: However, I'm surprised that only GCC is listed as "vulnerable" at the bottom of the page. We've provided information about a lot of other compilers that do the same optimization. Why is the status for compilers from Microsoft, Intel, IBM, etc. listed as "Unknown" instead

Re: US-CERT Vulnerability Note VU#162289

On Tue, 22 Apr 2008, Mark Mitchell wrote: > Chad Dougherty wrote: > > > The vulnerability note has been significantly reworked to focus on the issue > > of undefined behavior handling in the compiler and the fact that conforming > > implementations are not required to warn of this condition. I've

Re: US-CERT Vulnerability Note VU#162289

Chad Dougherty wrote: The vulnerability note has been significantly reworked to focus on the issue of undefined behavior handling in the compiler and the fact that conforming implementations are not required to warn of this condition. I've tried to incorporate many of the valid concerns that w

Re: US-CERT Vulnerability Note VU#162289

Joe Buck wrote: Thanks. I hope that you will correct the advisory promptly to avoid any implication that one should switch from GCC to a different compiler based on this issue, since we've already established that most of GCC's competitors perform similar optimizations under some cicumstances (e

Re: US-CERT Vulnerability Note VU#162289

Rupert Wood wrote: Nicola Musatti wrote: _main PROC ; 12 :char * b = "0123456789"; ; 13 : for ( int l = 0; l < 1 << 30; ++l ) ; 14 : f(b, l); ; 15 : } xor eax, eax ret0 _main ENDP Note that it optimised away your whole program! It could blank out f(

RE: US-CERT Vulnerability Note VU#162289

Nicola Musatti wrote: > _main PROC > > ; 12 : char * b = "0123456789"; > ; 13 : for ( int l = 0; l < 1 << 30; ++l ) > ; 14 : f(b, l); > ; 15 : } > > xor eax, eax > ret 0 > _main ENDP Note that it optimised away your whole program! It could blank

Re: US-CERT Vulnerability Note VU#162289

David Edelsohn wrote: Nicola, Please send the project files to Robert Seacord. Done. Cheers, Nicola -- Nicola.Musatti gmail com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/

Re: US-CERT Vulnerability Note VU#162289

a Musatti: Re: US-CERT Vulnerability Note VU#162289 David, Sure, please email us the project files. Thanks, rCs --- End of Forwarded Message

Re: US-CERT Vulnerability Note VU#162289

Sorry to be so late in joining this discussion. I'm the person who originally notified Mark Mitchell about Microsoft's compiler performing this same optimization under certain conditions. Since mailing Mark on the subject I tried also VC++ 2008 and it behaves exactly like its predecessor. Here'

Re: US-CERT Vulnerability Note VU#162289

BTW, It occurs to me that the optimisation is just as likely (if not more likely) to remove security holes as it is to introduce them. If someone writes comparison involving 'buf+len' because they incorrectly ignored a possibility of 'buf+len' wrapping, then the optimisation fixes, not breaks, th

Re: US-CERT Vulnerability Note VU#162289

A theoretical argument for why somebody might write problematic code is http://www.fefe.de/openldap-mail.txt . But that's like "putting the cart before the horses" (and complaining that it does not work). You find a security problem, you find a solution, you find the compiler optimizes awa

Re: US-CERT Vulnerability Note VU#162289

Robert Dewar <[EMAIL PROTECTED]> writes: > An optimziation is dubious to me if > > a) it produces surprising changes in behavior (note the importance of > the word surprising here) > > b) it does not provide significant performance gains (note the > importance of the word significant here). > > I

Re: US-CERT Vulnerability Note VU#162289

Joe Buck wrote: On Mon, Apr 14, 2008 at 06:42:30PM -0400, Robert Dewar wrote: [In fact, after GCC does something to warn users about this, it'll be much "safer" than those other compilers.] For sure you want a warning, the compiler should never be removing explicit tests in the users code witho

Re: US-CERT Vulnerability Note VU#162289

> Robert Dewar <[EMAIL PROTECTED]> > >> Richard Guenther wrote: >> >> In absence of any declared object (like with this testcase where we just >> have an incoming pointer to some unknown object) the compiler can >> still assume that any valid object ends at the end of the address space. >> Thus,

Re: US-CERT Vulnerability Note VU#162289

On Mon, Apr 14, 2008 at 06:42:30PM -0400, Robert Dewar wrote: > >[In fact, > >after GCC does something to warn users about this, it'll be > >much "safer" than those other compilers.] > > For sure you want a warning, the compiler should never be > removing explicit tests in the users code without g

Re: US-CERT Vulnerability Note VU#162289

[EMAIL PROTECTED] wrote: It's already been acknowledged that the source code is wrong to assume that the compiler knows about wrapping of pointers. The real issue at this stage is how to warn users who may be using GCC and implicitly relying on its old behavior, without unintentionally pushing p

RE: US-CERT Vulnerability Note VU#162289

Robert Dewar wrote: > An optimziation is dubious to me if > > a) it produces surprising changes in behavior (note the importance of > the word surprising here) > > b) it does not provide significant performance gains (note the > importance of the word significant here). > > I find this optimizat

Re: US-CERT Vulnerability Note VU#162289

Joe Buck wrote: On Mon, Apr 14, 2008 at 04:27:40PM -0400, Robert Dewar wrote: Ian Lance Taylor wrote: A theoretical argument for why somebody might write problematic code is http://www.fefe.de/openldap-mail.txt . I don't know where, or even if, such code is actually found in the wild. Ian F

Re: US-CERT Vulnerability Note VU#162289

Florian Weimer wrote: Existing safe C implementations take a performance hit which is a factor between 5 and 11 in terms of execution time. There is some new research that seems to get away with a factor less than 2, but it's pretty recent and I'm not sure if it's been reproduced independently.

Re: US-CERT Vulnerability Note VU#162289

On Mon, Apr 14, 2008 at 04:27:40PM -0400, Robert Dewar wrote: > Ian Lance Taylor wrote: > > >A theoretical argument for why somebody might write problematic code > >is http://www.fefe.de/openldap-mail.txt . > > > >I don't know where, or even if, such code is actually found in the > >wild. > > > >I

Re: US-CERT Vulnerability Note VU#162289

Ian Lance Taylor wrote: A theoretical argument for why somebody might write problematic code is http://www.fefe.de/openldap-mail.txt . I don't know where, or even if, such code is actually found in the wild. Ian Fair enough question. The other question of course is how much this optimization

Re: US-CERT Vulnerability Note VU#162289

Florian Weimer <[EMAIL PROTECTED]> writes: >> To me, dubious optimizations like this at the very least should >> be optional and able to be turned off. > > Why is this optimization dubious? We would need to look at real-world > code to tell, and so far, we haven't heard anything about the context

Re: US-CERT Vulnerability Note VU#162289

* Robert Dewar: > Florian Weimer wrote: >> * Robert C. Seacord: >> >>> i agree that the optimization is allowed by C99. i think this is a >>> quality of implementation issue, and that it would be preferable for >>> gcc to emphasize security over performance, as might be expected. >> >> I don't t

Re: US-CERT Vulnerability Note VU#162289

Robert C. Seacord wrote: > > i agree that the optimization is allowed by C99. i think this is a > > quality of implementation issue, and that it would be preferable for > > gcc to emphasize security over performance, as might be expected. On Sun, Apr 13, 2008 at 11:51:00PM +0200, Florian Weimer

Re: US-CERT Vulnerability Note VU#162289

Robert Dewar <[EMAIL PROTECTED]> writes: > Alex Stepanov told me once that he preferred Ada to C, because Ada > has proper pointer arithmetic (via the type Integer_Address) which > is defined to work in Ada in the manner that Paul mistakenly expects > for C. Integer_Address would be a bit of a pai

Re: US-CERT Vulnerability Note VU#162289

Richard Guenther wrote: In absence of any declared object (like with this testcase where we just have an incoming pointer to some unknown object) the compiler can still assume that any valid object ends at the end of the address space. Thus, an object either declared or allocated via malloc neve

Re: US-CERT Vulnerability Note VU#162289

Paul Schlie wrote: (as an aside, as most target implementations treat pointers as unsigned values, its not clear that presuming signed integer overflow semantics are a reasonable choice for pointer comparison optimization) The point is not of presuming signed integer overflow semantics (I was co

Re: US-CERT Vulnerability Note VU#162289

On Mon, Apr 14, 2008 at 1:55 PM, Paul Schlie <[EMAIL PROTECTED]> wrote: > > > >> (as an aside, as most target implementations treat pointers as unsigned > >> values, its not clear that presuming signed integer overflow semantics are > >> a reasonable choice for pointer comparison optimization) >

Re: US-CERT Vulnerability Note VU#162289

>> (as an aside, as most target implementations treat pointers as unsigned >> values, its not clear that presuming signed integer overflow semantics are >> a reasonable choice for pointer comparison optimization) > > The point is not of presuming signed integer overflow semantics (I was > correcte

Re: US-CERT Vulnerability Note VU#162289

(as an aside, as most target implementations treat pointers as unsigned values, its not clear that presuming signed integer overflow semantics are a reasonable choice for pointer comparison optimization) The point is not of presuming signed integer overflow semantics (I was corrected on this

Re: US-CERT Vulnerability Note VU#162289

Paul Schlie wrote: Florian Weimer wrote: Robert C. Seacord wrote: i agree that the optimization is allowed by C99. i think this is a quality of implementation issue, and that it would be preferable for gcc to emphasize security over performance, as might be expected. I don't think this is r

Re: US-CERT Vulnerability Note VU#162289

> Florian Weimer wrote: > >> Robert C. Seacord wrote: >> >> i agree that the optimization is allowed by C99. i think this is a >> quality of implementation issue, and that it would be preferable for >> gcc to emphasize security over performance, as might be expected. > > I don't think this is r

Re: US-CERT Vulnerability Note VU#162289

Florian Weimer wrote: * Robert C. Seacord: i agree that the optimization is allowed by C99. i think this is a quality of implementation issue, and that it would be preferable for gcc to emphasize security over performance, as might be expected. I don't think this is reasonable. If you use

Re: US-CERT Vulnerability Note VU#162289

* Robert C. Seacord: > i agree that the optimization is allowed by C99. i think this is a > quality of implementation issue, and that it would be preferable for > gcc to emphasize security over performance, as might be expected. I don't think this is reasonable. If you use GCC and its C fronte

Re: US-CERT Vulnerability Note VU#162289

On Fri, Apr 11, 2008 at 03:00:14PM -0400, Robert C. Seacord wrote: > Ian, > >I know I'm biased, but I think "use a different compiler" is clearly > >implied by the text of the advisory. If the advisory mentioned that > >other compilers also implement the same optimization, then that > >implication

Re: US-CERT Vulnerability Note VU#162289

Robert C. Seacord wrote: Gerald, There was a report (forwarded by Mark Mitchell) of Microsoft Visual C++ 2005 performing that optimization (the resultant object code was shown). Have you verified that this report was false? both chad and i have tested this with various options on Visual C++ 2

Re: US-CERT Vulnerability Note VU#162289

> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes: Ian> "Robert C. Seacord" <[EMAIL PROTECTED]> writes: >>> What you really mean is, "Use an older GCC or some other compiler >>> that is known not to take advantage of this optimization." >>> >> i think we mean what we say, which is "

Re: US-CERT Vulnerability Note VU#162289

Ian, I know I'm biased, but I think "use a different compiler" is clearly implied by the text of the advisory. If the advisory mentioned that other compilers also implement the same optimization, then that implication would not be there. yes, i agree we should make this change, and warn again

Re: US-CERT Vulnerability Note VU#162289

Gerald, There was a report (forwarded by Mark Mitchell) of Microsoft Visual C++ 2005 performing that optimization (the resultant object code was shown). Have you verified that this report was false? both chad and i have tested this with various options on Visual C++ 2005 and we have not found

Re: US-CERT Vulnerability Note VU#162289

From: Ian Lance Taylor <[EMAIL PROTECTED]> Date: Fri, 11 Apr 2008 11:04:38 -0700 > "Robert C. Seacord" <[EMAIL PROTECTED]> writes: > > >> What you really mean is, > >> "Use an older GCC or some other compiler that is known not to > >> take advantage of this optimization." > >> > > i think we

Re: US-CERT Vulnerability Note VU#162289

"Robert C. Seacord" <[EMAIL PROTECTED]> writes: >> What you really mean is, >> "Use an older GCC or some other compiler that is known not to >> take advantage of this optimization." >> > i think we mean what we say, which is "*Avoid newer versions of gcc" > and *"avoiding the use of gcc versio

RE: US-CERT Vulnerability Note VU#162289

Robert C. Seacord wrote: > this was only one of several solutions listed, and not the first one > listed. Yes, CERT did the right thing by recommending first that the code be changed (kudos for that). >> What you really mean is, >> "Use an older GCC or some other compiler that is known not to >>

Re: US-CERT Vulnerability Note VU#162289

Gerald, Comments below. My understanding is that it shouldn't, because the real issue here is pointer arithmetic and the resulting type should always be a pointer. I'm not sure what you mean by that last statement. my understanding of the C99 standard is that adding an integer and a

RE: US-CERT Vulnerability Note VU#162289

Robert C. Seacord wrote: > Here is another version of the program (same compiler version/flags). [...] > void test_signed(char *buf) { > signed int len; [...] > if((buf+len < buf) != ((uintptr_t)buf+len < (uintptr_t)buf)) > printf(" BUG!"); [...] > void test_unsigned(char *buf) { >

Re: US-CERT Vulnerability Note VU#162289

Gerald, Here is another version of the program (same compiler version/flags). #include void test_signed(char *buf) { signed int len; len = 1<<30; printf("buf = %p; buf+len = %p; buf+len < buf = %d %d", buf, buf+len, buf+len < buf, (uintptr_t)buf+len < (uintptr_t)buf); if

RE: US-CERT Vulnerability Note VU#162289

Robert C. Seacord wrote: > void f(char *buf) { > unsigned int len = len = 0xFF00; > > if (buf+len < buf) puts("true"); > > } You need to be more precise. That is not the same example that you quoted for GCC. In fact, if you vary the criteria too much, you will find situations where GCC

Re: US-CERT Vulnerability Note VU#162289

Dave, I made at least one change you suggested: #include void f(char *buf) { unsigned int len = 0xFF00u; if (buf+len < buf) puts("true"); } int main(void) { char buffer[100]; printf("buffer addr = %p.\n", buffer); f(buffer); return 0; } And compiled with flags: /O2 /GL

Re: US-CERT Vulnerability Note VU#162289

* Robert C. Seacord: > I agree with you that the behavior that gcc exhibits in this case is > permitted by the ISO/IEC 9899:1999 C specification > > (§6.5.6p8). I believe the vulnerability is that gcc may *silently* > discard the overfl

RE: US-CERT Vulnerability Note VU#162289

Robert C. Seacord wrote on : > Specifically with regards to MSVC 2005, I thought Chad had already > checked this and found that it did not exhibit this behavior. I just > tested the following program. > > #include > > void f(char *buf) { > unsigned int len = len = 0xFF00; I'm sure y

Re: US-CERT Vulnerability Note VU#162289

Robert C. Seacord wrote: I will update the CERT C Secure Coding rule with a list of compilers, once we complete a fact check. Chad is responsible for updating the vul note, so I'll need to discuss this with him. Thanks. Specifically with regards to MSVC 2005, I thought Chad had already che

Re: US-CERT Vulnerability Note VU#162289

Mark, I will update the CERT C Secure Coding rule with a list of compilers, once we complete a fact check. Chad is responsible for updating the vul note, so I'll need to discuss this with him. Specifically with regards to MSVC 2005, I thought Chad had already checked this and found that it

Re: US-CERT Vulnerability Note VU#162289

Mark Mitchell wrote: Mark Mitchell wrote: I've been told that Intel's ICC compiler also does this optimization: Apparently, IAR's Atmel AVR compiler does this optimization as well. That CPU has 16-bit addresses, so the tester changed the test case to use "1 << 14" instead of "1 << 30". I'

Re: US-CERT Vulnerability Note VU#162289

Daniel Jacobowitz wrote: On Tue, Apr 08, 2008 at 01:09:18PM +0100, Dave Korn wrote: ~ $ gcc -O3 -S -xc -o 2.s - extern void foo (char *buf, int len); extern void bar (char *buf); void foo (char *buf, int len) { if (buf+len < buf) { bar (buf); } return; } Note that if buf is a char

Re: US-CERT Vulnerability Note VU#162289

On Mon, Apr 07, 2008 at 02:15:14PM -0400, "Robert C. Seacord" <[EMAIL PROTECTED]> wrote: > >The advisory suggests that people not use GCC. > no, it does not. it suggests they may not want to use the latest > versions. this is one possible work around. we never say "use another > compiler".

Re: US-CERT Vulnerability Note VU#162289

On Tue, Apr 08, 2008 at 01:09:18PM +0100, Dave Korn wrote: > ~ $ gcc -O3 -S -xc -o 2.s - > extern void foo (char *buf, int len); > extern void bar (char *buf); > > void foo (char *buf, int len) > { > if (buf+len < buf) > { > bar (buf); > } > return; > } Note that if buf is a char *, t

RE: US-CERT Vulnerability Note VU#162289

Mark Mitchell wrote on : > Mark Mitchell wrote: > >> I've been told that Intel's ICC compiler also does this optimization: > > Apparently, IAR's Atmel AVR compiler does this optimization as well. Say, how do I get gcc to actually do this? I can't reproduce this in a real-world test. I woul

Re: US-CERT Vulnerability Note VU#162289

Mark Mitchell wrote: I've been told that Intel's ICC compiler also does this optimization: Apparently, IAR's Atmel AVR compiler does this optimization as well. That CPU has 16-bit addresses, so the tester changed the test case to use "1 << 14" instead of "1 << 30". The generated code is:

US-CERT Vulnerability Note VU#162289

> If you know of a non-GCC compiler that optimizes away > the test (so that the function always returns 0), please > post here, and let me know the name, version number, > command-line options, etc. you used to demonstrate that. The lovely TI Code Composer Studio compiler does the same optimiza

Re: US-CERT Vulnerability Note VU#162289

On Mon, Apr 7, 2008 at 1:44 PM, Tom Truscott <[EMAIL PROTECTED]> wrote: > Oops, sorry! That is a very nice warning (apparently in gcc newer than 4.2). It was added in at least 4.2.3. -- Pinski

RE: US-CERT Vulnerability Note VU#162289

Oops, sorry! That is a very nice warning (apparently in gcc newer than 4.2). -Original Message- From: Ian Lance Taylor [mailto:[EMAIL PROTECTED] Sent: Monday, April 07, 2008 4:40 PM To: Tom Truscott Cc: gcc@gcc.gnu.org Subject: Re: US-CERT Vulnerability Note VU#162289 Tom Truscott

Re: US-CERT Vulnerability Note VU#162289

Tom Truscott wrote: Here is an unintended bug I encountered recently, hopefully the "cert" warning will catch this one too. int okay_to_increment (int i) { if (i + 1 < i) return 0; /* adding 1 would cause overflow */ return 1;/* adding 1 is safe */ } Any sort

Re: US-CERT Vulnerability Note VU#162289

Tom Truscott <[EMAIL PROTECTED]> writes: > Here is an unintended bug I encountered recently, hopefully the "cert" > warning will catch this one too. > >int okay_to_increment (int i) >{ > if (i + 1 < i) > return 0; /* adding 1 would cause overflow */ > return 1;/*

Re: US-CERT Vulnerability Note VU#162289

Here is an unintended bug I encountered recently, hopefully the "cert" warning will catch this one too. int okay_to_increment (int i) { if (i + 1 < i) return 0; /* adding 1 would cause overflow */ return 1;/* adding 1 is safe */ } Any sort of bug can cause a sec

Re: US-CERT Vulnerability Note VU#162289

Mark Mitchell wrote: I've been told that Intel's ICC compiler also does this optimization: ICC 10.0 and earlier releases perform the same optimization, but not on straight-line code, such as the testcase. ICC performs the transformation inside loops. Thanks, -- Mark Mitchell CodeSourcery [E

  1   2   >