--- On Wed, 10/14/09, Oscar Plameras <[email protected]> wrote:
> Of course, what's at stake are the Integrity of the > Election results as well as other practical considerations > like, what's the implication of annulling the AES for the > May 2010 election in terms of cost, the common interest, > and the Constitution. I think you have misread the CenPEG petition, or you did not read it completely. CenPEG's petition is NOT to STOP/ANNUL the AES. CenPEG's petition is to force COMELEC to release the source code to CenPEG (and to other interested political parties and groups) for review, because COMELEC already promised the release of the source code to CenPEG in June, 2009, in an en-banc COMELEC resolution. COMELEC already decided to give us, and now they refuse to give us the source code. We are not even asking COMELEC to consider favorably any recommendations that may result from CenPEG's source code review, because that is not in the law. > The onus is on the Source Code proponents to convince the > SC that Source Code Review is the only ( which is not) way to > ensure the Integrity and Security of the AES system. > The way it appears to me and others, the Source Code Review > proponents have their work cut out for them. CenPEG is not asking the Supreme Court to force COMELEC to release the source code for review on the grounds that source code review is the only way to ensure the integrity and security of the AES system. We can not be that presumptuous. In fact, to ensure the integrity and security of the AES system, CenPEG has enumerated more than 30 vulnerabilities that COMELEC-Smartmatic has to address, and resolve to the satisfaction of the electorate. CenPEG is asking the Supreme Court to force COMELEC to release the source code for review because it is CenPEG's right under Section 12 of RA-9369 to do its own source code review independent of any review or testing that COMELEC itself might want to do. ~Pablo Manalastas~ > On Wed, Oct 14, 2009 at 1:10 PM, Robert Locke <[email protected]> > wrote: > > > > 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. > > > > > > for review because it is CenPEG's right under Section 12 of RA > > > > > > 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 > >> <[email protected]> > wrote: > >>> On Wed, Oct 14, 2009 at 7:38 AM, Oscar > Plameras <[email protected] > >>> > 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 > > > _________________________________________________ > 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
