Re: [SC-L] GCC and pointer overflows [LWN.net]
At 3:12 PM -0400 5/1/08, Leichter, Jerry wrote: > The VAX VMM effort died with the announcement of the Alpha, in late 1992 > - though obviously the death was decided internally once the move to > Alpha was decided, which would have been somewhat earlier. The origins > of the VAX VMM effort date back to the early 80's. My understanding is that DEC pulled the plug on the VMM project (called SVS) during a successful field test when they discovered that while the NSA division that handled trusted computing was really gung ho about the project, none of the government units which might actually make purchases were interested in multilevel secure machines. Remember that the MicroVAX II was available at the time and from many perspectives (including that of taxpayers) it was a lot nicer to use separate machines for various security classifications. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] GCC and pointer overflows [LWN.net]
| Ken, a good example. For those of you who want to reach much further | back, Paul Karger told me of a similar problem in the compiler (I don't | remember the language) used for compiling the A1 VAX VMM kernel, that | optimized out a check in the Mandatory Access Control enforcement, which | separates information of different classifications (*). [For those not | familiar with it, this was a provably secure kernel on which you could | host multiple untrusted operating systems. Despite what some young-uns | seem to think, VMs are not a new concept - they go back at least three | decades that I know of, and possibly longer. The A1 VAX effort ended | roughly 20-25 years ago, to give a timeframe for this particular | compiler issue.] The VAX VMM effort died with the announcement of the Alpha, in late 1992 - though obviously the death was decided internally once the move to Alpha was decided, which would have been somewhat earlier. The origins of the VAX VMM effort date back to the early 80's. As best I can recall, the VAX VMM kernel was written almost entirely in PL/I. (Why? Because the main alternatives available at the time were assembler and C - way too open-ended for you to be able to make useful correctness assertions - and Pascal, which even in VMS's much extended version was too inflexible. There were almost certainly a few small assembler helper programs. Before you defend C, keep in mind that this is well pre-Standard, when the semantics was more or less defined by "do what pcc does" and type punning and various such tricks were accepted practice.) I know from other discussions with Paul that it was understood in the high assurance community at the time that, no matter what you knew about the compiler and no matter what proofs you had about the source code, you still needed to manually check the generated machine code. Expensive, but there was no safe alternative. So any such optimizations would have been caught. -- Jerry | --Jeremy | | (*) At least that's what my memory tells me - if Paul is on this list, | perhaps he can verify or correct. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] GCC and pointer overflows [LWN.net]
At 1:00 PM -0400 5/1/08, Epstein, Jeremy wrote: > Ken, a good example. For those of you who want to reach much further > back, Paul Karger told me of a similar problem in the compiler (I don't > remember the language) VAX Pascal, before VMS was on Alpha (and long before Itanium). > used for compiling the A1 VAX VMM kernel, that > optimized out a check in the Mandatory Access Control enforcement, which > separates information of different classifications (*). [For those not > familiar with it, this was a provably secure kernel on which you could > host multiple untrusted operating systems. Despite what some young-uns > seem to think, VMs are not a new concept - they go back at least three > decades that I know of, and possibly longer. The A1 VAX effort ended > roughly 20-25 years ago, to give a timeframe for this particular > compiler issue.] -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] GCC and pointer overflows [LWN.net]
Ken, a good example. For those of you who want to reach much further back, Paul Karger told me of a similar problem in the compiler (I don't remember the language) used for compiling the A1 VAX VMM kernel, that optimized out a check in the Mandatory Access Control enforcement, which separates information of different classifications (*). [For those not familiar with it, this was a provably secure kernel on which you could host multiple untrusted operating systems. Despite what some young-uns seem to think, VMs are not a new concept - they go back at least three decades that I know of, and possibly longer. The A1 VAX effort ended roughly 20-25 years ago, to give a timeframe for this particular compiler issue.] --Jeremy (*) At least that's what my memory tells me - if Paul is on this list, perhaps he can verify or correct. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth Van Wyk > Sent: Thursday, May 01, 2008 9:14 AM > To: Secure Coding > Subject: [SC-L] GCC and pointer overflows [LWN.net] > > FYI, here's an interesting article (and follow-on > discussions) about a recent bug in the GCC compiler collection. > > http://lwn.net/Articles/278137/ > > The bug, which has been documented in a CERT advisory, > affects C code in which, under some circumstances, buffer > bounds checking can be optimized out to produce binaries that > are susceptible to buffer overflows. The article includes a > couple examples that really help illustrate the issue -- very > interesting reading, IMHO. > > Of course, many/most SC-Lers will no doubt jump on this as > another example of why C is such a dangerous language to > write (secure) code in, and that's fine. But, I see the > issue at least a little > differently: a compiler making decisions for the programmer > and producing executable code that does not accurately > conform to what the programmer coded. We've all heard of > security-related optimizing issues for years, right? Well, > here's a prime example of one in action. > > > Cheers, > > Ken > > - > Kenneth R. van Wyk > KRvW Associates, LLC > http://www.KRvW.com > > > > > > ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] GCC and pointer overflows [LWN.net]
> The bug, which has been documented in a CERT advisory, affects C code > in which, under some circumstances, buffer bounds checking can be > optimized out to produce binaries that are susceptible to buffer > overflows. [...] > Of course, many/most SC-Lers will no doubt jump on this as another > example of why C is such a dangerous language to write (secure) code > in, and that's fine. Actually, it isn't. It's a dangerous language to write sloppy, buggy code in. Go read the advisory - it's only severely broken tests that are affected. Such code has always been broken; the recent change just changes the behaviour produced by such broken code, and I have trouble getting worked up about it. > But, I see the issue at least a little differently: a compiler making > decisions for the programmer and producing executable code that does > not accurately conform to what the programmer coded. It accurately conforms to what the programmer coded, just not to what the programmer intended to code. The "problem" affects only code that depends on certain pointer computations whose behaviour has never been promised by C. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] GCC and pointer overflows [LWN.net]
Ken, Comment below. > FYI, here's an interesting article (and follow-on discussions) about a > recent bug in the GCC compiler collection. > > http://lwn.net/Articles/278137/ > > The bug, which has been documented in a CERT advisory, affects C code > in which, under some circumstances, buffer bounds checking can be > optimized out to produce binaries that are susceptible to buffer > overflows. The article includes a couple examples that really help > illustrate the issue -- very interesting reading, IMHO. > > Of course, many/most SC-Lers will no doubt jump on this as another > example of why C is such a dangerous language to write (secure) code > in, and that's fine. But, I see the issue at least a little > differently: a compiler making decisions for the programmer and > producing executable code that does not accurately conform to what the > programmer coded. We've all heard of security-related optimizing > issues for years, right? Well, here's a prime example of one in action. To be fair to gcc, the code in question is "undefined behavior" which means that the C standard gives the compiler lease to deal with the code in any manner they wish. This means that they do not need to diagnose the problem, generate object code, or generate correct code. This is a problem with the C language--the onus is on the developer to write "conforming" applications. The reason we dinged gcc in this case was because versions of the compiler prior to v 4.2 did generate object code in this case that was consistent with the user model (e.g., that adding a pointer to a integer could result in wrapping). Version 4.2 silently changed this behavior without providing a flag or option to diagnose the issue. They have since modified their compiler to warn on this issue, and once this version of the compiler is released we will update the vul note to recommend this version of the compiler be used. We are looking at this as a prototype for similar vulnerability notes dealing with erroneous or unexpected behavior in tools that can lead to the introduction of vulnerabilities in software, so I would be interested in feedback as to if vulnerability notes of this sort are of value. rCs ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
[SC-L] GCC and pointer overflows [LWN.net]
FYI, here's an interesting article (and follow-on discussions) about a recent bug in the GCC compiler collection. http://lwn.net/Articles/278137/ The bug, which has been documented in a CERT advisory, affects C code in which, under some circumstances, buffer bounds checking can be optimized out to produce binaries that are susceptible to buffer overflows. The article includes a couple examples that really help illustrate the issue -- very interesting reading, IMHO. Of course, many/most SC-Lers will no doubt jump on this as another example of why C is such a dangerous language to write (secure) code in, and that's fine. But, I see the issue at least a little differently: a compiler making decisions for the programmer and producing executable code that does not accurately conform to what the programmer coded. We've all heard of security-related optimizing issues for years, right? Well, here's a prime example of one in action. Cheers, Ken - Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com smime.p7s Description: S/MIME cryptographic signature ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
