Eric Murray wrote:
>>
> Another interesting idea would be to draw up some code on a white board
> and ask the candidate to identify the buffer overflow.
_that's_ asking them to think like a hacker.
<<
No, it's asking them to think like a software profess
d pointer), so it can assigned and passed by value. You can provide an
operator to return the value of the limit, and an indexing operator (with
optional bounds checking). If you really must, you can even implement "pointer
arithmetic" operators for the class which update the limit at the s
library) must never be used.
Of course, there are many other flaws in C and C++ and I advocate applying the
MISRA-C rules (other than Rule 1 if using C++) as well, together with additional
rules to avoid some other dangerous features of C++.
David Crocker
Consultancy & contracting for dependable so
ng them in C++ by
hand long ago. [Actually I prefer to write specifications, verify them, and let
a code generator produce correct C++ from them; but that is another story.]
David Crocker
Consultancy & contracting for dependable software development
www.eschertech.com
ng Simula or Smalltalk. But focussing solely
on Java and O-O programming does not set students up well for embedded software
development.
David Crocker
Consultancy, contracting and tools for dependable software development
www.eschertech.com
uding many classes of embedded
applications].
David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com
Kevin Wall wrote:
>>
If a GENERAL PURPOSE programming language were designed by
scratch by someone who was both a
" (i.e. no
buffer overflows no matter what input is provided), and "the browser address bar
always shows the full URL of the current page".
David Crocker
Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com
or many security issues, the attack string is so specific that it is
unlikely that it will be found during testing even with a large body of
randomly-generated input messages).
David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com
t specifications. I agree that there may be a temptation for
developers to just write the executable version. This is why in PD we have a
semantic distinction between specification and implementation, and you can't
write an implementation without having a specification to attach it to.
David Crocker, E
tive programming.
>>
However, I think I do see a gap between these extremes. You could have a
formal specification that can be mechanically transformed into a
*checker* program that verifies that a solution is correct, but cannot
actually generate a correct solution. The assert() statement
ence degree courses.
Taken together, these changes would result in software that would resist the
vast majority of attacks. It may not always be possible to make software
bulletproof, but that is not an excuse for the appalling insecurity of much of
today's software.
David Crocker, Esch
mportant, you don't know how the set may need to be expanded
in the future.
David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com
rity property
matters, it is much easier to express that as a part of the specification than
it is to write code and be sure that it obeys the security property for all
possible inputs. You are also much more likely to make an error writing the code
than writing the specification, simply because t
t as a positive
feature rather than a disadvantage, since it makes the resulting programs and
specifications easier to understand.
David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com
is by no means unknown for a
body of mathematicians to consider a theorem proven and then for a mistake in
the proof to be found (e.g. the early "proofs" of the four-colour theorem); so I
really don't think that proofs that are manually derived and manually checked
are necess
Y is initialised before use in the above
example, the generated Java code would be violate the "definite initialisation"
rule. We have to generate dummy initialisations in such cases.
David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com
a denial of service vulnerability.
So the better approach is to design the program so that there can be no buffer
overflows; and then verify through proof (backed up by testing) that you have
achieved that goal.
David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependa
ing the tool on itself does provide a lot of value, because proof failures
have shown up a number of problems with the tool. Some of these problems would
be very hard to detect by testing. The input space for a program of this type is
so large so that testing can only exercise a small fraction
r the password; if the password
is lost, it has to be reset to a new one.
David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of
that is a low-level design error, not a manufacturing error. Similarly, I
view coding errors as low-level design errors.
David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com
-Original Message-
From: [EMAIL PROTE
oped so as to be provably correct, then it is highly
likely that immunity to a new class of attack can be expressed by adding
additional formal requirements, allowing an immediate evaluation of where in the
design and implementation the vulnerabilities (if any) lie.
David Crocker, Escher Technol
way of return codes etc. to a point
at which some remedial action can be taken. Exceptions can certainly be misused,
but they are much better than the alternatives in many situations.
David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
garbage collection pauses cannot be
tolerated.
However, I suspect that most security-critical programs do not fall into either
of these categories, so C# or Java would indeed be a better choice than C++ for
those programs.
David Crocker, Escher Technologies Ltd.
Consultancy, contracting a
$19.
My own company provided one of the teams working on this problem, and we found
it is quite a challenge to prove the protocol correct by fully-automatic means.
Proofs that software is free from buffer overflows for all possible inputs are
almost trivial by comparison.
Regards
David Cr
- but the same is
true of C programs. Poorly-performing programs can be written in either
language.
David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com
-Original Message-
From: Crispin Cowan [mailto:[EMAIL
to
be hoped that as JIT compiler technology continues to improve, the performance
gap will be further reduced.
David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com
-Original Message-
From: mikeiscool [mai
which
case you might be able to make a case that the hardware cost saving outweighs
the higher cost and time to develop in C++ rather than Java or C#. Otherwise,
for application-level programming, Java or C# would generally be a more
productive choice.
Regards
David Crocker, Escher Technologie
tead to
describing what the program is supposed to achieve - including its resistance to
hostile input. Until we do so, we will be doing little more than patching up
outdated technology.
David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.
at nobody has thought of yet, and
which we therefore can't refer to in the requirements. But we _can_ solve the
problem of ensuring that software meets the stated requirements, as long as
these are well-defined.
David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for de
der Mouse wrote:
>>
> What Turing actually tells us is that it is possible to construct
> programs that may be correct but whose correctness is not decidable.
> This is a far cry from saying that it is not possible to build
> well-structured programs whose correctness _is_ decidable.
True as f
/SEFM07 for more details.
Regards,
David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information
n you meant #ifdef FRED, the compiler doesn't warn you, and the conditional
may not be interpreted as was intended.
Best regards
David Crocker, Escher Technologies Ltd.
http://www.eschertech.com
-Original Message-
From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecodi
32 matches
Mail list logo
