Re: [SC-L] Coding with errors in mind - a solution?
[Picking out one minor point:] | [Exceptions] can simplify the code because | -as previously mentioned by Tim, they separate error handling from normal | logic, so the code is easier to read (it is simpler from a human reader's | perspective). I have found bugs in my own code by going from error handling | to exceptions -- it made the mistake plain to see. I agree with this ... but: - Many years ago, I worked in a language called BASIC PLUS. (This was an extension to BASIC that DEC bought along with the RSTS operating system. It was actually a surprisingly productive environment. But the details aren't really relevant here.) BASIC PLUS had a simple exception handling approach: You specified ON ERROR statement, which requested that if any system-detected error occurred (and, in modern terms, BASIC PLUS was a safe language, so *all* errors were detected by the run-time system) then the given statement was to be executed. Almost universally, statement was a GOTO to a particular line number. At that line, you had access to the particular error that occurred (and error number); the line number on which it occurred; the current state of any variables; and the ability to resume execution (with some funny limitations). This provided exactly the separation of normal code flow from error handling that seems like a fine idea ... until you try to do anything with it other than logging the error and aborting at some high level of abstraction. I wrote an incredibly hacky error handler and a function called FNSET() that was used essentially as follows: IF (FNSET(errs)) THENnormal code ELSEerror path errs encoded the error numbers that would be handled by error path; any errors not on the list took the usual log-and-abort route. So ... this was essentially a try/catch block (which I don't think I'd seen - this was in 1976 or thereabouts), with the odd filip that you declared the error conditions you handled in the try rather than in the catch. It worked very well, and supplanted the old monolithic error handlers that preceded it. But notice that it moved the error handlers right up close to the normal operational code. Yes, it's not as close as a test after every call - *some* degree of separation is good. Really, what I think matters is that the error handling code live at the right semantic level relative to the code that it's covering. It's fine for the try/catch to be three levels of call up from where the throw occurs *if it the semantics it reflects are those of the code explicitly in its try block, not the semantics three levels down*. This is also what goes wrong with a try block containing 5 calls, whose catch block is then stuck with figuring out how far into the block we got in order to understand how to unwind properly. *Those 5 calls together* form the semantic unit being protected, and the catch should be written at that level. If it can't be, the organization of the code needs to be re-thought. (Notice that in this case you can end up with a try/catch per function call. That's a bad result: Returning a status value and testing it would probably be more readable than all those individual try/catches!) - On a much broader level: Consider the traditional place where exceptions and errors occur - on an assembly line, where the process has bugs, which are detected by QA inspections (software analogue: Assertions) which then lead to rework (exception handling). In the manufacturing world, the lesson of the past 50 years or so is that *this approach is fundamentally flawed*. You shouldn't allow failures and then catch them later; you should work to make failures impossible. Too much of our software effort is directed at better expression (try/catch) and implementation (safe languages, assertions, contract checking) of the assume it will fail, send it back for rework approach. Much, much better is to aim for
Re: [SC-L] Coding with errors in mind - a solution?
-Original Message-
From: Pascal Meunier [mailto:[EMAIL PROTECTED]
Sent: Friday, September 01, 2006 7:41 AM
To: [EMAIL PROTECTED]
Cc: Tim Hollebeek; sc-l@securecoding.org
Subject: Re: [SC-L] Coding with errors in mind - a solution?
On 8/31/06 8:05 PM, mikeiscool [EMAIL PROTECTED] wrote:
His point, I think, is that if you wrap a series of
statements in an
try/catch block, you might not roll back every statement you needed
to, or checked appropriate conditions.
For example:
try {
openFile();
getData();
writeToFile();
setSomeFlag()
moveFile();
deleteTempThings();
} catch(Exception e){
...
}
[...]
Ah, yes, I can see a bad (or under pressure) programmer
lumping together the handling of exceptions that should be
handled separately, or making just one giant try block so
when there's an exception, even if you specify the type
there's still ambiguity as to where it came from and
therefore can't handle it properly. That could be quite a
mess. Thanks.
Exceptions simplify the code? I don't think so. They also
don't reduce
code duplication [per se] you need to add extra functions,
etc, to do
that.
They can simplify the code because
-as previously mentioned by Tim, they separate error handling
from normal logic, so the code is easier to read (it is
simpler from a human reader's perspective).
But they only really separate the error handling if you have
one big try block, and that can make proper diagnosis difficult.
For example, in the above case, if you get a FileNotFound exception,
did it come from openFile or moveFile? It may be possible to
figure that out, but the extra logic will be more than you would
have had if you had just checked the return value of the call.
-if an exception is handled several call layers above, you
don't have to copy/translate and relay the error at each
layer, with the attached loss of context and possible
translation mistakes (error #3 in one layer/module may mean
something different in another...). So, there's less
(duplicated) code.
But the intervening stack frames have to be (painfully) aware of
the fact that they might terminate abruptly. Experience has shown
that getting this right is very hard, offsetting the benefits of
being able to quickly pop back up to a frame where the error can
be handled.
-It is common (and bad, IMO) practice for errors to be
signified to callers by returning an out of range or
different type (or null) value when something else is
semantically expected.
This is especially true when there is only one value available
for all errors (like zero). GetLastError/errno is a silly
substitute for not having another 'out' parameter, justified
on the basis that sometimes you don't care what the error was.
Except that you should!
Exceptions can be useful, but they really aren't what you want for
error handling, and are often cause as many problems as they cause.
What you really want is for all the (partial) side effects of a
function to disappear when it unrolls, but that's hard to do.
Even cleanup code is tough to get right due to the fact that
(A)(B)(A^-1) != B
(can we reboot the universe with that feature disabled?
It causes problems all over the place ...)
That said, Windows Vista will have transactions for file system/
registry modifications, so perhaps that will make life a bit easier...
-Tim
___
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
Re: [SC-L] Coding with errors in mind - a solution?
if an exception is handled several call layers above, you don't have to copy/translate and relay the error at each layer, [...] But the intervening stack frames have to be (painfully) aware of the fact that they might terminate abruptly. That's what unwind-protect is for. What, you don't have unwind-protect? Perhaps you need to fix that first. :-) Actually, I have found it not all that difficult. I have (ab?)used gcc's nested-function nonlocal-goto support as an error-handling throw facility relatively often, and I've run into very few cases where intervening stack frames have to be aware of the throw-through-them potential, and none where I would say it was painful. Perhaps that's just an artifact of how I design my code /~\ 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
Re: [SC-L] Coding with errors in mind - a solution?
On 8/31/06 8:05 PM, mikeiscool [EMAIL PROTECTED] wrote:
On 9/1/06, Pascal Meunier [EMAIL PROTECTED] wrote:
On 8/30/06 3:46 PM, Tim Hollebeek [EMAIL PROTECTED] wrote:
What you've proposed are exceptions. They do help (some) in separating
the normal logic from error handling, but:
(1) they often leave the job half done which has its own risks.
writing exception safe code can be more of a nightmare than error
checking.
I can't help noticing... In Ruby there's an ensure clause that allows you
to bring closure to half-done operations. Perhaps your point is that some
languages have poor exception support, just like some languages don't
provide safe string handling functions?
His point, I think, is that if you wrap a series of statements in an
try/catch block, you might not roll back every statement you needed
to, or checked appropriate conditions.
For example:
try {
openFile();
getData();
writeToFile();
setSomeFlag()
moveFile();
deleteTempThings();
} catch(Exception e){
...
}
Now obviously that's a statement that could be written far better, but
the point is that with the lazy/bad/accidental-bug-producing
programmer it might be common.
Ah, yes, I can see a bad (or under pressure) programmer lumping together the
handling of exceptions that should be handled separately, or making just one
giant try block so when there's an exception, even if you specify the type
there's still ambiguity as to where it came from and therefore can't handle
it properly. That could be quite a mess. Thanks.
Exceptions simplify the code? I don't think so. They also don't reduce
code duplication [per se] you need to add extra functions, etc, to do
that.
They can simplify the code because
-as previously mentioned by Tim, they separate error handling from normal
logic, so the code is easier to read (it is simpler from a human reader's
perspective). I have found bugs in my own code by going from error handling
to exceptions -- it made the mistake plain to see.
-if an exception is handled several call layers above, you don't have to
copy/translate and relay the error at each layer, with the attached loss of
context and possible translation mistakes (error #3 in one layer/module may
mean something different in another...). So, there's less (duplicated)
code.
-It is common (and bad, IMO) practice for errors to be signified to callers
by returning an out of range or different type (or null) value when
something else is semantically expected. The result is that if the caller
forgets to check for errors, a bad value is used by the remaining code. If
the caller checks for errors, an often used way to do this is to tuck the
assignment inside an if statement. Then, even if the error is checked for,
subsequent code may assume that the assigned variable still contains a
semantically correct value (e.g., the previous value) which causes bugs and
possibly vulnerabilities (I remember seeing an instance of this). So (and
for additional reasons that could be chalked up to coding style
preferences), a good practice is to decouple the error channel from the data
channel (e.g., pass additional variables by reference or use exceptions as
the error channel). By passing a variable by reference, its value can be
left intact if there's an error in the called function (I *really* like to
have variables that always contain a semantically correct, or valid, range
and type). Obviously passing additional variables by reference up and down
calling chains complicates the code, whereas exceptions are transparent.
As with most everything else, all this (simplifying the code and reducing
code duplication) depends on having a programmer with coding style and
skills that can take advantage of the provided opportunities.
Pascal
___
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
Re: [SC-L] Coding with errors in mind - a solution?
On 8/30/06 3:46 PM, Tim Hollebeek [EMAIL PROTECTED] wrote: What you've proposed are exceptions. They do help (some) in separating the normal logic from error handling, but: (1) they often leave the job half done which has its own risks. writing exception safe code can be more of a nightmare than error checking. I can't help noticing... In Ruby there's an ensure clause that allows you to bring closure to half-done operations. Perhaps your point is that some languages have poor exception support, just like some languages don't provide safe string handling functions? (2) in many languages, you can't retry or resume the faulting code. Exceptions are really far less useful in this case. See above. (Yes, Ruby supports retrying). (3) you usually end up with some generic clean up code, which generally hides more errors than it solves. I don't think that's fair. Yes, you can write poor exception handling code, but it's far easier to simply ignore or overlook errors or write poor error handling code to the point where the error is effectively ignored (or hidden) or the cause of the error becomes unidentifiable. Exceptions allow me to reduce code duplication (and lower the chance of inconsistent treatment and bugs), simplify the code (which makes it easier to understand and therefore audit) as well as handle problems at an appropriate layer in the code. I'm not saying that exceptions are always the best way to handle things, but they can be part of good programming practices. Pascal Meunier Tim Hollebeek Research Scientist Teknowledge, Corp. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael S Hines Sent: Wednesday, August 30, 2006 11:07 AM To: sc-l@securecoding.org Subject: [SC-L] Coding with errors in mind - a solution? a simple structure that provides for errors would go a long way... If - then - else - on error Do - end - on error Let x = y - on error Let x = function() on error etc... The problem is writing code without thinking of the possible errors that might arise. This forces you to think about the consequences of executing a command... Where 'error' is doing something intelligent when the original command doesn't work... Just a brainstorm... any merit to it? Mike Hines [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Reed (Aesec) Sent: Wednesday, August 30, 2006 1:17 PM To: sc-l@securecoding.org Subject: [SC-L] e: How can we stop the spreading insecure coding examples at, training classes, etc.? Message: 1 Date: Tue, 29 Aug 2006 15:48:17 -0400 From: [EMAIL PROTECTED] Subject: Re: [SC-L] How can we stop the spreading insecure coding examples at training classes, etc.? To: Wall, Kevin [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Cc: SC-L@securecoding.org Message-ID: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Quoting Wall, Kevin [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] : I think that this practice of leaving out the security details to just make the demo code short and sweet has got to stop. Or minimally, we have to make the code that people copy-and-paste from have all the proper security checks even if we don't cover them in training. If we're lucky, maybe they won't delete them when the re-use the code. I agree, and would like to extend it: security should be discussed *at the same time* that a topic is. Teaching security in a separate class, like I have been doing, reaches only a fraction of the audience, and reinforces an attitude of security as an afterthought, or security as an option. Comments in the code should explain (or refer to explanations of) why changing or deleting those lines is a bad idea. However, I'm afraid that it would irritate students, and make security the new grammar and spelling for which points are deducted from perfectly valid write-ups (i.e., it's my ideas that count, not how well I spell). The same used to be said about unstructured programming examples (computed gotos, spaghetti code, multiple entry and exit points from functions, etc). We got past it. We need a similar revolution in thought with regard to security, and some one to take the lead on providing clear, crisp examples of coding style that is more secure by its nature. I don't have one handy - but that's my wish. Ed ___ 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 ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
Re: [SC-L] Coding with errors in mind - a solution?
On 9/1/06, Pascal Meunier [EMAIL PROTECTED] wrote:
On 8/30/06 3:46 PM, Tim Hollebeek [EMAIL PROTECTED] wrote:
What you've proposed are exceptions. They do help (some) in separating
the normal logic from error handling, but:
(1) they often leave the job half done which has its own risks.
writing exception safe code can be more of a nightmare than error
checking.
I can't help noticing... In Ruby there's an ensure clause that allows you
to bring closure to half-done operations. Perhaps your point is that some
languages have poor exception support, just like some languages don't
provide safe string handling functions?
His point, I think, is that if you wrap a series of statements in an
try/catch block, you might not roll back every statement you needed
to, or checked appropriate conditions.
For example:
try {
openFile();
getData();
writeToFile();
setSomeFlag()
moveFile();
deleteTempThings();
} catch(Exception e){
...
}
Now obviously that's a statement that could be written far better, but
the point is that with the lazy/bad/accidental-bug-producing
programmer it might be common.
(2) in many languages, you can't retry or resume the faulting code.
Exceptions are really far less useful in this case.
See above. (Yes, Ruby supports retrying).
(3) you usually end up with some generic clean up code, which generally
hides more errors than it solves.
I don't think that's fair. Yes, you can write poor exception handling code,
but it's far easier to simply ignore or overlook errors or write poor error
handling code to the point where the error is effectively ignored (or
hidden) or the cause of the error becomes unidentifiable. Exceptions
allow me to reduce code duplication (and lower the chance of inconsistent
treatment and bugs), simplify the code (which makes it easier to understand
and therefore audit) as well as handle problems at an appropriate layer in
the code.
Exceptions simplify the code? I don't think so. They also don't reduce
code duplication [per se] you need to add extra functions, etc, to do
that.
I'm not saying that exceptions are always the best way to handle things, but
they can be part of good programming practices.
They _can_ be, but often aren't.
Pascal Meunier
-- mic
___
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] Coding with errors in mind - a solution?
a simple structure that provides for errors would go a long way... If - then - else - on error Do - end - on error Let x = y - on error Let x = function() on error etc... The problem is writing code without thinking of the possible errors that might arise. This forces you to think about the consequences of executing a command... Where 'error' is doing something intelligent when the original command doesn't work... Just a brainstorm... any merit to it? Mike Hines [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Reed (Aesec)Sent: Wednesday, August 30, 2006 1:17 PMTo: sc-l@securecoding.orgSubject: [SC-L] e: How can we stop the spreading insecure coding examples at, training classes, etc.? Message: 1 Date: Tue, 29 Aug 2006 15:48:17 -0400 From: [EMAIL PROTECTED] Subject: Re: [SC-L] How can we stop the spreading insecure coding examples at training classes, etc.? To: "Wall, Kevin" [EMAIL PROTECTED] Cc: SC-L@securecoding.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Quoting "Wall, Kevin" [EMAIL PROTECTED]: I think that this practice of leaving out the "security details" to just make the demo code short and sweet has got to stop. Or minimally, we have to make the code that people copy-and-paste from have all the proper security checks even if we don't cover them in training. If we're lucky, maybe they won't delete them when the re-use the code. I agree, and would like to extend it: security should be discussed *at the same time* that a topic is. Teaching security in a separate class, like I have been doing, reaches only a fraction of the audience, and reinforces an attitude of security as an afterthought, or security as an option. Comments in the code should explain (or refer to explanations of) why changing or deleting those lines is a bad idea. However, I'm afraid that it would irritate students, and make security the new "grammar and spelling" for which points are deducted from "perfectly valid write-ups" (i.e., "it's my ideas that count, not how well I spell"). The same used to be said about unstructured programming examples (computed gotos, spaghetti code, multiple entry and exit points from functions, etc). We got past it.We need a similar revolution in thought with regard to security, and some one to take the lead on providing clear, crisp examples of coding style that is more secure by its nature. I don't have one handy - but that's my wish.Ed ___ 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
Re: [SC-L] Coding with errors in mind - a solution?
Worse is when it works in unintended ways without producing an error. The code has to detect whenever something doesn't match a white list of expected program states and inputs. I think that in example code, the detection is more important than the subsequent handling because the handling will vary depending on the exact application requirements and framework. The detection is where contracts and correctness are verified, and I'd like to leave the handling of violations to some law enforcement module, so to speak. Perhaps a good enough approach for teaching would be to raise an exception (or use assert statements for languages that don't have exceptions) whenever a problem is detected, and leave it at that. This way, the handling of the exception (logging, UI, aftermath, etc...) doesn't bloat the code and distract from the main subject, yet all unsafe conditions and errors would be highlighted and caught. It's not revolutionary, but it's better than what we have now. Would it be good enough? I can picture people deleting those assert statements that just make their programs crash ;) Pascal Meunier On 8/30/06 2:07 PM, Michael S Hines [EMAIL PROTECTED] wrote: a simple structure that provides for errors would go a long way... If - then - else - on error Do - end - on error Let x = y - on error Let x = function() on error etc... The problem is writing code without thinking of the possible errors that might arise. This forces you to think about the consequences of executing a command... Where 'error' is doing something intelligent when the original command doesn't work... Just a brainstorm... any merit to it? Mike Hines [EMAIL PROTECTED] _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Reed (Aesec) Sent: Wednesday, August 30, 2006 1:17 PM To: sc-l@securecoding.org Subject: [SC-L] e: How can we stop the spreading insecure coding examples at, training classes, etc.? Message: 1 Date: Tue, 29 Aug 2006 15:48:17 -0400 From: [EMAIL PROTECTED] Subject: Re: [SC-L] How can we stop the spreading insecure coding examples at training classes, etc.? To: Wall, Kevin mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] Cc: SC-L@securecoding.org Message-ID: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Quoting Wall, Kevin mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]: I think that this practice of leaving out the security details to just make the demo code short and sweet has got to stop. Or minimally, we have to make the code that people copy-and-paste from have all the proper security checks even if we don't cover them in training. If we're lucky, maybe they won't delete them when the re-use the code. I agree, and would like to extend it: security should be discussed *at the same time* that a topic is. Teaching security in a separate class, like I have been doing, reaches only a fraction of the audience, and reinforces an attitude of security as an afterthought, or security as an option. Comments in the code should explain (or refer to explanations of) why changing or deleting those lines is a bad idea. However, I'm afraid that it would irritate students, and make security the new grammar and spelling for which points are deducted from perfectly valid write-ups (i.e., it's my ideas that count, not how well I spell). The same used to be said about unstructured programming examples (computed gotos, spaghetti code, multiple entry and exit points from functions, etc). We got past it. We need a similar revolution in thought with regard to security, and some one to take the lead on providing clear, crisp examples of coding style that is more secure by its nature. I don't have one handy - but that's my wish. Ed ___ 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 ___ 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
Re: [SC-L] Coding with errors in mind - a solution?
William L. Anderson wrote: Years ago I had to write a Fortran program as part of a job interview. The program problem was quite simple, and I wrote one that checked for as many errors as I could think of. My interviewer wanted to know what took me so long. I didn't get an offer. Years ago (probably not as many), I had to write a C program for a job interview. I also had it test for practically every error I could think of, mainly input format errors. I did get the offer, but I was told that the company placed such a premium on performance (it was telephony stuff) that I should not be quite so thorough on the errorchecking. Silly me, I had thought that they would also value reliability My 2 cents is that people are not really willing to pay for software with the kinds of qualities that we talk about in this list (which is about more than security). Well, *most* people anyway. The avionics, medical, and suchlike fields are quite another story. Bill Anderson Is this perchance the Bill Anderson who was my great grandboss until he left BAE for Cryptek? -- Dave Aronson http://www.davearonson.com/ Specialization is for insects. -Heinlein ___ 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
