With regards to no. 4, I may not agree with you completely. Source code review is an active approach before security breach. What the source code review does is to check and validate if there are some backdoors on it leading to security breach. Vulnerability discovery does not only comes from buffer overrun/overflow but other system flaw. During this activity, we also discover some codes that are not supposed to be there or inputs that could cause some trigger to function / crash some systems and know other entry points by a hacker, so source code audit/review may do the job. We are just preventing this to happen.
----- Original Message ---- From: Oscar Plameras <[email protected]> To: Philippine Linux Users' Group (PLUG) Technical Discussion List <[email protected]> Sent: Wed, October 14, 2009 9:23:45 AM 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
