tes for those compilers as well.
rCs
**
--
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC
Work: 412-268-7608
FAX: 412-268-6989
On Mon, Apr 7, 2008 at 10:28 AM, Robert C. Seacord <[EMAIL PROTECTED]> wrote:
I believe the vulnerability is that gcc may *silently* discard the overflow
checks and that this is a recent change in behavior.
No it is not recent, unless you consider 1998 recent :). I don'
Joe,
Response below.
On Mon, Apr 07, 2008 at 01:28:21PM -0400, Robert C. Seacord wrote:
You are also right that the popularity of gcc is one of the reasons we
decided to publish on this. If you identify other compilers that a) are
relatively popular, b) have changed their behavior
Mark,
comments below.
Robert C. Seacord wrote:
You are also right that the popularity of gcc is one of the reasons
we decided to publish on this. If you identify other compilers that
a) are relatively popular, b) have changed their behavior recently,
and c) silently optimize out overflow
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
er addr = 0012FF18.
true
The reason the len is so high is to force an overflow when added to
0x0012FF18.
BTW, I also tried compiling this as a C++ program under visual studio
and got the same result.
rCs
Robert C. Seacord wrote on :
Specifically with regards to MSVC 2005, I thought Chad
n't make a difference on Visual Studio. My
understanding is that it shouldn't, because the real issue here is
pointer arithmetic and the resulting type should always be a pointer.
rCs
Robert C. Seacord wrote:
void f(char *buf) {
unsigned int len = len = 0xFF00;
if (buf+
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
found any combination of options that will cause this
optimization to occur.
rCs
--
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC
Work: 412-268-7608
FAX: 412-268-6989
hange, and warn against assuming this
optimization is not performed on other compilers.
if i understand you correctly (and based on our own tests) none of the
compilation flags we've discussed address this issue, so we should also
remove this as a "solution".
thanks,
rCs
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
Ralph,
Comments below.
(a) Arithmetic overflows have historically been a significant source of
security vulnerabilities.
agreed.
(b) Recent versions of gcc (along with other compilers) contain an
optimisation that can *REMOVE* arithmetic overflows.
I am very interested in seeing how thi
Ralph,
Thanks for your further explanation of this optimization. Here is what
I understand. Please correct me if I am wrong on any of these points:
1. The description in VU#162289 misrepresents the problem has a length
check. It is actually a check for wrap.
2. The optimization in this c
Ralph,
Comments below.
Length-checks are directly related to security, because they protect
against buffer-overruns which are often directly exploited by attackers.
It is much harder to see how reliance on wrap-around could contribute to
the security of an application.
The original impetus fo
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 th
15 matches
Mail list logo
