Even if Mr. Plameras was right (which he's not), it's irrelevant. The source code review is required by law according to Mr. Manalastas, so what's there to argue? This is a legal issue, not a technical one.
On 10 14, 09, at 9:57 AM, Paolo Alexis Falcone wrote: > Sure we know the dictionary definition, done that in practice, coded > measures to prevent such. > > A buffer overrun need not terminate the system. The C and C++ > standards mention that handling of such is undefined. It may crash > the system, or be exploited once certain input has been placed. > > While it is possible that you can craft a test that will do buffer > overruns over certain inputs, you will have to craft multiple tests > (therefore consuming time and resources) to know all possible > combinations (as the buffer overrun may not be in your code, but > together with a current bug in one of the libraries, and together an > exploit can occur) while a simple source code check will get there > faster. > > Given undefined behavior, your program may have the semblance of > working properly (which satisfies the tests), but over the course of > time make a sudden crash (had this at work just last weekend), or at > this time be exploited (seen this happen a couple of times). You > cannot simply test against what you dont expect, since software > testing demands that you know your expectations in order to have a > successful UAT. > > I do understand the tests are measured against a thousand samples > (as you can only fit so much inside a voting precinct), but your > concept of tests being sufficient is already murky given the > arguments and how we poked a hole in your testing methodology re > buffer overruns. > > A source code review + very good and extensive tests will be most > beneficial and the fastest way to find exploitable code and fix > them. It makes testing easier as you have the expectations (the > source + the tests) absolutely in front of you - if there are still > exploits those are already either in the libraries used. > > > Sent from my Nokia phone > -----Original Message----- > From: Oscar Plameras > Sent: 2009-10-14 09:23:45 > Subject: Re: [plug] COMELEC SUED (Was: The Death of Election > 2010SourceCodeReview) > > For the benefit of everybody so we know what we > are talking about, I will quote this short article > about buffer overruns, > > "Buffer overrun is s an anomaly where a process > stores data in a buffer outside the memory the > programmer set aside for it. In computer security > and programming, a buffer overflow, or buffer overrun, > is an anomaly where a process stores data in a buffer > outside the memory the programmer set aside for it. > The extra data overwrites adjacent memory, which > may contain other data, including program variables > and program flow control data. This may result in erratic > program behavior, including memory access errors, > incorrect results, program termination (a crash), or a > breach of system security. > > Buffer overflows can be triggered by inputs that are > designed to execute code, or alter the way the program > operates. They are thus the basis of many software > vulnerabilities and can be maliciously exploited. > Bounds checking can prevent buffer overflows. > > Programming languages commonly associated > with buffer overflows include C and C++, which provide > no built-in protection against accessing or overwriting > data in any part of memory and do not automatically > check that data written to an array (the built-in buffer > type) is within the boundaries of that array." as quoted > from http://en.wikipedia.org/wiki/Buffer_overflow > > We are interested in, > > 1. "This may result in erratic program behavior, > including memory access errors..." in which case the > program will abruptly terminate. This will be caught by > the Outcome test. > > 2. "incorrect results..", This will be caught also by the > Outcome test > > 3. Program termination (a crash),..", which will be caught > by the Outcome test because the program crashes. > > 4. " or a breach of system security" meaning absurd or > corrupt results will be generated. The Outcome test > will again check the Actual Outputs against the Expected > Outputs. And since the two do not agree the system is > rejected. > > > > > On Wed, Oct 14, 2009 at 11:47 AM, Gideon Guillen > <gideon_l...@thegidz.org> wrote: >> On Wed, Oct 14, 2009 at 7:38 AM, Oscar Plameras <oscarplame...@gmail.com >> > wrote: >>> I'm as bored as you are with arguments going around in >>> circles. It's like watching dogs chasing their tails. >> >> You still haven't addressed the issue about your output based method >> not addressing security issues. Remember the part of the thread >> wherein actual voting machines used in a major industrialized country >> shipping with real and exploitable buffer overrun security >> vulnerabilities. And, contrary to you last post about it, you don't >> need to overload a system to exploit it. Just one seemingly valid >> malformed input is all it takes to explot it. You can use >> vulnerabilities to make the machine do things outside the scope of >> your output based testing, such as inserting and executing >> "dagdag-bawas" code. >> >>> As a matter of interest there was a previous court decision >>> on a similar matter which was ruled by SC in favor of the >>> Comelec. >> >> The previous ruling has nothing to do with the source code auditing, >> though. It has to do with the validity of the bid. >> _________________________________________________ >> Philippine Linux Users' Group (PLUG) Mailing List >> http://lists.linux.org.ph/mailman/listinfo/plug >> Searchable Archives: http://archives.free.net.ph >> > _________________________________________________ > Philippine Linux Users' Group (PLUG) Mailing List > http://lists.linux.org.ph/mailman/listinfo/plug > Searchable Archives: http://archives.free.net.ph > > _________________________________________________ > Philippine Linux Users' Group (PLUG) Mailing List > http://lists.linux.org.ph/mailman/listinfo/plug > Searchable Archives: http://archives.free.net.ph _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List http://lists.linux.org.ph/mailman/listinfo/plug Searchable Archives: http://archives.free.net.ph
